Web services were supposed to simplify the exposing and integration of functionality locked within the silos of software applications. And they were supposed to be the bridge by which Java and .NET logic could coexist.

But the devil's been in the details. Fulfilling this promise requires too much expertise in low-level plumbing, like chaining together a string of SOAP requests to various service definitions to execute a composite service. Or it required specialized knowledge of middleware and the structures of underlying data sources.

Recently, IBM, BEA, Oracle, SAP and others unveiled proposals for what they call Service Component Assemblies (SCA) and Service Data Objects (SDO). In effect, SCA and SDO apply many of the component design and assembly principles long taken for granted in the Java and .NET worlds to the composition of web services.

The announcement wasn't absent the usual round of hype. One vendor evangelist termed the proposals a deployment descriptor on steroids. Well, we won't go that far, but nonetheless, this could still become a potentially significant development.

Until now, there was a standards gap when it came to assembling compound web services. If you're a developer, you had to rely on the proprietary technology of your middleware, understand the data structure of the information related to the service, understand the content of multiple web services, then use BPEL (a standard for orchestrating multiple web services) to assemble what is in effect, a component.

BPEL is fine if the composition of a service is to vary by scenario. But what if you wanted to piece together a compound service component? Until now, you would have hit the donut hole, because there was nothing between the low-level "wire level" protocols for creating web services, and the sophisticated processes for conditionally orchestrating them.

As noted, the Java and .NET worlds solved this problem long ago with component architectures providing de facto standard APIs. You could readily compose services as long as they came from pure Java or Microsoft environments. SCA and SDO fill this gap by applying standard APIs to the platform-neutral web services domain.

The result will impact software developers rather than business analysts (who deal with processes, not components). If these proposals become standards, web services development will now fall inside the mainstream of modern software design principles, which are based on component architectures and object-oriented design. And for middleware, development, or process tools vendors, it provides a standard component architecture to make the logic and data underlying services more portable.

Of course this is all a big "if." The proposals originate from the usual Java suspects, although ironically, SCA and SDO have nothing to do with Java. And being preliminary, they have yet to find a standards body. The biggest question? Lacking Microsoft's imprimatur, the proposal will add rather than eliminate complexity.

Tony Baer, principal of onStrategies, is a well-published IT analyst with over 15 years background studying implementation issues in enterprise systems, application development, data management, and business intelligence. This piece first appeared in the onStrategies Perspectives newsletter. Read more of Baer's commentaries and rants on the state of the IT market here.