Last month an alliance of leading vendors announced progress on specifications to define a language-neutral programming model for application development in SOA environments. They call this specification Open SOA Collaboration. In essence, they are proposing a new standard to create and manage IT, making the process of integrating different third-party SOA technologies "less onerous," they say. Or, we can call this a standard way of delivering services, making it easier to work and play well together.

So, who's in the gang? BEA, IBM, Oracle, and SAP first got together last November to begin work on the common programming model, along with Iona, Sybase, Xcalia SA, and Zend Technologies Ltd. Others are joining the mix, including Software AG and Red Hat.

This group has concentrated its efforts on two projects - service component architecture (SCA) and service data objects (SDO). If this sounds familiar, it is. We've seen this type of standard with components, distributed objects, and, more recently, Java.

SCA is looking to provide a model for creating service components in a wide range of languages and a model for assembling service components in a business solution. In essence this is a standard that defines how services are created so they interact with each other without a lot of customization. This will benefit those who are looking to create composite applications that use these services.

SCA encourages an SOA organization of business application code based on components that implement business logic. It offers capabilities through services that consume functions offered by other components through services called references. SCA divides up the steps in building a service-oriented application into two major parts: The implementation of components that provide services and consume other services and the assembly of sets of components to build business applications by wiring references to the services.

SCA stresses decoupling the service implementation and service assembly from the details of the infrastructure capabilities and the access methods used to invoke services. SCA components operate at a business level, according to the spec.

SDO is looking to provide a consistent way of handling data in applications, whatever its source or format may be. Okay, that would be data abstraction. Moreover, SDO provides a way to unify data handling for databases and services.

It's clear that SDO is designed to unify the way in which SOA applications handle data. Using SDO, application programmers can uniformly access and manipulate data from heterogeneous data sources, including relational databases, XML data sources, Web Services, and enterprise information systems.

SDO is based on the concept of disconnected data graphs or a collection of tree-structured or graph-structured data objects. Under a disconnected data graphs architecture, a client retrieves a data graph from a data source, mutates the data graph, and then applies the data graph changes back to the data source.

Databases are connected to the applications by data mediator services. Client applications query a data mediator service and get a data graph in response. Client applications send an updated data graph to a data mediator service to have the updates applied to the original data source, and this architecture allows applications to deal principally with data graphs and data objects.

New? No. Interesting? Sure. We've seen these types of standards before with the rise of client/server, CORBA, and Java, all looking to provide standard mechanisms for developing SOA, or, the way we bind all of these things together to form applications. The SDA concept especially has been done to death, with some successes and some classic failures.

As always, the real battle to be won here is the developer's acceptance of these standards. For that, the vendors have to work together to implement the standards in the very same way...something that's been tough to do in the past. So they'll have to put aside their desire to stand out and focus on being the same...an unnatural act for most.

It will also be interesting to see where this standard goes in the context of BPEL and other standards that provide the same solution patterns. At the end of the day, standards are only useful if there's one for each problem pattern. So far in the world of SOA, we have three or more standards for each problem pattern. Those who consume the technology won't touch standards until the problem is solved. Once bitten, twice shy.