Building SOA Solutions with SCA - Service Component Architecture

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:

Listing 2:

public class CreditApprovalImpl implements CreditRequest {
    public DataObject calulateCreditScore(DataObject creditApp) {

ServiceManager serviceManager = new ServiceManager();

BOFactory bof =
(BOFactory)serviceManager.locateService("com/ibm/websphere/bo/BOFactory");
DataObject creditRating = bof.create("http://CreditApproval", "CreditRating");
creditRating.setString("customerId", creditApp.getString("customerId"));

    creditRating.setInt("creditScore", 750);
    creditRating.setDouble("creditLimit", 10000d);
    return creditRating;
   }

}

In this implementation class, we use the CreditApplication input to create a simple CreditRating business object that we then return to the caller.

A service component is defined in a Service Component Definition Language (SCDL) file. A component file created with SCDL is roughly analogous to an EJB deployment descriptor, in that it defines the interface, implementation, and several qualities of service requirements of an SCA component. The SCDL file for the Java classes above would look like this:

Listing 3:

xmlns:java="http://www.ibm.com/xmlns/prod/websphere/scdl/java/6.0.0" xmlns:ns1=
"http://CreditApproval/CreditRequest"
xmlns:scdl="http://www.ibm.com/xmlns/prod/websphere/scdl/6.0.0"
xmlns:wsdl="http://www.ibm.com/xmlns/prod/websphere/scdl/wsdl/6.0.0"
displayName="CreditApproval" name="CreditApproval">
  
    
    
   
  
  

Similarly, we could have used WSDL to represent the interface as shown here:

Listing 4:

xmlns:tns="http://CreditApproval/CreditRequest"
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema" name="CreditRequest"
targetNamespace="http://CreditApproval/CreditRequest">
  
    xmlns:bons1="http://CreditApproval"
xmlns:tns="http://CreditApproval/CreditRequest"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
        schemaLocation="xsd-includes/http.CreditApproval.xsd"/>
      
        
          
            type="bons1:CreditApp"/>
          
        
      
      
        
          
            type="bons1:CreditRating"/>
          
        
      
    
  
    
    name="calulateCreditScoreParameters"/>
  
    
    name="calulateCreditScoreResult"/>
  
    
    
        name="calulateCreditScoreRequest"/>
        name="calulateCreditScoreResponse"/>
    
  

Our SCDL file would bind the interface to a WSDL document:

Listing 5:

xmlns:java="http://www.ibm.com/xmlns/prod/websphere/scdl/java/6.0.0"
xmlns:ns1="http://CreditApproval/CreditRequest"
xmlns:scdl="http://www.ibm.com/xmlns/prod/websphere/scdl/6.0.0"
xmlns:wsdl="http://www.ibm.com/xmlns/prod/websphere/scdl/wsdl/6.0.0"
displayName="CreditApproval" name="CreditApproval">
  
    
      
    
  
  

SCDL is used to describe SCA elements such as modules, references, imports, and exports. You will see examples of these throughout the series. SCDL definitions are organized across several files. For example, we store the SCDL for the interface and implementation in a file called CreditApproval.component. References can be included in the CreditApproval.component file (in-line) or in a separate sca.references file located in the Module root. Any standalone reference will be placed in the sca.references file, shown below. As we mentioned, standalone references can be used by non-SCA artifacts (JSP) within the same SCA module to invoke the SCA component.

Listing 6:

xmlns:java="http://www.ibm.com/xmlns/prod/websphere/scdl/java/6.0.0"
xmlns:scdl="http://www.ibm.com/xmlns/prod/websphere/scdl/6.0.0">
  
    interface="approval.credit.credit.request.CreditRequest">
      
    
    
  

Listing 7:

name="CreditApproval"/>

Although we defined a WSDL interface for our component, notice that we are able to add another Java interface to the standalone reference and wire it to our target component. In this manner, Java clients can invoke SCA components using a simple POJI. WebSphere Integration Developer will provide the option to translate the call between the Java and WSDL interface. You will see an example of this shortly when you create your first SCA component.

