Service Component Architecture (SCA) is a specification that describes a model for building applications and systems using the core notions of SOA. SCA encourages an organization of business application code based upon components that implement business logic, which offer their capabilities through service-oriented interfaces and which consume functions offered by other components through service-oriented interfaces, called service references.
When building SCA components, you need to move through two major steps. First, the implementation of service components provides services, as well as consumes other services. Second, the assembly of sets of components to build business applications, through the wiring of service references to services.
The objective of SCA is to emphasize the decoupling of service implementation and of service assembly from the underlying infrastructure, as well as the details around how the services are accessed. Thus, one may consider a SCA component as something that operates on the process level, and is not focused on the use of many underlying middleware services.
SCA is a language-neutral supporting service implementation written using any one of many programming languages, including JavaT, PHP, C++, COBOL, XML-centric languages such as BPEL and XSLT, and also declarative languages such as SQL and XQuery. What's more, SCA is also style independent, approaching programming using asynchronous and/ or synchronous.
SCA also promotes the use of Service Data Objects (SDO) to represent the business data that forms the parameters and returns values of services, providing uniform access to business data to compliment the uniform access to business services offered by SCA itself. The use of SDO provides a data abstraction infrastructure, allowing services to access information in ways and methods that are most logical for the purposes of the SOA.
Emerging from the dozens of SOA standards in the market place today is the Service Component Architecture (SCA) specification. SCA provides the foundation for defining common services by leveraging common data abstraction, and thus promoting both standard service design and reuse.
However, SCA unto itself is not a solution, and the technology you select that leverages SCA will make all the difference. Critical to the success of your SOA is not only the ability to design, deploy, and manage services using SCA, but to provide a runtime environment that allows those services to scale to transaction loads that the business demands, as well as provide enterprise-class reliability and durability that supports reuse by many points of consumption.
Key to this goal is to understand your own requirements and use cases, as well as select the right technology for the job. Indeed, most enterprises need technology that not only supports a standard, but takes that standard to the level of service required by the business.
This was first published in January 2008