One problem with SOA is that the first initial does not yet stand for “Simple”, as was the case for SOAP, the Simple Object Access Protocol — even though SOAP quickly became quite complex itself over time. Distributed systems are inherently complex and marketing hype can only go that far.

Part of the problem is that services do not freely fall from the sky, but rather have to be built from objects deployed on existing IT systems. For many organizations, this is achieved using development platforms such as J2EE, which itself adds quite a bit of complexity to the picture. Most of the J2EE stack has been developed prior to the emergence of the concept for a Service Oriented Architecture, and as a result is more object oriented than service oriented. This gap was supposed to be addressed by specifications such as JBI (JSR 208), but competitive issues very well described in Ian Thomas’ recent post prevented wide industry adoption.

IBM, BEA and a host of other vendors recently announced yet an other attempt at addressing the issue: the Service Component Architecture (SCA) and Service Data Objects (SDO) specifications, which “aim to provide developers with simpler and more powerful ways of constructing applications based on SOA.” In a perfect world, Microsoft and Sun Microsystems would have been part of this effort and things would indeed have become simpler. In the world we live in though, Microsoft will not be part of this work and Sun Microsystems will keep promoting JBI and others specifications that largely overlap with SCA and SDO. But because this overlap is not perfect, one cannot just wish that one camp will win over the other and life will be good again.

Without getting into too many details, JBI does two things: One, provide a component architecture similar to SCA. Two, provide a way by which specific containers such as an EJB container, a Servlet container or a Process container can be deployed on top of multiple J2EE application servers. The later is no addressed by SCA or SDO, and therefore makes something like JBI necessary for any software vendor looking for portability across application servers. Even though vendors such as IBM and Oracle have little interest in such a thing, the rest of the industry, including customers, would benefit from this portability. As steward of the J2EE platform, it is Sun Microsystems’ responsibility to make it happen. At this stage of the game, my advice to Sun would be the following: adopt the SCA and SDO specifications, rewrite JBI accordingly and deliver an Open Source implementation certified for the major J2EE applications servers, including BEA WebLogic, IBM WebSphere and Oracle Application Server. This would make a lot of things a lot simpler for a lot of people.