Service Component Architecture – an SOA Implementation?

In one of our previous article, we wrote about Service Oriented Architecture and Cloud Computing Services.  We obviously cannot talk about SOA and not mention Service Component Architecture or SCA.

Background behind Service Component Architecture

An informal group comprising of leaders from software vendors like IBM, Oracle, TIBCO, etc have founded the Open Service Oriented Architecture Organization (osoa.org) to promote and develop Service Component Architecture specifications.

What is SCA?

OSOA defines Service Component Architecture as a set of specifications that describe a model for building applications and systems using a Service-Oriented Architecture. SCA extends and complements prior approaches to implementing services, and SCA builds on open standards such as Web services.

In short, SCA is implemented using Service-Oriented Architecture. Is this a misnomer? Well, to understand that, we need to look into SCA in a little detail

The three main aspects of SCA are:

  • Composition – defines how software components fit into the composite applications.
  • Assembly – defines the structure for the software components that need to work together.
  • Policy – defines the access to the software components in the application.

This illustrations shows how these fit to form an application implemented using SCA –

Composition

An SCA application comprises of logical constructs termed as composites. Each composite encompasses components, services, references, bindings, wires, promotions, and properties. A complete application can consist of one composite or several composites as seen above. A domain is a larger construct that contains composites and components. A domain can contain composites defined across one or more machines, but a composite cannot span across domain boundaries.

Assembly

Every composite has the same structure as shown below –

A component implements business logic that is exposed through one or more services. It interacts with services from other components through references. Services and references are the communication gateways between clients and other components. Wires connect references in one component to services in other components. A composite’s creator can promote services to make them visible to the outside world.

Bindings define the mode of communication between services and references. They can be Web service, JMS, or EJB Session Bean bindings. See illustration below -

Policy Framework

As SCA allows creation of distributed applications, it is important to specify how the parts will interact with each other.  The SCA defines a policy framework. This framework defines two broad categories of policies – Interaction policies and Implementation policies. The interaction policies govern the interaction of components with each other, while the implementation policies modify how a component behaves locally.

This is how it all looks together -

How does SCA differ from SOA?

From the above explanation, it is obvious to see that labeling an SCA application as an implementation of SOA is a misnomer. We now shall see how these two differ -

Service Oriented Architecture Service Component Architecture
Applications based on Services Applications comprise of domains, composites, components. Services are contained in a component.
The SOA standards do not restrict applications to a single vendor. Anyone can develop, register, and invoke a service. Although, one can develop distributed SCA applications, composites cannot cross vendor boundaries. All components of a composite must run in a single vendor’s SCA environment.
Interactions between services happens in a well-defined shared format using messages or other communication protocols Communication between composites and components within a domain are vendor-defined. Communication with a non-SCA application is through Web services or some other interoperable protocol.

In conclusion, SCA despite its complex implementation specifications is an interesting technology. It offers an alternative way to create business logic for a service-oriented world. If you have any thoughts on this concept, do let us know. You can leave your feedback, suggestions, or both for us in the comments section below.

 

Leave a Reply

Your email address will not be published. Required fields are marked *

*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code class="" title="" data-url=""> <del datetime=""> <em> <i> <q cite=""> <strike> <strong> <pre class="" title="" data-url=""> <span class="" title="" data-url="">