Cape Clear Software today announced the availability of a new version of its Enterprise Service Bus (ESB), hot on the heels of BEA's own ESB announcement earlier this week.

Cape Clear 6.1 adds support for a range of messaging infrastructures, including:

(x) Standard Internet infrastructure:
- HTTP
- FTP
- SMTP
- WS-ReliableMessaging
(x) Existing JMS Middleware:
- JBoss JMS
- Oracle JMS
- SonicMQ
- WebLogic JMS
- WebSphere MQ
(x) New JMS Middleware:
Cape Clear's ESB now optionally includes a fully integrated version of the JBoss JMS.

Cape Clear also provides the Orchestrator BPEL engine with the following new features:

(x) A new Copy dialog that provides a simple interface for business analysts to construct complex XPath expressions in BPEL.
(x) Auto-generation of BPEL variables, which saves time and makes the process of creating working BPEL processes less complex.
(x) Additional support for BPEL correlation sets.
(x) Increased productivity, by enabling the drag and drop of partner links.
(x) Improved process-management features, enabling administrators to view messages exchanged with partners for a complete process audit trail.
(x) More sophisticated process-management search tools. Administrators can now view and search processes on the basis of business or process data. This makes it much easier for business administrators to manage process flows.

Cape Clear 6.1 also added support for SAAJ 1.2 (SOAP with Attachments API for Java).

Is this not just another XML-based tool implementing WS-Everything from OASIS?

At least BEA chose not to turn everything into XML first, that will give them a very good edge on performance.

The list of supported features doesn't read much past standard internet transports and JMS, what then is their selling point over something like BEA, Sonic or PolarLake?

BEA have little expertise in integration, yet, Sonic are better in this space but I would have opted for PolarLake, it supports all the same features and more.

I'd be interested to hear from anyone who's using this in anger or who's compared it to other products.

-John-

BEA have little expertise in integration, yet,

I'm curious. Does WebLogic Integration 8.1 not count? It's been a pretty solid product (since SP2) in my experience, and one of the reasons I joined BEA. If you disagree, I'd like to understand.

BEA have little expertise in integration, yet,
I'm curious. Does WebLogic Integration 8.1 not count? It's been a pretty solid product (since SP2) in my experience, and one of the reasons I joined BEA. If you disagree, I'd like to understand.

I think BEA have the best app server on the planet, they also have the best portal server (sorry Billy@IBM at least they run on last year's J2SE version even if they don't run on 1.5 yet).

BEA's WLI is a very good tool and it's coming along just fine. What I really meant was that they don't have a name for integration, they're an App Server company not and integration company. Currently they have pretty sorry support for financial services integration (SWIFT et al) but should change in later releases.

BEA are obviously working hard to change their position from being just "pure J2EE" and their recent announcement to work with Spring is the best indication I seen from any company of their size. It really shows they have vision into the 21st century.

You have joined the right company Stu, WLI has great potential, keep working on it.

-John-

At least BEA chose not to turn everything into XML first, that will give them a very good edge on performance.

I don't understand what do you mean by this, if you are an web service application server, the messages are in XML? Its the job of the application server deserialize the XML message into Java objects.

I don't understand what do you mean by this, if you are an web service application server, the messages are in XML?

You said it, a "web services application server", why does everything have to be web services? Great for those who want XML and web services of course but not very flexible when it comes to CSVs, FIX, SWIFT etc.

Its the job of the application server deserialize the XML message into Java objects.

I think you'll find CapeClear do not serialise their XML into Java Objects although I'll bow to anyone with a more intimate knowledge.

-John-

Its the job of the application server deserialize the XML message into Java objects.

I think you'll find CapeClear do not serialise their XML into Java Objects although I'll bow to anyone with a more intimate knowledge.-John-

Boiled down, the Cape Clear server accepts a SOAP message and calls a method on a Java class passing the deserialized SOAP message as parameters. How could it not deserialize the message into Java objects, I can't see how it would work if it didn't!

Boiled down, the Cape Clear server accepts a SOAP message and calls a method on a Java class passing the deserialized SOAP message as parameters. How could it not deserialize the message into Java objects, I can't see how it would work if it didn't!

