OSOA Home

Introduction

The Service Component Architecture (SCA) is an effort by a number of major software vendors to simplify building Service-Oriented Architectures (SOAs).  The companies have founded the Open Service Oriented Architecture organization (osoa.org) to host the specifications for SCA.

In particular, we'll focus on three aspects of an SOA here:

• Composition - If you have a software component, how do you package it so that other applications can use it? 
• Assembly - If you have components that need to work together, how do you put them together?
• Policy - If you want to restrict access to a component or require a digital signature, how do you do that?

All of these tasks have become much more difficult as SOAs have grown in complexity and maturity.  There are many enterprise APIs, persistence frameworks, networking protocols and programming languages.  This complexity makes it difficult to build a flexible SOA that meets the needs of your organization.  SCA provides a single API that hides the underlying details, making development simpler. 

To put SCA in context, we'll talk about Service-Oriented Architectures and how they've evolved.  After covering the basics of SOAs, we'll look at the ways SCA can save you time and money, increase reuse and improve system management.

Conceptually, an SOA is simple; you have a software component, you package it as a service, and other components can use your service.  In the early days of Web services, many organizations used them in a haphazard way.  You decided to package a component as a SOAP service just to see how the technology works.  You mentioned your service to me while we were chatting at the water cooler, and I started using it.

A Quick Overview of SCA

There are four major parts to the SCA effort; we'll discuss them here and point out how they simplify life for developers, administrators and architects.

Assembly

Assembly defines how components are packaged as services.  It also defines how components can be combined into composites, a group of components that perform a particular task.  A composite lets you take a group of components and treat them as a single service; that makes reuse much simpler.  If you've built a set of services to check a customer's credit, you can package those services as a composite, then use that composite in any application in which you need to check a customer's credit.

The Assembly spec also defines how to wire components and composites together.  Accessing a given service might require data encryption, authentication or using a message queue.  SCA lets you define those details outside the code of the service, so you can change them without changing your code.

Business value: SCA makes reuse much simpler, which in turn makes reuse more likely.  If a given business function is implemented as a composite, every application that needs that business function simply reuses that composite.  SCA also lets you define properties of a service without changing the service; that saves your developers' valuable time as well.  

Client and Implementation Model    

The client and implementation model defines how services are packaged and accessed for various languages.  If you work in Java, there is an API that defines how to package your Java code as a service, and there is an API that defines how to access any SCA service.  There are currently client and implementation models for Java, BPEL, C++ and the Spring Framework.  (More models are on the way from osoa.org.)  

For developers, that means there's one interface to learn, and that one interface can use any component that's packaged with SCA.  You can use Web services, JMS, JCA and EJBs with the same code.
 
As with assembly, you can define the properties of your services outside of the code.  Those properties can define how the service is accessed or initialize values in the service itself.

Business value:  SCA gives developers a single interface for services written in a variety of languages and architectures.  A single interface means less time training and more time doing productive work.

Policy Framework

Previous standards efforts in the Web services space, WSDL in particular, didn't include how to define policies for security, authentication, quality of service and other important aspects of a service.  The SCA Policy Framework uses the open standards WS-Policy and WS-PolicyFramework to describe policies.

An administrator can define that any data sent to a given service must be encrypted.  An administrator can define that the user of a given service must be authenticated before the user can access the service.  As with all aspects of SCA, the policies can be defined outside the actual code of the service, which means a change to a policy doesn't require any change to the service itself.

Business value:  The ability to define policies outside the services themselves lets administrators set and change the policies without changing code. It also means administrators know their policies are implemented globally. 

Bindings

Bindings specify the mechanisms to access particular kinds of components.  Applications built with SCA can use Web services, JMS, JCA and EJBs.  (More bindings are on the way from osoa.org.)  As you would expect, the bindings can be defined outside the code itself.

Business value:  The bindings provided in SCA allow developers to use a wide variety of services without knowing the details of how those services are accessed.  With the bindings external to the code, the bindings can be changed without changing the code. 

Summary

We've discussed the various parts of the SCA specification here.  All of them focus on a single API and a single way of assembling applications.  As your SOA becomes more complex, you'll need the simplicity and flexibility of SCA.  The Service Component Architecture helps you:

• Save time and money - A simpler API means a shorter learning curve with fewer errors.
• Enable and encourage reuse - Developers can create composites that perform useful functions.  SCA makes it easy to use and reuse them.
• Manage your system - Because policies can be defined outside the code that performs the service, you can change the policies without changing the code. 

SCA simplifies the workload of developers, administrators and architects, freeing them to work on things that add value to your business.