Introducing Service Component Architecture (SCA)
For the past twelve months, I have been involved with the Service Component Architecture (SCA) specifications and two of the open source SCA implementations. Now that SCA is gaining industry traction, I would like to use my weblog here to introduce the technology and demostrate how SCA can be used for building standards-based enterprise class applications using service orineted principles and paradigms, through a series of weblog entries covering both the theory and practical aspects of SCA.
In the past few years SOA has evolved into one of the most prevalent architectural paradigms in building enterprise class middleware applications. Despite its wide spread adoption, SOA has pretty much stayed a vague set of principles, interpreted differently based on the perspective of the interpreter. More than often practitioners use the terms SOA and Web Services invariably, even though, web services based technologies are only one of the means of realising service-oriented architecture.
There has been a significant lack of standards and specifications that provide prescriptive and definitive guidelines into how service-oriented business applications are to be developed. However, with the inception of Service Component Architecture (SCA) by OSOA, SOA has been made a realistic proposition for enterprise developers and architects. SCA is now being ratified under the OASIS Open Composite Services Architecture (OpenCSA) initiative.
What is SCA?
SCA is a set of specifications, addressing both runtime vendors and enterprise application developers and architects, for developing applications based on service oriented architectural principles and paradigms. SCA advocates a compositional architectural pattern for building enterprise class service oriented applications. It addresses the assembly of both fine-grained tightly coupled and coarse-grained loosely coupled components. SCA composition is based on recursive assembly where fine-grained tightly coupled components are composed together to build coarse-grained components. These coarse grained components can be used in a higher-level contexts to build even coarser grained components and enterprise applications.
SCA Key Concepts
The key SCA concepts are,
SCA assembly model primarily defines the recursive assembly of components into services. The recursive assembly allows fine-grained components to be wired into what in SCA terms is called composites. These composites than can be used as components in higher-level composites and applications. The type of a component generally defines the services exposed by the component, properties that can be configured on the components and dependencies the component has on services exposed by other components.
The diagram below shows an example of an SCA assembly model,
In the diagram above Composite X is composed of two components Component Y and Component Z, which themselves are composites. Composite X exposes its service using web services.
Composite Y is composed of a Java component, a Groovy component and a Jython component. The service offered by Java component is promoted outside the composite. The Java component depends on services offered by the Groovy and Jython components. In SCA terminology these dependencies are called references. All the references for the Java component are satisfied by services offered by other components within the same composite. However, the reference on the Groovy component has been promoted outside the composite and will have to be satisfied in a context within which Composite Y is used as a component. In the diagram above this is achieved using the service promoted by Composite Z.
Composite Z is composed of a Java component, a BPEL component and a Spring component, the service offered by the BPEL component is promoted to be used when the composite is used as a component in a higher level composite.
As you can see SCA allows building of compositional service-oriented applications using components built on heterogeneous technologies and platforms. SCA assembly model is generally expressed in an XML based language called Service Component Description Language (SCDL).
Client & Implementation Model
SCA client and implementation (C & I) model describes how components, services, references etc are represented, defined and packaged in multiple languages and technology platforms. The current SCA suite of specifications cover the client and implementation model for Java, Spring, BPEL, C++ etc.
SCA bindings enable services and references to be accessed over multiple transport and data binding protocols. The current SCA suite of specifications cover bindings for Web Services, JMS, EJB etc.
Intents and Policies
The policy framework is one of the key aspects of SCA. Policy framework allows Quality of Service (QoS) aspects to be defined, managed, enforced and governed, orthogonally to component implementations and assembly using declarative intents and corresponding policy sets. Like all the other SCA aspects, policy framework is highly extensible as well. Policy framework allows policies to be defined using standard mechanisms like WS-Policy or using your own policy language.
Note: I will cover SCA assembly model, client & implementation model, policy framework and bindings in detail later.
Current SCA Specifications at OpenCSA
The current set of SCA specifications hosted on the OSOA site includes,
SCA Assembly Model
SCA Policy Framework
SCA Java Client & Implementation
SCA BPEL Client & Implementation
SCA Spring Client & Implementation
SCA C++ Client & Implementation
SCA Web Services Binding
SCA JMS Binding
SCA provides a set of specifications, addressing both runtime vendors and enterprise developers/architects, for building service-oriented enterprise applications. For the first time we have a set of specifications that address how SOA can be built rather than what SOA is about. I have provided a bird's eye view of SCA as a technology. In the coming days I will cover in further detail each aspect of SCA as well as practical examples on building SCA based applications using one of the open source SCA runtimes I am heavily involved with, Fabric3.