We will see examples of how SCDL defines other SCA artifacts, such as service references, imports, and exports, throughout this article series. The naming conventions for the SCDL files above are used by WebSphere Integration Developer, and were actually by using WebSphere Integration Developer. In our example, you will use WebSphere Integration Developer when building your first SCA component. However, SCA applications can also be built using a notepad process as well.

WebSphere Integration Developer and WebSphere Process ServerIn this article, you will use WebSphere Integration Developer and WebSphere Process Server to build and run your SCA components.

WebSphere Integration Developer is used to develop applications that run on WebSphere Process Server V6. WebSphere Integration Developer, based on the Eclipse 3.0 platform, delivers role-based development for integration projects. You can use WebSphere Integration Developer and IBM WebSphere Business Modeler V6 together with IBM Rational® Application Developer V6 or IBM Rational Software Architect V6 as an integration development platform. J2EE developers, business analysts, or integration developers can use the tooling perspective based on their unique roles, so that each developer can focus on the editors and tools needed for those roles, thereby maximizing productivity.

WebSphere Process Server is a comprehensive integration platform which is based on WebSphere Application Server V6. WebSphere Process Server is used to execute component-based business integration applications in a service-oriented architecture. Because it is based on J2EE 1.4 infrastructure and platform services provided by WebSphere Application Server, WebSphere Process Server includes capabilities such as business process automation.

See Resources for more details on both WebSphere Integration Developer and WebSphere Process Server.

Build your first SCA projectYou are now ready to build your first SCA project. In this example, you will build a simple credit approval component. The component will take in a data object with an ID and name, and then return another data object containing a credit score and credit limit. Download the zip file included with this article and extract it to your hard drive. The instructions assume you extract the zip file to your C: drive.

WebSphere Integration Developer V6.0 is a flexible development environment that provides tools and wizards for developing SCA applications from the bottom-up or from the top-down.

For the creation of the credit approval service, we will explore the aspects of top-down development. The general high level steps in our top-down development process are:

1. Create the SCA module.
2. Create the business objects.
3. Define the service interface.
4. Generate the component and provide an implementation.
5. Unit test the SCA component.
6. Provide a standalone reference.
7. Test the service using a simple JSP client.

1. Open WebSphere Integration Developer to a blank workspace. (Figure 9)
2. Close the Welcome screen.
3. Next you will create a new module.
   a. Your WebSphere Integration Developer workbench should be open to the Business Integration perspective. Find the Business Integration view.
   b. Right-click inside the Business Integration view and select New => Module. (Figure 10)
   c. The New Module wizard should display (Figure 11). Name the Module CreditApprovalSCAModule.
   d. You should now have a new project displaying in the Business Integration view. SCA modules are described as a SCDL file. The Business Integration view shows you a logical view of your SCA module. You can open the Physical Resource view to see the physical resources contained in the SCA module, as previously discussed. The SCDL for the SCA module is contained in the file called sca.module. If you open the file with a text editor, you should see something like this:

name="CreditApprovalSCAModule"/>

Create the business objects. There is no predefined sequence of tasks for creating interfaces or business objects; you could have just as easily have created the business objects when creating the interface. Here we chose to create business objects from the Business Integration view.

When creating a business object, you are actually creating an XML schema. Business objects are stored as standard XML schema. Applications can access the data using the SDO programming model and XPath.

The Business Object Editor enables us to create the business object definitions that will be used by the credit approval service. There are two business objects that are needed for our service.

CreditApplication: Contains the information about the credit applicant necessary to calculate a credit rating. The credit application business object (CreditApplication) consists of three attributes:

• Customer Id: unique identifier of the customer
• First Name: customer's first name
• Last Name: customer's last name

• Credit Score: customer's credit score based on prior history
• Credit Limit: total amount that the customer may owe.

2.  We will now define the attributes of the CreditApplication business object.
a. You can add an attribute by selecting the Add Attribute icon as shown in Figure 15.
b. Enter customerId as the attribute name and accept the default String type. (To change the type, you could just select the type field and select it from the drop-down box. You will do this for the response object.)

Figure 16. Define attribute
c. Add two more String attributes and name them firstName and lastName. Both of them should be of type string as shown below.

© 2008 SYS-CON Media