Progress Sonic and Cape Clear blaze the SOA trail
Duelling ESB suites continue to advance on service-oriented integration, offering a choice between simple and affordable or sophisticated and costly
The similarities in these solutions end there. Under the surface, these enterprise service buses are poles apart. Cape Clear, narrowly focused on XML-based Web services, has long incorporated WS-* standards for messaging between end points, but requires a Java application server for deployment. In contrast, the Progress Sonic ESB builds on the company’s MOM (message-oriented middleware) heritage, relying on the SonicMQ messaging system for its backbone, bringing additional weight to the wire, but proven reliability as well, with easy scalability.
The Cape Clear ESB 7.5 suite makes good sense for small to midsize rollouts where its excellent, event-driven technology implementation and development tools aren’t compromised by the unsophisticated management and administration features.
Progress Sonic ESB Product Family 7.5 is a very good choice for large and highly distributed SOA initiatives, thanks to brilliant distributed debugging capabilities and top-notch scalability. Although a number of features for the ESB (such as data services, monitoring, and XML offloading) require add-ons that could quickly escalate cost, Progress has done a great job in building out this product.
Cape Clear ESB 7.5
Both Progress Sonic and Cape Clear have eased installation with automation. Cape Clear's core server components and IDE installed autonomously with only minor tweaks. Cape Clear also installed JBoss to serve as the default app server. Progress Sonic includes its XML Server and Database Service out of the box.
Cape Clear bundles its server (ESB and BPEL orchestration engine) and Cape Clear Studio (graphical IDE and debugger) in its development environment, providing a good set of wizards and editors to get your developers productive. All of the expected tools are there: WSDL, XSLT (XSL Transformation), Java client stubs, and more.
Click for larger view.
In my testing, the Assembly Editor made rapid work of stringing together transforms and transports (including REST, s/FTP, e-mail, JMS (Java Message Service), outbound XMPP (Extensible Messaging and Presence Protocol), and RSS), along with security and load balancing, from a pallet of activities. The editor also provides hooks to take advantage of the new multichannel features, with only minor declarative tinkering required. Assembly configuration files (XML) get packaged and deployed as Spring-based Java Beans into the runtime.
The Assembly Editor further streamlines development with rapid orchestration prototyping. Hopefully, as standards continue to mature, the company will offer an eventual migration path for portability.