Introduction

Service-Oriented Architecture (SOA) is a framework that combines individual business functions and processes, called services, to implement sophisticated business applications and processes. In a SOA framework, relatively coarse-grained business components are exposed as services. SOA structures IT assets as a series of reusable services, which are loosely coupled and are platform- and implementation-neutral. SOA designs solutions as assemblies of services, which are connected through well-specified interfaces and contracts.

Service Component Architecture (SCA) is a specification which describes a model for building applications and systems using a SOA . It simplifies application development and implementation developed using SOA.

Motivation

SCA simplifies the creation and integration of business applications built using a SOA. SCA provides a mechanism to build coarse-grained components as assemblies of fine-grained components.

SCA relieves programmers from the complexity of traditional middleware programming by abstracting it from business logic. It allows developers to focus on writing business logic and can free them from the need to spend significant cycles on more low-level implementation techniques.

Some advantages of the SCA approach are:

• Simplified business component development
• Simplified assembly and deployment of business solutions built as networks of services
• Increased portability, reusability, and flexibility
• Protection of business logic assets by shielding from low-level technology change
• Improved testability

SCA architecture

SCA divides the steps of building of a Service Oriented Application into two major parts:

• The implementation of components which provide services and which consume other services
• The assembly of components to build the business application through the wiring of service references to services

SCA offers a mechanism to package and deploy sets of closely related components, which are developed and deployed together as a unit. It decouples service implementation and assembly from the details of infrastructure capabilities and from the mechanisms for invoking external systems. This enables portability of services between different infrastructures.

Service implementations and service clients

Service implementations are concrete implementations of business logic, which provide services and/or consume services. These implementations use any one of many implementation technologies, such as Java™, BPEL or C++. The implementation is the servant of the business process.

An implementation can provide a service, which is a set of operations defined by an interface used by other components. Implementations can also use other services, called service references, which indicate the implementation's dependency on services provided elsewhere. An implementation may also have one or more configurable properties. A property is a data value that can be externally configured and affects the business function of the implementation.

SCA services typically use document-style business data for parameters and return values, and preferably these parameters are represented using as Service Data Objects (SDOs) (please see the Resources section for more information).

Services, references and properties are the configurable aspects of an implementation -- SCA refers to them collectively as Component type.

Configuring a reference is done by binding the reference to a target service, which will then be used by the implementation when it invokes the reference. Configuration of a property involves setting a specific data value for the property. In a SCA framework, one implementation can be used to build multiple different components, with each component having a different configuration of the references and properties. Components and their services are used by other local components, or components can be used for remote access.

Assembly

Assembly is the process of composing business applications by configuring and connecting components that provide service implementations. SCA assembly operates at two levels:

• Assembly of loosely connected components within a system
• Assembly of loosely connected components within a module

The SCA assembly model consists of a series of artifacts, which are defined by XML elements.

Module assembly

A SCA module is the largest composition of tightly-coupled components that are developed and deployed together into a SCA system. It is the basic unit of loosely-coupled composition within a SCA System. A SCA module contains a set of components, external services, entry points, and the wires that interconnect them. Modules contribute service implementations to a SCA System.

Entry points define the public services provided by the module, which can either be used by other components within the same module or which can be made available for use outside the module. These are used to publish services provided by a module using a specified binding.

External services within a module represent remote services provided by other modules. They are external to the SCA module that uses the service. These external services can be accessed by components within the module like any service provided by a SCA component. External services use bindings to describe the access to external services.

The interface of an external service must be remotable.

System assembly

A SCA subsystem is used to group modules which provide related business functions through the configuration and administration of module components, external services and entry points, plus the wires that interconnect them in a SCA system. The configuration of a SCA system is represented by the combination of all the subsystems deployed into it. Figure 1 is an example of system assembly; it illustrates how sub systems and modules are wired using services and references.

Let's break down what we see in Figure 1:

• Module components in a subsystem configuration represent configured instances of a SCA module, where the module component can set values for the external services of the module and can set values for properties exposed by the module.
• External services are remote services that are external to the SCA system that uses the service. The differences between an external service on the module level and on the system level are:
  • The name has to be unique across all external services defined in the subsystem
  • No external service in a subsystem can have the same name as a module component since they both can be targets of wires
• Entry points are used to declare the externally accessible services of a subsystem. They are used by other organizations or customers as a Web service. The differences between entry points on the module level and on the system level are:
• The name has to be unique across all entry points defined in the subsystem. No entry point in the subsystem can have the same name as a module component
• The specification of the reference child element is optional, since it can be wired through a wire supplied by another subsystem

Open Source runtimes and tools

There is an open source project which provides a runtime implementation of Service Component Architecture, which you can use to run SCA applications. This project is called Tuscany, currently under incubation at Apache. The major contributors to this project are IBM, BEA, Oracle, Sybase, SAP, IONA, and Siebel.

Conclusion

We've introduced the SCA architecture and its assembly model, and explained the SCA subsystem and its various components including module, wires, and external service which make up this subsystem. These details should help you understand the concepts required to build and integrate different business applications using SCA.

Resources

• The SCA 0.96 Assembly Model Specification (PDF) is a good starting point for background information.
  
  
• You'll also want to learn about the SDO Specification.
  
  

About the authors

Comments (Undergoing maintenance)

Back to top

Trademarks  |  My developerWorks terms and conditions

Table of contents

• Introduction
• Motivation
• SCA architecture
• Conclusion
• Resources
• About the authors
• Comments

Next steps from IBM

Rational Tester for SOA Quality is an automated web services testing and SOA testing tool that supports Web services SOAP, HTTP(S), JMS, WS-Security, UDDI, and RESTful standards.

---

• Try: The no-charge Rational Service Tester for SOA Quality helps quality assurance professionals validate web service based SOA application..
• Article: See the whats new with Rational Service Tester for SOA Quality, and its Generic Service Client, which provides a single client to interact with any SOA service type.
• Tutorial: Get hands-on experience with this Transport for SOAP feature tutorial using Rational Tester for SOA Quality.
• Buy: Rational Service Tester for SOA Quality

My developerWorks community

Dig deeper into SOA and Web services on developerWorks

Rate a product. Write a review.

Write a review for Rational products today!

Special offers