Simplifying Composite Applications with Service Component Architecture

Service Component Architecture (SCA) is a set of specifications which describe a programming model for building composite applications. Version 1.0 of the specification—released in March, 2007 by IBM, Oracle, Red Hat, and the other 15 members of the Open SOA Collaboration—provides developers a way to apply the SOA principles of component reuse, flexibility, interoperability, and standardized interfaces to application design and development. SCA extends and complements the principles of composite application development, providing the specifications for a model for that process.

While many IT organizations have been practicing some form of composite application development over the past few decades, an organization's development maturity and requirements are usually the prime determinants of the composite programming model used. Regardless of how a composite application is built, all of them require three pieces of information at runtime:

1. The interface of the component
2. The implementation of the component
3. The access method of the component

To put it another way, at runtime the application has to know what the component can do (method names, arguments, and so forth), how the component was written (Java bean, EJB, Perl script or something else) and how to communicate with the component (SOAP over HTTP, RMI, JCA, etc).

In the earliest architectures for component development, the application had to know all three things at build time. All of those details were hardwired into the application, and any changes required rewriting, retesting and redeploying the code.

With the advent of Web services, the component implementation was abstracted away. The SOAP infrastructure meant you didn't have to know how the component was written—SOAP handled the details of communicating with the Java bean, the EJB or the Perl script, freeing the application developer to focus on more important things. And while a good SOAP toolkit could handle some of the details of the access method for you, and the Web services and the SOAs that host them became more complicated, a number of issues arose:

• Access methods other than SOAP over HTTP emerged.
• Some Web services required the SOAP envelope to be encrypted and/or digitally signed.
• Some Web services were asynchronous (SOAP over JMS, for example).
• Some Web services required authentication.

None of this information existed in the WSDL file associated with the Web service, which once again meant any changes in the areas mentioned above once again required the composite application to be recoded, retested and redeployed. While Web services and SOA promised application flexibility, it never went far enough to deliver on that promise.

And that's where SCA comes in.

In a composite application written with SCA, the access method is handled by the infrastructure as well. (It's important to note that in the world of SCA, "access method" includes policy details such as encryption and authentication as well as the protocol.) If an administrator decides to change the underlying service or the policies for accessing it, the SCA runtime handles those details. The administrator changes the service definition one time, in one place, and the applications simply use the new definition. None of the applications have to be rewritten, retested or redeployed; they simply work.