|
While the SOA software industry clearly has room for many participants, at the enterprise-wide software grade, the usual suspects dominate
June 07, 2006
URL:http://drdobbs.com/web-development/enterprise-service-bus-part-2/188701721
Frank Teti is an industry analyst and principal architect. He can be reached at [email protected].
While SOA and Web services are standards based to a large degree, the Enterprise Service Bus (ESB) "specification" is wide open. That can be a good thing, but too many standards can hamper software developer productivity. An SOA, including an ESB, either using a commercial product, open source or custom made is key to having a truly scalable, enterprise-wide solution. A modern ESB is capable of dynamically transforming Web service payloads, in a deterministic way, through a metadata enabled, policy-driven, configuration environment and intelligently routing the messages to the corporate pipeline.
The SOA software industry clearly has room for many participants, at the enterprise-wide software grade, the usual suspects dominate.
BEA's AquaLogic Service Bus (ALSB) was the Network Computing's Editor's Choice during a vendor lab test of eight ESB suites with Oracle being the runner-up. However, this survey focused on core ESB features, not enterprise-wide features such as, ubiquitous integration, process management, workflow, and activity monitoring where IBM excels.
BEA ALSB is a comprehensive enterprise grade ESB, which could serve as the heart of your SOA infrastructure. BEA has combined messaging and management in a single environment. BEA enjoys a reputation in the J2EE software market for being out in front of the other vendors with respect to J2EE spec compliance. Now BEA has turned its attention to providing a comprehensive SOA infrastructure, while again supporting the important standards, such as, WS-Policy, WSDL, XQuery, WS-Security. BEA also has added a certain amount of there own technology to the SOA mix. In ALSB terms, pipelines have stages in which logical choices and transformations can occur. A transformation is where you need to change the format of the data from one type to another type or perhaps augment or even split the message/document in the bus. These transformations are part of a pipeline which is processing the message/document as it moves through various stages.
BEA, like IBM and Oracle, is starting to be able to leverage other components within it software portfolio. ALSB uses a lightweight version of WebLogic Portal for administration and operation. This is probably a plus for BEA, which in the past tended to put too much functionality in its application server, other enterprise grade vendors tend to have a more distributed approach to software engineering.
Even though BEA would consider itself to be a complete SOA infrastructure, architects will still see the need to augment the ESB with tool adapters, possibly more powerful transformation and extraction tools, specialized B2B components, and a possibly a another BPM engine, even though BEA recently purchased Fuego for BPM. BEA through its portal acquisition of Plumtree clearly sees the need to sell to business users, not just technologists, as I believe they have successfully done in the past. The SOA business model is an enterprise-wide model and has to be implemented with that type of scope, if it is to be successful. Only senior business analysts truly have that kind of perspective; BEA is now trying to woo that constituency.
IBM has, in reality, been in the SOA market for a long time. In some organization, the existence and use of MQSeries represents the ESB and for those organizations will remain an interim ESB. However, IBM has had a series of modern process orchestration tools starting with the acquisition of CrossWorlds, which was re-branded to WebSphere Business Integrator (WBI) and then Server Foundation, which really never got any traction. IBM has had a difficult time differentiating WBI from ETL type tools, given its large software portfolio.
Its current incarnation of ESB is Websphere ESB. Because IBM has a number of hardware platforms to support, IBM tends to make a market for there technology well in advance of a viable product being shipped. One brilliant strategic decision that IBM did make was to standardize its WebSphere tooling around Eclipse.
The next-generation, Eclipse-based tool is specifically designed to build and deploy business processes based on SOA. IBM states the tools are easy to use and require minimal programming skills. However, while IBM promotes its "on demand" abilities, in reality, it suffers from a reputation that always puts it squarely behind BEA with respect to ease of implementation. Indeed, understanding IBM's marketing terminology is perhaps a metaphor for understanding its software applications. In fairness to IBM, IBM eventually delivers a robust system that can be used for enterprise-wide deployment.
Oracle If you are an Oracle DB shop and your basic SOA system Use Case revolves around integration with disparate data sources, Oracle Fusion Middleware appears to be a solid platform. From a data-centric perspective, while vendors, such as, IBM and BEA focus on (XML) data analysis of in transit and data at rest using XQuery and XPath, Oracle BI and analytic capabilities are still centered on the DBMS. Oracle's Fusion Middleware does include SOA process and management, so a viable SOA infrastructure is achievable.
Perhaps Oracle's best strategic decision of the year was to not purchase JBoss, as was indicated by the rumor mill. EJB 3.0, JBosss area of specialization is a bloated spec that is encumbered by the need to support existing functionality (i.e. deployment descriptors) as well as new functionality (i.e. annotations), which JBoss viewed as mandatory even though the constructs do virtually the same thing. Today's architects are more interested in building services with lightweight data-centric containers. Oracle is now in position to acquire several of the more nimble SOA pure-plays in order to augment and complete its SOA offering.
Today, SOA and ESB is an area where there is maximum hype and minimum understanding regarding how the holistic model will be designed and implemented. In larger organizations, the enterprise architects may be planning to move to IBM or BEA in the future, but they are still in there own product evaluation and learning phases. Therefore, enterprising technologies within the organization are building a case for implementing "interim" custom solutions by wrapping Spring services or using other open source technologies, such as, IONA's Celtix, an open source ESB.
IONA's model is to give away its software and sell its professional services to "help organizations take advantage of open source and to ensure the successful adoption of SOA." While technologies like Spring and IONA represent the nuts and bolts of an SOA, companies such as Savvion are providing free copies of there Process Modeler. The tool provides model simulation and functionality for collaboratively building executable business processes. SOA is clearly not a packaged environment and one way or another an organization will have to assemble a certain amount of technologies and technical expertise to pull it off.
The OASIS SOA technical committees focus on creating standards to help interoperability for industry computing environments. OASIS doesn't provide a "how to" for developing the whole enterprise system from beginning to end. Each organization has to decide and tailor the appropriate software methodology for its purposes.
The OASIS SOA TC will develop a Reference Model. This is primarily to address SOA being used as a term in an increasing number of contexts and specific technology implementations. Sometimes, the term is used with differing--or worse, conflicting--understandings of implicit terminology and components. This Reference Model is being developed to encourage the continued growth of different and specialized SOA implementations while preserving a common layer of understanding about what SOA is.
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.
Develop a Service-Oriented Architecture Methodology
Use Spring Web Flow with IBM WebSphere Application Server 5.
Use Enterprise Generation Language in a Service-Oriented Architecture.
Terms of Service | Privacy Statement | Copyright © 2024 UBM Tech, All rights reserved.