Cape Clear ESB 6.5

Cape Clear ESB 6.5

Cape Clear's entry is interesting because of its origins: ESB 6.5 didn't evolve from an enterprise service platform, like BEA's AquaLogic and Oracle's SOA Suite did; it didn't grow out of a conventional EAI product, like Tibco's and Software AG's products did; nor did it bloom from a messaging world, like Sonic's and IBM's products did. Rather, Cape Clear's software came out of a pure Web services world, and its ESB approach reflects these roots as much as its competitors reflect theirs.

Cape Clear and BEA both view the ESB as a service orchestration mechanism and don't include conventional integration as part of their visions for their individual ESB products. Cape Clear takes the same metadata-driven orchestration approach to implementing its functionality as BEA does, though it has chosen to tie its success to BPEL, as has Oracle, instead of a proprietary orchestration notation.

Cape Clear ESB 6.5 is J2EE-based and can be deployed within any number of enterprise service platforms, including IBM WebSphere and BEA WebLogic. It's distributed with JBoss, which is what we used for testing. Orchestration requires a BPEL repository, and we used ESB 6.5's embedded Hibernate database for this as well as for configuring Cape Clear ESB to use our Oracle9i database. The configuration can be determined during setup, and we suggest this as the best course of action if you want to use an external RDBMS as ESB 6.5's BPEL and WS-RM (Web Services Reliable Messaging) repositories. Regardless of which database you're using, if the system is already installed, and you migrate to a different database, you will have to modify the configuration files manually, or reinstall the application. Cape Clear recommends a reinstallation of its software if you need to migrate.

Cape Clear's design-time environment is an Eclipse 3.1 plug-in--something we are now intimately familiar with, as it was distributed with almost all the products we tested. The design-time environment provides the means to develop both individual services and orchestrations. We easily created services integrating JMS queues and databases; the latter required all the necessary code--including connectivity--to build. We missed having an easy mechanism for dealing with SMTP and, like Software AG's and IBM's exclusion of SMTP, we found this lack problematic. Again, coding was necessary.

Integration with a foreign JMS was a breeze, requiring that we specify an "integration" from Cape Clear's Web administrative console and then copy the appropriate JAR files to the proper directory on the server. Once an integration was defined, all we had to do was add an adapter and then call the JMS queue from our orchestration, which was presented as just another service by Cape Clear.

Orchestrating our services using Cape Clear's BPEL editor was painless, though we much preferred Oracle's BPEL editor. As we published each process to the server, it was added to ESB 6.5's included UDDI 2 registry. ESB 6.5 is one of the few products that doesn't support UDDI 3 or allow access to external registries for its run-time environment. Support for external and internal registries is completely integrated into the design-time environment, however, so including services in an orchestration requires only that you choose services from the registry and drop them into the orchestration.

Once our services were created and orchestrated, deployment was a simple matter of publishing the created archives to the server. Our created archives included all requisite external JARs--such as those needed for database access--and could easily be deployed to any existing Cape Clear ESB server. Unlike the products from BEA and Oracle, Cape Clear's generates code for every orchestration/service, and it is this code that is compiled and bundled into a WAR (Web Archive) file for deployment.Testing our service was a breeze with Cape Clear's included Web services tester, accessible directly from within Eclipse. We preferred Cape Clear's tester over BEA's simply because Cape Clear's creates the necessary SOAP environment and headers as well as the body--we had only to fill out the necessary elements and hit "send" in order to run our test.

Cape Clear ESB's process-management features are a plus, though the capabilities are much more limited than those in Oracle's product. The Web orchestration manager console gave us a view of processes, messages sent and timing information as well as the exposure of process variables. Like BEA's presentation of process variables, they had to be of a primitive type (string, integer), but we were impressed that such functionality was included at all.

There were fewer capabilities for process managment thanwe would have liked. Additionally, we encountered errors while running against the HSQL database that prevented us from managing processes within the Cape Clear System. We initiated thousands of processes, many of which ended up hung. Although a delete option was available, it failed with a less-than-helpful error message, and we couldn't resolve the error working with Cape Clear's engineers. Cape Clear asserts that this is an issue with HSQL, and we agree that HSQL should not be used in production.

Cape Clear came in at $35,000 per processor, and unlike many of its competitors it charges for its design-time environment--$3,500 per developer. That drove the price of Cape Clear ESB 6.5 for NWC Inc.'s scenario over $100,000, which put Cape Clear in the middle of the pack.

Cape Clear ESB 6.5, $105,000 as tested. Cape Clear, (888) CAPE 439, (781) 622-2258. www.capeclear.com0