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.
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.
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.
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.