SOA standards remain a work in progress

The Organization for the Advancement of Structured Information Standards has established two technical committees to clarify industry understanding of SOA approaches.

In April 2004, OASIS created the Electronic Business SOA technical committee. In February 2005, OASIS chartered the SOA Reference Model (SOA-RM) technical committee. The overlap among these groups' charters is considerable, but the general division of responsibilities is as follows.

OASIS' ebSOA technical committee is defining reference architecture, guidelines and best practices for implementing SOA within business-to-business environments that implement ebXML standards. The technical committee is also defining the ongoing road map for OASIS' ebXML Technical Architecture, which is in Version 1.04.

The group is attempting to align the ebXML Technical Architecture with ongoing changes to the various ebXML standards, which address such business-to-business requirements as service brokering, reliable messaging, orchestration and trading partner agreements.

It is also addressing how ebXML standards will evolve to integrate more thoroughly with the growing range of Web services standards being defined at OASIS, World Wide Web Consortium and elsewhere. An ebSOA best practice document is promised for mid-2006.

OASIS' SOA-RM technical committee is defining a broader reference model that can encompass ebXML, Web services and other implementation environments. The group will release a first draft by the end of this year.

One of the SOA-RM technical committee's principal goals is to define a set of SOA concepts, functional elements, architectural patterns, and best practices that can be applied to different implementation environments. In addition, the group is drawing an important distinction between SOA use cases of varying complexity:

• Simple SOA: This involves a single shared service on which there are no requirements for reliable messaging, transactional rollback, long-running orchestration or QoS.
  
• Intermediate SOA: This involves multiple shared services that are presented to consumers through a single "root" or "façade" service; are hosted and managed within the same administrative domain; and may require transactional rollback, long-running orchestration and/or QoS.

• Complex SOA: This involves multiple shared services that are hosted and managed within one or more administrative domains, and that involve reliable messaging, transactional rollback, long-running orchestration, and/or QoS policies to be enforced in interactions among services.