Service Component Architecture (SCA). SCA vs SOA

Service Component Architecture (SCA)

It's a set of specifications that defines an assembly model model for composite services and also provides a programming model to build applications which are SOA-based.

A composite service can have serveral business processes, bindings, properties, human workflows, etc. all put together. We define a Composite and once the Composite is ready it's for you to be treated as a single component and can easily be exposed as a composite service the way you expose a web service.

SCA makes the deployment design very easy. Suppose your application have n business processes and let's say BP-1 is the entry point to the application then you can define a composite by specifying the navigation details among the various business processes and/or human workflows and then you can expose BP-1 as a composite service. Now, the composite service is having a well defined assembly of all the components involved in your application and ready to be deployed. You don't need to deploy the individual components separately. All will be handled by SCA. All the assembly information is stored in an SCA Descriptor.

SCA vs SOA

SCA focuses on the assembly of various components to provide an easier design and deployment while SOA provides an architecture or style to design and develop the individual components. SCA comes into pictures only when you're ready with all the components. So, you create components with SOA and assemble them using SCA mainly to make the deployment easier.