WebServices dot org

In the first installment , Patrick discussed what’s driving the need for enterprise service buses.

One of the most compelling aspects of service-oriented architecture is that is completely neutral about technologies, platforms, and programming styles. An SOA isn’t necessarily built on a single type of language such as Java, or on a single type of application, or database. For that matter, an SOA doesn’t necessarily have to be built on XML Web services. SOA is meant to leverage any and all resources – no matter how they’re constructed and deployed – from across the enterprise.

Of course, abstracting processes from a diversity of systems is much easier said than done. Responding to this challenge, BEA Systems, along with several other leading vendors, announced support this past November for a specification that supports the abstraction of SOA-enabled applications from underlying infrastructures and implementations, be they based on Java, J2EE, C++, or even XML Web services.

SCA provides a model for the assembly of composite application development, which forms the basis of most SOA deployments, says Patrick. “If you look at all of the specs that are out there, there’s nothing that describes what a composite application is, or more importantly, what its dependencies are,” he says.

These composite applications may be based on collections of individual services. SCA addresses the need for control over access and security, while simplifying the development of creating business services and Service Data Objects (SDO) for accessing data residing in multiple locations and formats. “In the assembly specification of SCA [SCA 0.9 Assembly Model specification], you describe this composite app made up of all these services,” Patrick explains. “This allows us, for the first time, to have a standards-based way to describe services, dependencies, and the languages the services are written in.”

One of the key advantages of SCA is that unlike JBI (Java Business Integration), the specification is not limited to Java environments. “JBI is very Java-centric, and we believed that SCA needed to be neutral of any programming language,” says Patrick. In theory, SCA works with any and all languages, including scripting languages such as BPEL, XSLT, SQL, and xQuery. The code in the composite application would not change, even if the supported service were migrated from EJB to a Web service.

The SCA specification is even seen by some industry observers as an alternative to Java Enterprise Edition.

“We helped found the SCA standard because we saw something missing in the industry,” says Patrick. “We needed a service-definition language, not another Web service standard. Thus we have SCA. We need to be able to describe databases, message queues, or legacy apps in an SCA assembly, without tying it to Web services specifically.” SCA not only binds to Web services, but also supports bindings to other elements that may be part of SOA, including various messaging systems and CORBA.

By some calculations, there are more than 60 Web services standards being proposed, under review, or offered through a standards body. This has created a lot of confusion in the marketplace, Patrick observes. “Customers want to focus on business agility, and they really need is a set of blueprints, outlining the right standards to make their businesses work. “They’re turning and to vendors and saying, ‘Help, I’m not going to sit down and implement every one of these freaking standards. What are the ones I need to use to solve my business problem?’”

Through SCA, BEA and other vendors hope to provide clarity to SOA efforts that bring together the necessary resources from across the enterprise.

For detailed Webservices.Org coverage on the Service Component Architecture specification, click here .

More information on SCA can be found here .