Pushing the Edge of Technology
I know of an insurance company that was analyzing 300 slightly different transformations and they wanted to know if there was a way in which a vendor purchased ESB could either template or build transformations on-the-fly. Basically, they wanted to create XQueries, based upon a set of business rules and make the transformation process totally dynamic. There are a number of ESBs that would be appropriate here that support XQuery. For example, XQuery is used in several of BEA products: WebLogic Integration, ALSB and Data Services Platform. Essentially, the operative words that surface the need for a service bus are routing, transformation and mapping. The open question then becomes is it for enterprise use or is it needed for one specific department. I find that many architects are now grappling with this decision and that if the need is departmental, then it does not require an ESB.
Savvy architects today tend to look for certain distinct patterns that indicate the need for a Web service or ESB. Currently, I am working with a major healthcare provider that is interested in significantly enhancing an existing application that routes and queues open claims and claims adjustments to a number of claims management systems. Claims data is routed based on certain business rules (that is, area of expertise, training, dollar amounts, and so on) to adjusters. There is limited transformation required. Additionally, new requirements state a need to access an external environment for provider reference data. This clearly indicates the need for a Web service.
Managers on the project envision the new application as a significant modification of the existing J2EE application that is five-years old, from a software perspective--this is a lifetime. I see the need for a modern ESB, given the non-standard constructs used in the existing system, such as, threading, lack of separation of business logic from the presentation layer, polling versus MDB-style listeners. We are still in the design phase, so a decision regarding the reference architecture is still under way. I'll keep you posted on the outcome.
A recent Network Computing poll indicated that there are eight significant ESB vendors worth considering: BEA, Oracle, Tibco, Fiorano, Cape Clear, IBM, Software AG and Sonic. Out of that list, the top three were BEA, Oracle, and Tibco. An important evaluation criteria was price. This is where an IBM fares poorly against the rest of the group; surprisingly, though, BEA had a strong rating in the price category. As is the case with most enterprise-wide software decisions, if you are an IBM or Oracle shop that fact will tend to further bias your decision. Still, an SOA is a long term decision and needs to be in alignment with your strategic direction.