Chapter 9: Introduction to SCA

Overview

Service Component Architecture (SCA) is a proposed standard for composing and deploying service-oriented applications. When SCA-compliant products are in place at development and run time, you write code in the implementation language of your choice, but with an important difference: you focus on business logic. SCA lets you avoid writing many of the technology-specific details that would otherwise be necessary before you can invoke other code.

With the ease of invoking a local method or function, you do tasks such as the following:

• Invoke a Web service.

• Invoke an Enterprise JavaBean stateless session bean (EJB SLSB), which is a kind of binary-exchange service that is written for the Java EE platform.

• Invoke a traditional application by way of an adapter, which is software that allows a data exchange between logical units that were not designed to interact.

• Access a message queue, which is a data collection that is administered by messaging software such as WebSphere MQ. The messaging software stores or forwards the data, acting as an intermediary between your service and (for example) a help-desk application. The interaction between your service and the help-desk application is usually asynchronous, with your service continuing to run rather than waiting for a response. The message queue also can forward data to your service - for example, after receiving a callback message from the help-desk application.

  At this writing, access of a message queue is possible only by way of a facility called Java Message Service (JMS). Additional technologies are in plan.

SCA also releases you from having to write logic that distinguishes one requester from the next during conversational processing.

SCA does more than make development easier. The technology allows for significant change in service behavior over time without requiring updates and recompilation. By setting values outside the code, your company can initialize variables, choose transport protocols and endpoints for in-code invocations, and specify Quality of Service (QoS) capabilities. In this way, SCA helps your company to retain software but be responsive to change.

Last, SCA makes reuse easier by providing a simple way to compose services from other services. A business analyst can do the assembly, replacing one service with another if the interfaces are alike or assigning an intermediary between services that are otherwise not compatible. A replacement service also can be assembled from other services, to any level of complexity.

SCA supports several implementation languages, including BPEL, C++, Java, and PHP, with more expected. A given SCA runtime may or may not support a given language or runtime technology.

If you are writing code in Java (or, later, in other languages), you can implement your service's argument and return definitions with Service Data Objects (SDO) Version 2, another open-standards technology. We describe SDO in Chapter 10.

Although companies have implemented early versions of SCA and SDO, the situation of interest to this book is that eighteen companies are in the Open Service Oriented Architecture (OSOA) collaboration, which is creating a set of SCA and SDO proposals for a major standards body to adopt. Our descriptions in this chapter are based primarily on early 2007 drafts of the following OSOA documents: SCA Assembly Model Specification; SCA Policy Framework; SCA Client and Implementation Model Specification for WS-BPEL; and SCA Client and Implementation Model Specification for Java. The current, publicly available specifications are at the following Web site: http://www.osoa.org.

Under the auspices of the Apache Software Foundation, the Tuscany incubator project is developing open-source implementations of SCA and SDO. For details and code, see the following Web sites: http://incubator.apache.org/tuscany and http://www.apache.org.