Open SOA

by Mike Rosen, Director, Cutter Consortium Enterprise Architecture Practice

In February, I wrote about service component architecture (SCA) and service data objects (SDO) (see "Service Component Architecture," 1 February 2006, and "Service Data Objects," 15 February 2006), which are emerging specifications for how services can be written and assembled in an industry-standard way. At that time, eight companies had joined together to create and support these specifications. Let's see how this effort is progressing.

In August 2006, an additional nine companies signed on and the Open SOA Collaboration was born. Its Web site, www.osoa.org defines the collaboration this way: "The Open SOA Collaboration (OSOA) represents an informal alliance of industry leaders that share a common interest: defining a language-neutral programming model that meets the needs of enterprise developers who are developing software that exploits Service Oriented Architecture characteristics and benefits." Early holdout Sun Microsystems has now joined the fray, but Microsoft stands out as a notable, nonparticipant. Of course, this really shouldn't surprise anyone, since Microsoft is not known for its participation in standards.

OSOA also said, "While it is not practical for every interested company to commit the resources to get deeply involved in the day to day activity of writing the specifications, we recognize that there is a class of company, organization and individual who may wish to contribute in a smaller way." Thus, a second level of membership was created, called The Open SOA Supporter's Community, which now includes 10 companies. One such company is Paremus Corporation, which announced that its infrastructure will eventually support SCA. Here's what Paremus's CTO had to say: "The emergence of SCA is industry recognition of the limited value and applicability of traditional Web services within the enterprise. Rather than marginalizing Java, we believe that SCA will help free businesses from the confines of stove-piped monolithic legacy Web Services & EJB application paradigms."

I find this a rather interesting interpretation of SCA. It seems like license to hop onto the SOA bandwagon without having any Web service capabilities. I've always said that SOA does not require Web services, but this is the first product renaming I've seen around SOA without them. It also supports my belief that at this point in the lifecycle, marketing is a major driver for companies to claim support of OSOA.

When I first read about SCA, I wondered whether it was a solution looking for a problem. I wondered why a language-neutral approach to service assembly was necessary. Remember that SCA is not about orchestrating smaller services into composite services. For that we have BPEL. Certainly, programmers are not going to be mixing Java, perl, php, etc., within the same executable service. But my friends at SAP (a contributor to OSOA) explain it this way. Most programming environments, regardless of language, face a similar problem with regards to constructing services. So, why not have a standard way to do it that can be shared across different languages. When you consider a multipurpose, multilanguage development framework like Eclipse, this really does make sense. The same SCA plug-in could be used for many different languages.

Of course, other opinions about SCA exist as well. David Chappell, well-known author about things related to Microsoft, in an interesting article called "What Next? Life after J2EE" thinks SCA represents a fracturing of the Java landscape. He agrees that it represents an acknowledgement that EJB is not a useful programming abstraction for services.

But, at the same time, implementations of SCA and SDO are beginning to emerge. The OSOA Web site lists five different implementations of SCA, including the mainstream product IBM Websphere Application Server. The site also lists seven implementations of SDO, including major vendors IBM, BEA, and SAP. Apparently, unlike SCA, which introduces a new mechanism, SDO maps more readily to existing data access methods supported by development tools. And don't forget the open source community. Apache claims to be putting a lot of effort into implementation.

So what's a service developer to do? At this point, I think a wait-and-see approach is prudent. And, since there are relatively few tools that support SCA or SDO, it's hard to do otherwise anyhow.

-- Mike Rosen, Director, Cutter Consortium Enterprise Architecture Practice