Since SOA is hot, many presentations were devoted to differents aspects of services. The adoptation of services is growing rapidly. This requires standarization in the way we handle services within Java/JEE. J2EE 1.4 addresses standarization for webservices. Current initiatives like JBI (JSR-208), SCA, SDO (JSR-235) and data binding (JSR-227) focus on the abstraction and generalization of services to encapsulate implementation details. I am especially interested in the relation between data binding, JBI, SCA and SDO, but did not manage to have a clear picture yet. Data binding seems to aim at the front-end, JBI and SCA are focussed on the abstraction of services while SDO’s kind of operate in between. Since the main vendors are backing these standards I suppose they will be the upcoming standards.
Java Business Integration (JBI): The Technical View
JBI may be the upcoming standard (JSR-208) for service abstraction. It will offer a standardized integration architecture to encapsulate and hide the implementation. JBI is message-based and uses Web Services Description Language (WSDL) to describe the services. The JBI environment has two main building blocks: the service engine and the binding component. The service engine encapsulate the actual service, which can be of any technology, while the binding component provides the connectivity external to the JBI environment. This concept is much alike the ESB concept as described below.
More info:
Service Data Objects (SDO)
Started by IBM and Bea, all the main vendors are involved in JSR-235. The aim is to provide a unified way to access data from a variety of disparate sources like relational database, XML, EJB components, web services etc. Diving into too much detail, the presenter failed to give a clear overview of what SDO’s are and what their position will be within a J2EE architecture. Although he demonstrated some features like the XML options to access the data using XPath, this didn’t clarify the concept to me and I got even more confused when he started talking about the static and dynamic API’s. Although I have the impression that this is an important subject I am also afraid that is does not make the J2EE world any simpler.
How the Enterprise Service Bus Delivers on the Value of SOA
David Chappell can be, more or less, considered as one of the founders of the ESB concept. As an ESB evangelist he did not speak about Java, but about the ESB in general. He started sketching out the ‘alternatives’ for the traditional spaghetti architecture or, as David calls it, the ‘Integration Hairball’ or the ‘accidental architecture’:
1) Traditional enterprise integration based on an integration broker hub that offers all the required functionalities in a monolitic hub and spoke model.
2) The applicationserver that is good in serving web applications and hosting Business Logic, but fails in integration.
3) Webservices that offer interoperability, are implementation independent but do not offer a solution for the spaghetti architecture.
An ESB is an implementation of a Service Oriented Architecture and combines the best from the alternatives. It’s keywords are loosely coupled, distributed, reuse and course grained. All services are deployed in so called service containers and are connected to the messaging system, the heart of an ESB, thus enabling the services in an implementation independent manner. JBI will certainly take play a big role in this part of the ESB.
The ESB is more than a concept. Sonic offered the first implementation, and currently all the big vendors like IBM, Oracle, Bea are developing ESB products. And off course, also the open source community is participating with the very mature product Mule.
