BEA, IBM, Oracle, SAP, IONA, Siebel, and Sybase today announced their support for a new specification for building and packaging applications called Service Component Architecture or SCA – a specification that allows developers to focus on writing business logic.

More directly, SCA is "a deployment descriptor on steroids," that works with any language, not just Java. Moreover, you can use procedural languages and declarative language like BPEL and XSLT as well. The key difference is that it uses the notion of declarative policies for things like security, transactions and reliable messaging.

One thing that sets SCA apart is that it has been designed for SOA, unlike other systems, such as J2EE which has been adapted to it. It focuses on being able to describe assemblies of components which have been written in a variety programming models and protocols.

The goal of SCA is to make building applications easier. It allows the development off application assemblies without regard to specific middleware APIs or language.

At the heart of SCA is the notion of a service, and its related implementation. A service is defined by an interface which includes a set of operations. Service implementation can reference other services, called references. These services may have one or more properties which are data values that can be configured externally.

A key actor in the SCA universe is is the Service Data Object (SDO). SDOs are used to represent business data, parameters and return values of service invocations, and are a way to represent data as it travels across a service network. Note that XMLBeans and other technologies can be used as well.

SCA components are composed into assemblies. Assemblies are service level applications which are collections of services connected together and appropriately configured. An SCA assembly operates at two levels: First, assemblies are a set of loosely connected components connected within a system. Second, assemblies are a set of loosely connected components connected within a module. The distinction between the two is (roughly) that a module is a collection of components, and a systems is a collection of modules. Furthermore, a system corresponds to "programming in the large" or megaprogramming, and a model is "programming in the small", akin to building one of today's typical applications.

This wiring of components to the services they depend on is how service networks are "assembled." Assembly has been pioneered in a number of technologies and frameworks such as CORBA, J2EE, ATG Dynamo, and Spring; that is, it is nothing new. We have learned from these technologies that assembly provides important benefits (some of the frameworks mentioned do a better job than others at this) such as easier iterative development and avoiding making business logic dependent on middleware containers.

SCA uses the concept of assembly to solve key problems presented by SOA development including:

1. Separation of business logic from underlying infrastructure, qualities of service, and transport
2. Linking programming in the small with programming in the large
3. Providing a unified way to move to and from architectural design, coding, and operational deployment in a bottom-up or top-down approach.

It should be noted that companies like IBM and BEA have been shipping pieces of SCA, like SDO, for some time.

Why does SCA matter?

SCA matters, because this is the first technology that promises a compositional model that will enable the Service Network and allow the building of the next generation of service-oriented applications.

Each innovation in this field allowed a new layer of abstraction to appear which made new tiers of applications possible. C allowed applications to be built that could not be built in assembler, or whose effort would have been prohibitive. C++ allowed things to be built that could not be built in C. Java allowed things not possible in C++. All of these are progenitors to SCA. It appears that SCA is part of a promising future for building large-scale enterprise composite applications.

• BEA SCA Resource Center