What every architect should now know about the Service Component Architecture (SCA)
The definition of ‘application’ is rapidly changing. As the industry is moving from using an application-centric architecture to a Service Oriented Architecture (SOA), the focus for building functionality is moving to Service Oriented Business Applications (SOBA). This means that applications are a set of services and components working together in fulfilling a certain business need. The technology, specifications, and standards for specifying these components and services may vary, and most often religious discussions are going on about the usefulness of each of them.
As regular readers may guess, my take would be to create these components and services in a model driven way using an approach to Model Driven SOA. However, even in that case you’ll need some kind of programming model that defines interfaces, implementations, and references. When building an application or solution based on services, these services can be both created specifically for the application and reused from existing systems and applications. Hence, we need a programming model that specifies how to create and implement services, how to reuse services, and how to assemble or compose services into solutions.
That’s exactly what the Service Component Architecture (SCA) is.
Structure of this article:
- Introducing the Service Component Architecture (SCA): the who and why behind SCA.
- Service Component Architecture specifications: explaining the four main elements of the SCA.
- Service Component Architecture concepts: explaining the concepts (e.g. composite, component, service, wire, binding, reference, etc.) of the SCA in detail.
- Deployment and the Service Component Architecture: contributions, clouds, and nodes.
- Implementations of the Service Component Architecture: an overview of existing SCA implementations (open source and commercial).
The SCA models the "A" in SOA. It provides a model for service construction, service assembly, and deployment. The SCA supports components defined in multiple languages, deployed in multiple container technologies, and with multiple service access methods.
The SCA consists of a set of specifications that define a model for building Service-Oriented Business Applications (SOBA). These specifications are based on the following design principles:
- Independent of programming language or underlying implementation.
- Independent of host container technology.
- Loose coupling between components.
- Metadata vendor-independence.
- Security, transaction and reliability modeled as policies.
- Recursive composition.
The first draft of SCA was published in November 2005 by the Open SOA Collaboration (OSOA). OSOA is a consortium of vendors and companies interest in supporting or building a SOA. Among them are IBM, Oracle, SAP, Sun, and Tibco. In March 2007 the 1.0 final set of specifications was released. In July 2007 the specifications were adopted by OASIS and they are developed further in the OASIS Open Composite Services Architecture (Open CSA) member section.
The set of specification can be split into four main elements: the assembly model specification, component implementation specifications, binding specifications, and the policy framework specification. I will shortly explain each of them in this section. In the next section I’m going to explain the concepts (e.g. what is a composite, what is a wire, etc.) of the SCA in more detail.
Assembly model specification, this model defines how to specify the structure of a composite application. It defines what services are assembled into a SOBA and with which components these services are implemented. Each component can be a composite itself and be implemented by combining the services of one of more other components (i.e. recursive composition). So, in short, the assembly model specifies the components, the interfaces (services) for each component, and the references between components, in a unified, language independent-way. I’ll explain these concepts in detail in the next section. The assembly model is defined with XML files.
Component implementation specifications, these specifications define how a component is actually written in a particular programming language. Components are the main building blocks for an application build using SCA. A component is a running instance of an implementation that has been appropriately configured. The implementation provides the actual function of the component and can be defined with a Java class, BPEL process, Spring bean, and C++ or C code. Several containers implementing the SCA standard (meaning that they can run SCA components) support additional implementation types like .Net, OSGI bundles, etc. In theory a component can be implemented with any technology, as long as it relies on a common set of abstractions, e.g. services, references, properties, and bindings. I’ll explain these abstractions in detail in the next section.
The following component implementation technologies are currently described:
- SCA Java Component Implementation V1.00 (PDF), XSD file
- SCA Spring Component Implementation V1.00 (PDF)
- SCA BPEL Client and Implementation V1.00 (PDF)
- SCA C++ Client and Implementation V1.00 (PDF), XSD file
- SCA COBOL Client and Implementation V1.00 (PDF)
- SCA C Client and Implementation V1.00 (PDF)
Binding specifications, these specifications define how the services published by a component can be accessed. Binding types can be configured for both external systems and internal wires between components. The current binding types described by OSOA are bindings using SOAP (web services binding), JMS, EJB, and JCA. Several containers implementing the SCA standard support additional binding types like RMI, Atom, JSON, etc. An SCA runtime should at least implement the SCA service and web service binding types. The SCA service binding type should only be used for communication between composites and components within an SCA domain. The way in which this binding type is implemented is not defined by the SCA specification and it can be implemented in different ways by different SCA runtimes. It is not intended to be interoperable. For interoperability the standardized binding types like web services have to be used.
Officially described binding types:
- SCA Web Services Binding V1.00 (PDF), XSD file
- SCA JMS Binding V1.00 (PDF), XSD file
- SCA EJB Session Bean Binding V1.00 (PDF), XSD file
- SCA JCA Binding V1.00 (PDF)
Policy framework specification, describing how to add non-functional requirements to services. Two kinds of policies exist: interaction and implementation policies. Interaction policies affect the contract between a service requestor and a service provider. Examples of such policies are message protection, authentication, and reliable messaging. Implementation policies affect the contract between a component and its container. Examples of such policies are authorization and transaction strategies.
In the previous section we’ve seen the different SCA specifications and what they describe. Let’s now look in more detail at the concepts of the SCA.
As stated before the main building block of a Service-Oriented Business Application is the component. Figure 1 exhibits the elements of a component. A component consists of a configured piece of implementation providing some business function. An implementation can be specified in any technology, including other SCA composites. The business function of a component is published as a service. The implementation can have dependencies on the services of other components, we call these dependencies references. Implementations can have properties which are set by the component (i.e. they are set in the XML configuration of a component).
Figure 1 – SCA Component diagram
Components can be combined into assemblies, thereby forming a business solution. The SCA calls these assemblies composites. As shown in figure 2 a composite consists of multiple components connected by wires. Wires connect a reference and a service and specify a binding type for this connection. Services of components can be promoted, i.e. they can be defined as a service of the composite. The same holds for references. So, in principle a composite is a component implemented with other components and wires. As stated before, components can in their turn be implemented with composites thereby providing a way for a hierarchical construction of a business solution, where high-level services (often indicated as composite services) are implemented internally by sets of lower-level services.
Figure 2 – SCA Composite diagram
The service (or interface if you like) of a component can be specified with a Java interface or a WSDL PortType. Such a service description specifies what operations can called on the composite, including their parameters and return types. For each service the method of access can be defined. As seen before, the SCA calls this a binding type.
Figure 3 – Example XML structure defining a composite
Figure 3 exhibits an example XML structure defining an SCA composite. It’s not completely filled in, but it gives a rough idea what the configuration looks like. The implementation tag of a component can be configured based on the chosen implementation technology, e.g. Java, BPEL, etc. In case of Java the implementation tag defines the Java class implementing the component.
SCA composites are deployed within an SCA domain. An SCA Domain (as shown in Figure 4) represents a set of services providing an area of business functionality that is controlled by a single organization. A single SCA domain defines the boundary of visibility for all SCA mechanisms. For example, SCA service bindings (recall the earlier explained SCA binding types) do only work within a single SCA domain. Connections to services outside the domain must use the standardized binding types like webservice technology. The SCA policy definitions do also only work within the context of a single domain. In general, external clients of a service that is developed and deployed using SCA should not be able to tell that SCA was used to implement the service, it is an implementation detail.
Figure 4 – SCA Domain diagram
An SCA domain is usually configured using XML files. However, an SCA runtime may also allow the dynamic modification of the configuration at runtime.
An SCA domain may require a large number of different artifacts in order to work. In general, these artifacts consists of the XML configuration of the composites, components, wires, services, and references. We of course also need the implementations of the components specified in all kinds of technologies (e.g. Java, C++, BPEL, etc.). To bundle these artifacts the SCA defines an interoperable packaging format for contributions (ZIP). SCA runtimes may also support other packaging formats like JAR, EAR, WAR, OSGi bundles, etc. Each contribution at least complies to the following characteristics:
- It must be possible to present the artifacts of the packaging to SCA as a hierarchy of resources based off of a single root.
- A directory resource should exist at the root of the hierarchy named META-INF.
- A document should exist directly under the META-INF directory named ‘sca-contribution.xml’ which lists the SCA Composites within the contribution that are runnable.
A goal of the SCA approach to deployment is that the contents of a contribution should not need to be modified in order to install and use the contents of the contribution in a domain.
An SCA domain can be distributed over a series of interconnected runtime nodes, i.e. it is possible to define a distributed SCA domain. This enables the creation of a cloud consisting of different nodes each running a contribution within the same SCA domain. Nodes can run on separate physical systems. Composites running on nodes can dynamically connect to other composites based on the composite name instead of its location (no matter in which node the other composite lives), because they all run in the same domain. This also allows for dynamic scaling, load balancing, etc. Figure 5 shows an example distributed SCA domain, running on three different nodes. In reality you don’t need different nodes (and even different components) for this example, but it makes the idea clear.
Figure 5 – A distributed SCA domain running on multiple nodes
The SCA is broadly supported with both commercial and open source implementations. To give you an idea I’ll list a few them below.
Open source implementations:
- Apache Tuscany (official reference implementation). The current version is 1.4, released in January 2009. They are also working on a 2.0 version which they aim to run in an OSGi enabled environment.
- The Newton Project.
- ActiveMatrix Service Grid from TIBCO.
- Oracle Tuxedo.
- IBM WebSphere Application Server Feature Pack for SCA.
Do you have experience with one of these products? Do you use SCA in practice?