You are right of course, what I meant was that CapeClear have to turn everything into XML before they can process it, i.e. a CSV file will have to be XMLised before it can be read in. I agree it all has to serialise into Java at some point but they don't use JavaBinding so it's not terribly fast. CSV to XML to SAX/DOM (in Java) through XSL to XML to CSV is not as fast as CSV to Java to CSV.

If you're only working with low volume XML then fine, you're not going to care.

PolarLake are also XML based but they have very good optimisation for non-XML integration. They also recognise that there is life outside of XML in the integration world.

-John-

At least BEA chose not to turn everything into XML first, that will give them a very good edge on performance.

an "Enterprise Service Bus" that doesn't expose Services in a technology neutral fashion, such as through XML isn't much an a "Bus" in my opinion, it's more of a "Distributed Java thingy", and we already have EJB's for that, don't we?

Besides having a "document-first" XML-driven approach also makes you think through your Service interfaces in a way that doesn't tempt you to cut corners in the same way as you would in an all Java-environment (I would refer to any arbitrary SOAP-discussion around this, I know, I know, an ESB and SOAP are far from equivalent, but when it comes to Service interfaces SOAP and XML tends to be a good fit a lot of the time for business services).

Generally speaking:
Working with POJO's is nice and all, but if you are working with integration and cant be bothered to work with XML, you should probably get the hell out of integration work.

Let me clarify that XML based integration with respect to BEA Aqualogic ESB. Any ESB worth it's salt, including BEA Aqualogic provides XML based integration as well as schema valdation at the message level. They also provide JMS or other application protocols in addition to SOAP over HTTP or SMTP etc.

According to Gartner who coined the term ESB, there are four foundations in an ESB. They are : reliable messaging, XML transformation, content based routing and web services feature(well Register, Find & Bind of services). A good ESB should also support service registry(sort of UDDI) and dash board capability for services health monitoring, SLA violation alerts etc.

Aqualogic ESB provides all those above mentioned features with XQuery and XSLT used for content based routing of the message.

Bijan

I believe most companies are dealing with INTERNAL integeration of various system. External integration I would imagine for most large company, is a very small percentage of the integration work being done. An ESB that understands MULTIPLE protocol and are able to transform between these protocols is a very valuable tool. I personally don't tie INTEGRATION work with XML. IBM WAS-6 is trying to provide such a bus.


thanx
Note, I have no affiliation with IBM.

Generally speaking:
Working with POJO's is nice and all, but if you are working with integration and cant be bothered to work with XML, you should probably get the hell out of integration work.

I'm sorry but integration is a multi-billion dollar industry and XML is a small part of it. If it were so simple why then do companies like Sun buy SeeBeyond for several hundred $million, TSI bought Braid for over $100m, TSI became Mercator which was bought by Ascential who were then snapped up by IBM, who also bought NEON, all integration companies, non of them XML.

Finally, next time you get some cash out of your ATM, think about the processes behind the scenes, about 90% of them are something other than XML.

What about X12, HL7, SWIFT, FIX, CSVs, IIOP, JRMP or SAP, EDIFACT etc. etc.

Where have you been?

-John-

Sorry, the recent postings were by "John" not "Greg", that's what you get from using someone else's machine with log-in cookies on it. :-(

-John-

What about X12, HL7, SWIFT, FIX, CSVs, IIOP, JRMP or SAP, EDIFACT etc. etc.

Good to read sensed posts around this Enormous Silly Bullshit mood !
:-P

BTW, check out IONA's Artix if you want a taste of what real integration is, and what I'd personnally call a real "ESB", even if I dislike the name.
After all, that's their job since years now, and I would bet such a CORBA vendor has pretty good solutions to integration issues...

And, no, they're not tied to XML at all. Of course they support it, otherwise they would not sell their stuff since it wouldn't be fashion at all, but you don't *have to* use it.

Last but not least, please consider twice relationships between companies buying each other, and technological improvements. IMHO, all this is mostly about stock quotes considerations, nothing more.

Have fun,

Remi