Service Component Architecture(SCA) - Its all about assembly

We've been repeatedly saying that SOA is neither a technology nor a specification, but just an architectural approach in designing enterprise applications.

If that’s true, then how is it realized?

Is it with the help of services that follow those so-called SOA principles, and integrating them in a custom-fashion.

Yes, you may do that, but that becomes really difficult as the application and the number of underlying technologies grow

For this, you may require a standard way of assembling such things so that it simplifies and standardizes the overall lifecycle of the enterprise software.

Service Component Architecture is exactly that.

Similar to SOA, there is no standard definition to SCA. Some of the definitions that I would like to share are below

"Service Component Architecture is a specification that defines how various enterprise pieces are created and assembled together as modular components to increase IT sustainability and flexibility"

"SCA is a unifying framework for standardizing and simplifying the development, deployment and management of atomic service components"

"SCA provides a model for composing applications that follow SOA principles"

In simple terms, its like a platform on which you develop your SOA applications in a more standard, easier and flexible manner.

SCA is first started with a collaboration of major IT vendors under OpenSOA group, and later handed over to OASIS.

Anatomy of SCA

The SCA Assembly Model consists of a series of artifacts, which are defined by elements contained in XML files.

Following figure depicts various artifacts of SCA

 

The basic components of SCA are:

1. Composite : It is a single unit of deployment, irrespective of the complexity of the application.
2. Component : It is the unit which provides the business logic for the application. A composite contains multiple such components.
3. Services : Act as entrypoint to each of these components. Not all services can be accessed directly from outside the composite. Only those exposed to outside world specifically can be accessed directly. Those that can be accessed by outside world are called Promoted Services / Exposed Services
4. Reference : As the name suggests, is a reference to some implementation, either external to the composite or within it.
5. Wires : It is with wires that the components or services are bound/connect to each other
6. Properties : SCA leverages its implementation to provide customizations to the components through properties, which actually extend the standard functionality.

Apart from these, SCA also defines the non-functional requirements such as policy enforcement, QOS, etc.

Hope this post gave you a clear understanding of SCA.
In my next post, I'll go explain how Oracle has leveraged these concepts, on its implementation of SCA, the Oracle SOA Suite 11g.


Thanks for going through my post, feel free to provide a feedback!