You may be thinking, oh great, not another programming model. What about Web services? What happened to Enterprise JavaBeans? Well, Service Component Architecture (SCA) is not meant to replace or compete with any existing programming models. Instead, SCA gives you a model to define interfaces, implementations, and references in a technology neutral way, letting you then bind these elements to whichever technology specific implementations you choose.

For example, we can define our interface in Java, and our implementation can be applied as a BPEL process, or we can have my interface as a WSDL document and our implementation could be a Java™ class. Figure 1 illustrates how SCA is used in IBM WebSphere Process Server.Out of the box, WebSphere Process Server lets integration developers have various different implementation technologies and enables you to expose the interfaces using open standards, such as with Java or WSDL. Additionally, SCA provides a client programming model that lets clients access service components. Developers are encouraged to keep developing using the various technologies they are familiar with, such as Enterprise JavaBean (EJBs), and use SCA to glue the components together.

Another major element of SCA is that it also defines a standard model for defining dependencies between components (see Figure 2). As such, dependencies are defined by wiring SCA components together using references.

Finally, SCA defines a standard deployment model for packaging components into a service module. SCA components with their associated dependencies can be defined and packaged together into deployable units (see Figure 3).

An SCA module is not just another type of package. In WebSphere Process Server, an SCA service module is equivalent to a J2EE EAR file and several other J2EE sub-modules. J2EE elements, such as a WAR file, can be packaged along with the SCA module. Non-SCA artifacts (JSPs, and others) can also be packaged together with an SCA service module, enabling them to invoke SCA services through the SCA client programming model using a special type of reference called a standalone reference (see Figure 4).

SCA is closely tied to integration; we described references above as the way of defining dependencies between SCA components. For example, we can define a reference to another SCA component within the same module. When invoking service components within a module using the reference, the data is passed by-reference. SCA defines a way for components to be invoked by, or to invoke other SCA services, that live in other SCA modules.The mechanisms used for module to module and module to external service invocation are called imports and exports.

Imports and exports are expressed from the perspective of the module. The module is a self-contained bundle of components that perform a specific business function.

When the module wishes to provide the ability for another entity (external service or other module) to invoke a business function it exports this capability. Exports also provide the ability to make this service available over a number of different transport protocols. The export is associated to a particular component within the module.

When the module wishes to leverage the ability of another entity (external service or module) the module will import this function. Imports also provide the ability to interact with service providers across a variety of transport protocols.

Figure 5 illustrates these concepts.

Imports and exports are abstract concepts. They need to be binded to a specific technology. The types of bindings provided in WebSphere Process Server V6.0 are:

• SCA (used for SCA module to module)
• Web service
• JMS
• Stateless session bean.

Imports and exports can also bound to other technologies such as JMS, Enterprise JavaBeans, or Web services. This enables a Web service client to invoke an SCA module, or an SCA module to invoke an existing Enterprise JavaBean using the SCA programming model (see Figure 7).

We will discuss imports and exports in an article later in this series. What about my data?SCA gives us a universal model to define business services. The Service Data Object (SDO) provides the technology to represent a universal model for data. SCA components can be composed and can exchange data with each other in a neutral fashion by passing SDOs. The fundamental concept in the SDO architecture is the data object, a data structure that holds primitive typed data and/or other data objects. The data object also holds references to metadata that provides information about the data included in the data object.

In the SDO programming model, data objects are represented by the commonj.sdo.DataObject Java interface definition. This interface includes method definitions that enable clients to get and set the properties associated with the DataObject. Another important concept in the SDO architecture is the data graph, a structure that encapsulates a set of data objects. From the top level data object contained in the graph, all children data objects are reachable by traversing the references from the root data object. Another important feature included in the data graph is a change summary that is used to log information about what data objects and properties in the graph have changed during processing. (See Resources for more details on SDO.)

WebSphere Process Server implements the SDO specification by way of business objects. SCA components can exchange data by passing around business objects as shown in Figure 8. Much like an SDO is wrapped in a DataGraph, a business graph is used to wrap a top level business object and provide additional information that is used to supplement the data that is included the graph. In particular, the business graph includes the change summary for the data in the graph (similar to the SDO change summary information), event summary, and verb information (used for data synchronization between EIS systems). The business graph is very similar to the concept of the data graph in the SDO architecture. However, the event summary and the verb portion of the enhanced information were not included with the SDO data graph concept.

SCA 101Now that we've looked at SCA from a 10,000 foot view, we will begin to discuss some of the details using a sample. During the course of building the sample, we will give you an overview of IBM WebSphere Integration Developer, a tool that you will use to visually build and integrate SCA components.

OverviewTo demonstrate the aspects of SCA and business objects, we will discuss these concepts related to a business case. As with all development efforts, the cycle must begin with requirements. The requirements in this scenario involve the creation of a credit approval service, which will receive information about an applicant (CreditApplication) and respond with a credit rating (CreditRating).

The simplest element in SCA is a service component. As mentioned earlier, a service component is made up of an interface and an implementation. The technology used to "code" these artifacts can vary; in WebSphere Process Server, interfaces can be Java or WSDL. A Java interface can be a Plain Old Java Interface (POJI) as shown below:

Listing 1:

public interface CreditRequest
{ public DataObject calulateCreditScore(DataObject creditApp)
     throws ServiceBusinessException;

}

If you use a Java implementation, you can create a simple POJO. Below is an example of a POJO that acts as an SCA implementation: