Basic assembly model of Service Component Architecture (SCA)

Service Component Architecture (SCA) specifications started as a joint effort by mainly IBM and BEA in 2004 soon got more acceptances in 2005 when other software companies like Oracle, IONA, SAP AG, Sybase, Xcalia and Zend also joined the effort. As of February 2007, seventeen key vendors (http://www.osoa.org/display/Main/Service+Component+Architecture+Partners) are working together to define a specification that can be a version 1.0. It has almost all major J2EE middleware vendors on its board. Offcourse, you won’t miss an absence of Microsoft.

Specifications:

Version 0.9 (Nov 2005)

http://www.oracle.com/technology/tech/webservices/standards/sca/pdf/SCA_AssemblyModel_V09.pdf

Version 0.96 (Nov 2006)

http://www.osoa.org/download/attachments/35/SCA_AssemblyModel_V096.pdf?version=1

Upcoming specification 1.0

A service, in case of web service defined in WSDL, is a heart of Service Oriented Architecture (SOA). Service can be implemented using different languages like Java, C++, PHP, etc and many follow different interaction protocols. Often services interact together to offer a business solution (thus becoming an application). However, there was no standard way to specific this dependencies and to assemble them together to form a composite application. Sun Microsystems had provided JBI to address some of the needs needs. However, JBI is Java centric. So cross platform component architecture was much needed. That’s where SCA stepped in.

SCA provides a way to specify the interaction of services and assemble them together to form a composite application. The specification does not dictate any runtime implementation but, just like WSDL is in XML, it express an assembly of a composite application composed of services implemented using different technologies like EJB, web services, C++, PHP and invoking internal or external services via different protocols. Thus making a deployable assembly of services. With this modular and uniform assembly of disparate services, platforms built on SCA would definitely provide service-based applications that are easy to deploy, configure, monitor and move. Thus, would reduce a Total Cost of Ownership (TCO).

Basics design blocks of SCA assembly:

Composite: As expressed in fig 1, a basic container block of SCA assembly is a Composite. A composite is composed of Services, entry points, references and wires linking them together. Composite is expressed in XML and it does not replace the definitional artifacts of software’s implementing the services. Composite has an entry point expressed as a Java or WSDL interface. These interfaces can be bound to different protocols like SOAP over HTTP, JMS, JCA, etc via bindings.

Component: One basic artifact of SCA is the component which implements services in using different implementations like BPEL, EJB, Annotated Java, and PHP etc. The implementation types are specified in the components definition. Services, implemented by components, can be consumed by other components and external software. The components may have settable properties.

References: Services provided by Components may depend on other services. The service depending on is specified as a reference.

Wires: Wires links components to references or other components.

Fig 1. SCA System assembly (source: SCA specifications)

Fig2. SCA Composite Assembly (source: SCA specifications)

Note that, though SCA assembly provides wirings between components and can be graphically depicted as a flow, SCA itself is neither an orchestration engine like BPEL nor a workflow.

Note that SCA assembly model provides a loose coupling and flexibility to change. You may notice that a referencing service need not know the implementation type of the referenced service. It only knows the interface. Similarly, one can always change the wires or bindings thus offering a flexibility. With this module composition of services and their implementation, we may see an overall increase of productivity.

All of these can be assembled together to make a composite as:

In addition to SCA assembly model, SCA defines specifications for client and implementations, bindings and policies.

Client and Implementation specs: SCA provides Client API and service implementation specifications (Java, PHP, BPEL, etc).

Bindings: Access interactions with outside a composite are defined by bindings. SCA specifications are working on various bindings like WSDL, JMS, RMI-IIOP, REST, etc.

Policies: SCA also working on defining a framework to define policies like transaction, reliable mesaging, secutity etc.

In some later posts, I would drill down further into more details...
SCA 2.0