Oracle Service Bus

From the podcast Oracle Middleware Strategy Update, I learned more about what Oracle will be doing with the BEA SOA products and how they will integrate or co-exist with the Oracle SOA Suite.

Interesting to hear that AquaLogic Services Bus (ALSB) will become the 2^nd ESB of the Oracle SOA Suite, called the Oracle Service Bus. This product is positioned as a "standalone" ESB, extremely fast, light-weight and highly functional, but tied to the BEA WebLogic application server.

Oracle will drop the BEA SmartConnect adapters and retain its own JCA adapters, with exceptions being e.g. the REST adapter from BEA. Oracle also goes for its own Web Services Manager for policy based security (based on security solution obtained from Oblix). Oracle will drop the BEA security solution and stop the relationship with Amberpoint. But Oracle will retain the BEA Event Server (Complex Event Processing) and BEA Repository (Flashline acquisition) as well as AquaLogic BPM (Fuego acquisition).

Interesting to learn that Oracle retains the BPM solution to complement their (strong) BPEL offering (Collaxa acquisition). Many integration vendors have 2 process management solutions: one more low level focusing on BPEL and integratino processes and one more high-level focusing on process modelling, human interaction (workflow) and business rules.

Oracle has made more podcasts available on other related BEA products. Nice to hear such clear statements from Oracle regarding the future of some of the BEA products.

Ethernet over powerline

The house I live in has quite some steel and concrete. This causes the Wifi connection upstairs to drop often and there is also some latency. Therefore I started digging around for a solution. A good friend of mine suggested the use of Ethernet over powerline, so use the electricity circuits in your home for transporting bits and bytes at high speeds. The maximum speed is currently 200 Mbit, which results in real throughput of maximum 50 to 60 Mbit. There are 2 camps: Homeplug AV with Intellon chipset and UPA with DSS9010 chipset from DS2. My good friend strongly recommended the 2^nd option.

I bought a set of 2 powerline adapters from D-Link for 150 EUR, just plugged them in and voilà. The adapters work fine with latency below 4 ms and very stable connectivity.

For the security aware: Homeplug AV uses AES encryption and my UPA solution only uses 3DES. I don't know if and from what distance neighbors could try to break into this network connection.

JMS Correlaton Patterns

A customer came up with the suggestion to use the CorrelationID pattern for correlating JMS request and responses. In this pattern, a client sets a (preferably unique) value in the JMSCorreleationID property of the request. The service copies request.JMSCorrelationID to reply.JMSCorrelationID. This was a way-of-working I hadn't encountered.

There are 2 main JMS correlation mechanisms that I had seen so far: 1) the MessageID pattern whereby the service copies the request.JMSMessageID to the response.JMSCorrelationID and 2) the use of temporary queues.

In the Enterprise Integration Patterns book, the use of the CorrelationID as a "Conversation Identifier" is confirmed. And indeed, the CorrelationID pattern has some nice advantages, e.g. the correlation can be based on some unique identifier the JMS client picks itself (e.g. from the payload), no need to keep an extra JMSMessageID as an extra state variable.

Unfortunately, the SOAP-over-JMS draft also prescribes copying the JMSMessageID of the request to the JMSCorrelationID of the response message. And this is e.g. what Spring-WS implements.

Book: Web Service Contract Design and Versioning for SOA

Just finished reading the early access version of the book "Web Service Contract Design and Versioning for SOA". Recommended book, well written!

As its title suggests, the primary focus is contract design. Less attention is paid to versioning. But the book goes into extensive detail wrt. XML Schema design, WSDL creation and use of related specs such as WS-Addressing and WS-Policy. Also the differences between different versions of e.g. SOAP and WSDL are well addressed.

This book really fills a gap: SOA books often remain at a too high level, standard WS development books dive directly into code and XML Schema books are unrelated to WS-*.

Every serious WS/BPEL/SOA developer or designer needs to have a good understanding of these base technologies, in particular XML schema. One of the better WS books since "Web Services Platform Architecture SOAP, WSDL, WS-Policy, WS-Addressing, WS-BPEL, WS-Reliable Messaging, and More".

Note: after reading such book, one must confess that WS-* is quite messy and more cleanup is needed; WS-I will need to write more or lengthier profiles!

HTTPS all the time?

Why don't web sites, web applications and web services use HTTPS by default? What prevents us from using HTTPS for all Internet communication? No more risk while accessing applications from public places such as hotels. No more risk of an ISP looking into your confidential network traffic.

Obviously, SSL takes some CPU power. I don't know how costly SSL is, but isn't this becoming negligible? On the other hand, there is SSL accelerator hardware being sold, so there must be some need for it.

Another challenge is the certificate management. Either services use one of the well known Certficate Authorities. But alternatively, clients should become better at managing self-signed server certificates or unknown CA certificates. Many client apps, including WS clients, would benefit from user friendly certificate and key mgt. No more Java keytool, but a user friendly configuration GUI.

XML gateways

If you're interested in learning more about XML gateways, 2 vendors provide reasonably detailed information. The technical documentation of CISCO's products is available online, both for their AON and ACE (ex-Reactivity) products. And IBM provides 4 Redbooks that go into quite some detail on DataPower. But other vendors such as Cast Iron, Layer7, Vordel and Intel (ex-Sarvega) all seem to consider their docs as a valuable assets not to be shared with the world.

Spring Integration is not an ESB

The Spring Framework is a popular application framework for Java Enterprise applications. Best known is its mechanism of "Inversion of control" or dependency injection. But the Spring Framework comes with many other features. Typically, Spring will define a clean set of interfaces and implementations on top of existing Java constructs.

Now, Spring is also popular in the world of integration: most open source ESB's - Mule, ServiceMix - are based on the Spring Framework. Recently Spring came up with its own "Spring Integration" sub-project. Although still in beta, this doesn't seem like a standard ESB. Rather, Spring Integration is more focused on integration "within" the application. Separating the integration logic from the business logic, but keeping it within the application itself. As such, one gets integration at the edges. In line with the Spring Framework itself, Spring Integration is obviously Java oriented, e.g. the Message object has a Java object as payload. It does not make any assumptions about payload format, XML or other. Spring Integration takes the Enterprise Integration Patterns book as a starting point, and that is something it does have in common with the many open source ESB's.

Another interesting sub-project is Spring Batch. This framework is focused on processing large data sets whereby the processing is split into multiple transactions and progress of batch jobs is maintained in database tables. This tool also comes with adapters and message conversion, but from a completely different angle.

Interesting to watch how the Spring team will grow these projects, along with Spring-WS and their upcoming REST implementation.