SCA/SDO go to OASIS

Posted by Mark Little on Mar 22, 2007

Sections

Development,

Enterprise Architecture

Topics

Web Services ,

WS Standards ,

Java ,

SOA

Tags

Standardization

In November 2005, IBM, Oracle and others announced the release of the Service Component Architecture, which they said was an implementation agnostic way to define and build applications using SOA principles. At the time many saw this as a threat to JEE, particularly when you consider that Sun was not involved in SCA and they have their own apparently overlapping JBI standard, from which IBM and BEA droped out. Since that time, the original authors have solicited feedback and added more co-authors on the specifications, but not much has been felt in the development community.

However, with the number of partners on the specifications growing to 18, they have recently announced that work on the specifications has been completed. Furthermore, rather than continue to work on these specifications behind closed doors, the authors also announced their intent to turn them over to OASIS for standardization, as well as to turn over the SDO 2.1 Java Specification to the JCP and restart JSR 235. BEA and IBM, the current co-spec leads for JSR 235, are working with Sun on a plan to resolve the current set of issues around JSR 235 and are committed to a solution that allows this work to be done in the JCP.

As the press release states:

The SCA and SDO specifications can help organizations to more easily create new and transform existing IT assets, enabling reusable services that may be rapidly assembled to meet changing business requirements. These specifications greatly reduce complexity associated with developing applications by providing a way to unify services regardless of programming language and deployment platform. Both are technologies designed to simplify the representation of business logic and business data. Early customers are already implementing and gaining value.

As seems usual these days, the specification authors chose to take the OASIS route towards standardization. Patrick Gannon, president and CEO of OASIS had this to say:

We applaud the Open SOA Collaboration for reaching this milestone and for choosing to take the next step and advance this important work through an open standards process. We look forward to furthering the evolution of SCA from specifications to standards and to promoting the broadest possible industry adoption through education and implementation efforts.

If previous OASIS efforts are anything to go by, don't expect a finished standard for about 12 months. These specifications are huge and unless the authors expect a rubberstamping excercise, the OASIS policy of allowing any and all comers to influence the evolution of specifications towards standards can lead to interesting (and long) debates in technical committees. Whether or not SCA/SDO continues to be seen as a threat to JEE, JBI and other technologies remains to be seen. The fact that Sun is now an author of these latest specifications and IBM/BEA are interested in working within the JCP on this effort indicates that some bridge building has been taking place. Or is it a case of "Keep your friends close but your enemies closer"?

1. Back to top

   JBI Overlap is minimal

   by Michael Rowley

   JBI is often mentioned as overlapping SCA. In my opinion the overlap is too small to worry about. It doesn't look like your links include this page, which does a good job of describing the relationship between the two technologies. [PLUG] If anyone wants to see my overview presentation of SCA, you can find it here. [/PLUG]

   Reply

2. Back to top

   Re: JBI Overlap is minimal

   by Mark Little

   Thanks for the reference Michael. Naming no names, but I think it's in some vendor's interests to portray this as a JBI versus SCA battle.

   Reply

3. Back to top

   Re: JBI Overlap is minimal

   by John Harby

   I think component is a wonderful concept for client side widgets like text boxes and radio groups but for the server-side it has never really seemed to work - think of all those people who were doing anything to bypass EJB and just use servlets. I prefer the old pre-CCM CORBA approach to be honest. Code that is shared across services can reside in libraries and be accessed using many different mechanisms. The term "component" even in the UML sense does suggest some constraints and dependencies which really seem unnecessary. I had thought the modern move to SOA would be replacing component with service anyway.

   Reply

• Older >