IBM WebSphere Developer Technical Journal: Building SOA solutions with the Service Component Architecture -- Part 1

Oh great, another programming model?

With the release of IBM® WebSphere® Integration Developer and IBM WebSphere Process Server, comes a new programming paradigm for building service-oriented architectures (SOA) called the Service Component Architecture, a new programming model designed specifically for building and assembling business solutions in an SOA, and targeted for integrating and composing services.

Share:

Roland Barcia, Certified IT Specialist, EMC

Roland Barcia is a Certified IT Specialist for IBM Software Services for WebSphere in the New York/New Jersey Metro area. He is a co-author of IBM WebSphere: Deployment and Advanced Configuration. For more information on Roland, visit his Web site.



Jeff Brent (jeffb@us.ibm.com), Advisory Software Engineer, EMC

Jeff Brent is an Advisory Software Engineer for the Service Component Architecture team and Technical Lead for WebSphere Process Server SWAT from West Palm Beach, Florida. In his spare time, he enjoys spending time with his family and playing basketball.



26 October 2005

Also available in Chinese

From the IBM WebSphere Developer Technical Journal.

Introduction

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 any existing programming models. Instead, SCA gives you a model to define interfaces, implementations, and references, letting you then bind these elements to whichever technology specific implementations you choose, such as Java and Web services.

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.

Figure 1. SCA in WebSphere Process Server
Figure 1. SCA in 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 JavaBeans™ (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. As such, dependencies are defined by wiring SCA components together using references.

Figure 2. Define dependencies between components
Figure 2. Define dependencies between components

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.

Figure 3. Components packaged with dependencies
Figure 3. Components packaged with dependencies

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.

Figure 4. Standalone reference for non-SCA artifacts
Figure 4. Standalone reference for non-SCA artifacts

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 synchronously 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.

Figure 5. SCA imports and exports
Figure 5. SCA imports and exports

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.

When invoking SCA components through imports and exports, parameters are passed by-value.

Figure 6. SCA imports and exports
Figure 6. SCA imports and exports

The wires that glue SCA components together abstract out most of the infrastructure level code. For example, we can define wires to be synchronous or asynchronous, operations to be one way or request-response, or we can define the transactional behavior between components. SCA handles the infrastructure details for you. We will elaborate more on these details throughout this article series.

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.

Figure 7. Imports and exports with other technologies
Figure 7. Imports and exports with other technologies

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.

Figure 8. WebSphere Process Server business objects
Figure 8. WebSphere Process Server business objects

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. The business graph uses the change summary for the data in the business graph. In addition, the business graph maintains an event summary, and carries verb information about the data (used for data synchronization between EIS systems).


SCA 101

Now 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.

Overview

To 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

Click to see code listing

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
<?xml version="1.0" encoding="UTF-8"?>
<scdl:component xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
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">
  <interfaces>
    <interface xsi:type="java:JavaInterface" interface="CreditRequest " >
      <method name="calulateCreditScore"/>
    </interface>
  </interfaces>
  <implementation xsi:type="java:JavaImplementation" class=" CreditApprovalImpl"/>
</scdl:component>

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

Listing 4
<?xml version="1.0" encoding="UTF-8"?>
<wsdl:definitions xmlns:bons1="http://CreditApproval" 
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">
  <wsdl:types>
    <xsd:schema targetNamespace="http://CreditApproval/CreditRequest" 
	xmlns:bons1="http://CreditApproval" 
	xmlns:tns="http://CreditApproval/CreditRequest" 
	xmlns:xsd="http://www.w3.org/2001/XMLSchema">
      <xsd:import namespace="http://CreditApproval" 
schemaLocation="xsd-includes/http.CreditApproval.xsd"/>
      <xsd:element name="calulateCreditScore">
        <xsd:complexType>
          <xsd:sequence>
            <xsd:element name="CreditApp" nillable="true" 
type="bons1:CreditApp"/>
          </xsd:sequence>
        </xsd:complexType>
      </xsd:element>
      <xsd:element name="calulateCreditScoreResponse">
        <xsd:complexType>
          <xsd:sequence>
            <xsd:element name="CreditRating" nillable="true" 
type="bons1:CreditRating"/>
          </xsd:sequence>
        </xsd:complexType>
      </xsd:element>
    </xsd:schema>
  </wsdl:types>
    <wsdl:message name="calulateCreditScoreRequestMsg">
    <wsdl:part element="tns:calulateCreditScore" 
name="calulateCreditScoreParameters"/>
  </wsdl:message>
    <wsdl:message name="calulateCreditScoreResponseMsg">
    <wsdl:part element="tns:calulateCreditScoreResponse" 
name="calulateCreditScoreResult"/>
  </wsdl:message>
    <wsdl:portType name="CreditRequest">
    <wsdl:operation name="calulateCreditScore">
      <wsdl:input message="tns:calulateCreditScoreRequestMsg" 
name="calulateCreditScoreRequest"/>
      <wsdl:output message="tns:calulateCreditScoreResponseMsg" 
name="calulateCreditScoreResponse"/>
    </wsdl:operation>
  </wsdl:portType>
</wsdl:definitions>

The implementation class could look the same (except it would obviously not implement any Java interface since it is defined as WSDL).

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

Listing 5
<?xml version="1.0" encoding="UTF-8"?>
<scdl:component xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
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">
  <interfaces>
    <interface xsi:type="wsdl:WSDLPortType" portType="ns1:CreditRequest">
      <method name="calulateCreditScore"/>
    </interface>
  </interfaces>
  <implementation xsi:type="java:JavaImplementation" class="CreditApprovalImpl"/>
</scdl:component>

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
<?xml version="1.0" encoding="UTF-8"?>
<scdl:references xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
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">
  <reference name="CreditRequestPartner">
    <interface xsi:type="java:JavaInterface" interface="approval.credit.credit.request.CreditRequest">
      <method name="calulateCreditScore"/>
    </interface>
    <wire target="CreditApproval"/>
  </reference>
</scdl:references>

In our example, a third file we will define is the sca.module. This SCDL file will contain the definition for the module:

Listing 7
<?xml version="1.0" encoding="UTF-8"?>
<scdl:module xmlns:scdl="http://www.ibm.com/xmlns/prod/websphere/scdl/6.0.0" 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. 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 Server

In 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. It is based on J2EE 1.4 infrastructure and platform services provided by WebSphere Application Server. Furthermore, 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 project

You 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.

Create an SCA module

First, you need to create an SCA module. As stated earlier, an SCA module is the packaging construct of SCA components.

  1. Open WebSphere Integration Developer to a blank workspace. (Figure 9)

    Figure 9. Open a blank workspace in WebSphere Integration Developer
    Figure 9. Open a blank workspace in WebSphere Integration Developer
  2. Close the Welcome screen.

  3. Next you will create a new module.

    1. Your WebSphere Integration Developer workbench should be open to the Business Integration perspective. Find the Business Integration view.

    2. Right-click inside the Business Integration view and select New => Module. (Figure 10)

      Figure 10. Create new module
      Figure 10. Create new module
    3. The New Module wizard should display (Figure 11). Name the Module CreditApprovalSCAModule.

      Figure 11. Create new module
      Figure 11. Create new module
    4. 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:

Listing 8

Click to see code listing

Listing 8

<?xml version="1.0" encoding="UTF-8"?>
<scdl:module xmlns:scdl="http://www.ibm.com/xmlns/prod/websphere/scdl/6.0.0" 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

CreditRating: Contains credit rating information such as credit score and credit limit. The credit rating business object (CreditRating) consists of three attributes:

  • Credit Score: customer's credit score based on prior history
  • Credit Limit: total amount that the customer may owe.
  1. We begin by creating our Request business object, which will be used as an input parameter to our SCA component.

    1. Make sure that the CreditApprovalSCAModule is expanded. Right click on Data Types and select New => Business Object. (Figure 12)

      Figure 12. Create a new business object
      Figure 12. Create a new business object
    2. Name your business object CreditApplication as shown in Figure 13.

      Figure 13. Define business object
      Figure 13. Define business object
    3. The business object should open in the Business Object Editor. You should now have the CreditApplication under the Data Types menu. (Figure 14)

      Figure 14. Business Integration menu
      Figure 14. Business Integration menu
  2. We will now define the attributes of the CreditApplication business object.

    1. You can add an attribute by selecting the Add Attribute icon as shown in Figure 15.

      Figure 15. Add Attribute icon
      Figure 15. Add Attribute icon
    2. 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
      Figure 16. Define attribute
    3. Add two more String attributes and name them firstName and lastName. Both of them should be of type string as shown below.

      Figure 17. Define attributes
      Figure 17. Define attributes
    4. The business object is defined using standard XML schema type. You can open the business object using an XML editor to see it. (You can open the business object in a text editor by right clicking it and selecting Open with => and the editor of your choice.)

    5. Save and close the Business Object Editor.

      Figure 18. Defined business object
      Figure 18. Defined business object
    6. The XML schema should look something like the code sample below.

      Listing 9
      <?xml version="1.0" encoding="UTF-8"?>
      <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" 
      targetNamespace="http://CreditApprovalSCAModule">
        <xsd:complexType name="CreditApplication">
          <xsd:sequence>
            <xsd:element minOccurs="0" name="customerId" type="xsd:string"/>
            <xsd:element minOccurs="0" name="firstName" type="xsd:string"/>
            <xsd:element minOccurs="0" name="lastName" type="xsd:string"/>
          </xsd:sequence>
        </xsd:complexType>
      </xsd:schema>
  3. We will now create a second business object to represent the response.

    1. Create another business object following the same steps above. This business object will have three fields:

      • customerId of type string
      • creditScore of type int
      • creditLimit of type double
    2. As mentioned earlier, you can change the type by selecting the type column as shown in Figure 19.

      Figure 19. Change attribute type
      Figure 19. Change attribute type
    3. Save and close the Business Object Editor

You now have two business objects created.

Define the service interface

You are now ready to create your SCA Interface. Again, the credit approval service is a request-response service that receives a credit application and returns a credit rating synchronously. The service interface defines the interaction between the service client and the service provider.

There are several ways to create an interface. If you choose a Java interface, you can use the Java Eclipse tools within WebSphere Integration Developer to do this. In our example, we will create a WSDL interface from the Business Integration perspective. You can do this using the Assembly Editor or you can do it using the Business Integraiton view. We will use the latter. (We will use the Assembly Editor later to create the implementation.)

  1. First, we will create the Interface using the Business Integration view menu.

    1. Right-click on the Interfaces menu item and select New => Interfaces as shown in Figure 20.

      Figure 20. Create a new interface
      Figure 20. Create a new interface
    2. On the New Interface menu, enter the name CreditApproval. (Keep in mind that we are using the default package and folders in our example for illustration purposes. You can select a folder to easily group different interfaces by functionality.)

      Figure 21. Create a new interface
      Figure 21. Create a new interface
  2. The CreditApproval Interface is a simple WSDL file. WebSphere Integration Developer comes with a simple WSDL editor that you can use to build up your interface.

    1. The Interface Editor should have opened when you created the Interface. If it is not open already, you can double click the interface in the business integration view to open it.

    2. We will first create a simple request-response operation. (You can also create one-way operations that can be used with asynchronous invocations, but for now, we are only creating a simple synchronous request.) Press the Add Request Response Operation icon as shown in Figure 22.

      Figure 22. Add Request Response Operation icon
      Figure 22. Add Request Response Operation icon
    3. An operation will be created on the editor. Name the operation calculateCreditRating. (Figure 23)

      Figure 23. Define operation
      Figure 23. Define operation
    4. Now we need to define the parameters. Remember, we created two business objects, one for input and the other for output. With the operation created, select the Add Input icon as shown in Figure 24.

      Figure 24. Add Input icon
      Figure 24. Add Input icon
    5. Name the input CreditApplication.

    6. Select the Type column and find the CreditApplicaiton business object. As you can see, the business object is now a valid type that you can use to build up the interface, as shown in Figure 25. (Optionally, you can select to create a new business object here.)

      Figure 25. New business object is now a valid type
      Figure 25. New business object is now a valid type
    7. Next, select the Add Output icon as shown in Figure 26.

      Figure 26. Add Output icon
      Figure 26. Add Output icon
    8. Select CreditRating as the type, similar to what we did with the input.

      Figure 27. Define output
      Figure 27. Define output
    9. Save and close the Interface Editor.

    10. If you wish to inspect the WSDL file, you can right click the CreditApproval.wsdl file in the Physical Resources view and open it with a text editor. (Figure 28)

      Figure 28. View WSDL file
      Figure 28. View WSDL file

      The WSDL file should look like the code sample below.

      Listing 10
      <?xml version="1.0" encoding="UTF-8"?>
      <wsdl:definitions xmlns:bons1="http://CreditApprovalSCAModule" 
      xmlns:tns="http://CreditApprovalSCAModule/CreditApproval" 
      xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" 
      name="CreditApproval" targetNamespace="http://CreditApprovalSCAModule/CreditApproval">
        <wsdl:types>
          <xsd:schema targetNamespace="http://CreditApprovalSCAModule/CreditApproval" 
      xmlns:bons1="http://CreditApprovalSCAModule" 
      xmlns:tns="http://CreditApprovalSCAModule/CreditApproval" 
      xmlns:xsd="http://www.w3.org/2001/XMLSchema">
            <xsd:import namespace="http://CreditApprovalSCAModule" 
      schemaLocation="xsd-includes/http.CreditApprovalSCAModule.xsd"/>
            <xsd:element name="calculateCreditRating">
              <xsd:complexType>
                <xsd:sequence>
                  <xsd:element name="CreditApplication" nillable="true" 
      type="bons1:CreditApplication"/>
                </xsd:sequence>
              </xsd:complexType>
            </xsd:element>
            <xsd:element name="calculateCreditRatingResponse">
              <xsd:complexType>
                <xsd:sequence>
                  <xsd:element name="CreditRating" nillable="true" 
      type="bons1:CreditRating"/>
                </xsd:sequence>
              </xsd:complexType>
            </xsd:element>
          </xsd:schema>
        </wsdl:types>
          <wsdl:message name="calculateCreditRatingRequestMsg">
          <wsdl:part element="tns:calculateCreditRating" 
      name="calculateCreditRatingParameters"/>
        </wsdl:message>
          <wsdl:message name="calculateCreditRatingResponseMsg">
          <wsdl:part element="tns:calculateCreditRatingResponse" 
      name="calculateCreditRatingResult"/>
        </wsdl:message>
          <wsdl:portType name="CreditApproval">
          <wsdl:operation name="calculateCreditRating">
            <wsdl:input message="tns:calculateCreditRatingRequestMsg" 
      name="calculateCreditRatingRequest"/>
            <wsdl:output message="tns:calculateCreditRatingResponseMsg" 
      name="calculateCreditRatingResponse"/>
          </wsdl:operation>
        </wsdl:portType>
      </wsdl:definitions>

Generate the component and provide an implementation

We are now ready to create our SCA implementation. At this point, we have created standard interfaces and business objects. We will now define our SCA component. You will use the SCA Assembly Editor to do this.

  1. First, we will define the SCA component.

    1. Open the SCA Assembly Editor by double clicking the CreditApprovalSCAModule menu item, as shown in Figure 29.

      Figure 29. Open SCA Assembly Editor
      Figure 29. Open SCA Assembly Editor
    2. The SCA Assembly Editor has a palette you can use to create SCA artifacts. You can also drag certain artifacts from various views. Simply drag the CreditApproval interface onto the Assembly Editor as shown in Figure 30. (Alternatively, you could also drag a Java component from the palette and associate the interface afterwards.)

      Figure 30. Drag interface onto Assembly Editor
      Figure 30. Drag interface onto Assembly Editor
    3. A text box will appear. Select Component with No Implementation Type as shown in Figure 31.

      Figure 31. Component Creation text box
      Figure 31. Component Creation text box
    4. You should now see an SCA component on the Assembly Editor named Component1. (Figure 32)

      Figure 32. SCA component icon
      Figure 32. SCA component icon
    5. You can change the name by selecting the component and typing the name, or you can change it using the Properties Editor as shown in Figure 33. Change the Display Name to CreditApproval. The Name field should change automatically.

      Figure 33. Change component name
      Figure 33. Change component name
  2. We now have an SCA component with an interface, but no implementation. We will now use the Assembly Editor to generate the implementation.

    1. Generate a skeleton implementation by right-clicking the component in the Assembly Editor and selecting Generate Implementation => Java. (Figure 34)

      Figure 34. Generate skeleton implementation
      Figure 34. Generate skeleton implementation
    2. The new Java implementation should open in a Java Editor; you will see the calculateCreditRating. A simple code snippet is provided in the download file, in C:\SCA_ArticleSeries\Part1\CodeSnippet1.txt. The method is shown below.

      Listing 11

      Click to see code listing

      Listing 11

      public DataObject calculateCreditRating(DataObject creditApplication) {
      //	Create and return a credit rating object.
      	System.out.println("********* credit approval service invoked ******");
      	ServiceManager serviceManager = new ServiceManager();
      
      	BOFactory bof = (BOFactory)serviceManager.locateService("com/ibm/websphere/bo/BOFactory");
      
      	System.out.println("********* BOFactory created ******");
      	DataObject creditRating = bof.create("http://CreditApproval", "CreditRating");
      
      	System.out.println("********* credit rating object created ******");
      	creditRating.setString("customerId", creditApplication.getString("customerId"));
      		
      	creditRating.setInt("creditScore", 750);
      	creditRating.setDouble("creditLimit", 10000d);
      	System.out.println("********* returning credit rating object ******");
      		
      	return creditRating;
      
      }
  3. The code uses the SCA service manager to locate the Business Object Factory, which is used to create business objects from XML schemas. In our demonstration purposes, we create the Response Data Object and return hard coded data.

  4. If you pasted in the code, you should have some compile errors. You can resolve the these by right clicking in the editor and selecting Source => Organize Imports as shown in Figure 35.

    Figure 35. Resolve errors
    Figure 35. Resolve errors
  5. Save and close the Java file, but leave the Assembly Editor open.

Unit test the SCA component

WebSphere Integration Developer provides the ability to unit test components using a unit test tool. Depending on the type of SCA implementation, you can test SCA components in a J2SE environment, which enables you to test components without a full application server; of course, this greatly depends on the type of component you have. A Java implementation can be easily tested in a J2SE environment, but an SCA component realized by a BPEL flow would need a BPEL engine like WebSphere Process Server. In our example, we will use the Test Component feature to test our SCA component.

To launch the Test Component feature:

  1. Right click the CreditApproval component in the SCA Assembly Editor and select Test Component. (Figure 36)

    Figure 36. Launch Test Component feature
    Figure 36. Launch Test Component feature
  2. This will launch the Test Component Editor. On the right side of the tool, enter the test data as shown in Figure 37, then press Continue.

    Figure 37. Enter test data
    Figure 37. Enter test data
  3. A list of available run times will display. Select Eclipse 1.4 JVM, then Finish. (Figure 38)

    Figure 38. Runtime deployment locations
    Figure 38. Runtime deployment locations
  4. To begin the test, select the Return item as shown in Figure 39. Monitor the Events window to see the flow.

    Figure 39. Events window
    Figure 39. Events window
  5. On the right side, you will see the result. (Figure 40)

    Figure 40. Unit test results
    Figure 40. Unit test results

Create SCA client Web application and testing with WebSphere Process Server

  1. To have an SCA component be invoked by a non-SCA component packaged in the same SCA deployment, we need to create a standalone reference:

    1. In the SCA Assembly Editor, select the arrow next to the Import icon on the palette. This will expose a smaller submenu. Select the Standalone references icon and drag it anywhere on the Assembly Editor as shown in Figure 41.

      Figure 41. Create standalone reference
      Figure 41. Create standalone reference
    2. Click inside the Stand-alone References box (not the text) and drag it to the Credit Approval component as shown in Figure 42.

      Figure 42. Create a matching reference
      Figure 42. Create a matching reference
    3. Press OK to create a matching reference. (Figure 43)

      Figure 43. Create a matching reference
      Figure 43. Create a matching reference
    4. The next text box will give you an option to generate a Java interface. Remember, you created a WSDL Interface. However, WebSphere Integration Developer is generating an equivalent Java interface to let Java clients interact using the SCA API. Select Yes. (Figure 44) Keep in mind that this model is generally used for local non-SCA clients that want to use the Java programming model to invoke components for better performance.

      Figure 44. Interface conversion verification
      Figure 44. Interface conversion verification
  2. With a standalone reference, we can now invoke SCA components from non-SCA components in the same module. Remember, an SCA module is realized by an EAR file, so you can add additional J2EE components to the SCA module. In our example, we are going to import an existing WAR file that has a JSP file. That WAR file will be part of the underlying EAR file.

    1. Select File => Import to bring up the Import wizard. Select WAR file and press Next. (Figure 45)

      Figure 45. Invoke SCA components from non-SCA components
      Figure 45. Invoke SCA components from non-SCA components
    2. Select C:\SCA_ArticleSeries\Part1\CreditApprovalClient.war. Unselect Add module to an EAR Project.

      Figure 46. Importing a WAR file
      Figure 46. Importing a WAR file
    3. Select Yes to switch to the Web perspective. (Figure 47)

      Figure 47. Switch to the Web perspective
      Figure 47. Switch to the Web perspective
    4. Open the JSP file to examine the code. You will find it under the Dynamic Web Projects directory, as shown in Figure 48. The JSP is called creditApprovalClient.jsp.

      Figure 48. Dynamic Web Projects directory
      Figure 48. Dynamic Web Projects directory
    5. We use a simple JSP to receive input and use the SCA API to invoke an SCA component. (Keep in mind this JSP does follow best practices for using MVC).

  3. SCA has a Dependency Editor that enables you to add different packages to the SCA module:

    1. Open the Dependency Editor by right-clicking the CreditApprovalSCAModule and select Open Dependency Editor. (Figure 49)

      Figure 49. Open Dependency Editor
      Figure 49. Open Dependency Editor
    2. Expand the J2EE section, then press the Add button. (Figure 50)

      Figure 50. Configure dependencies
      Figure 50. Configure dependencies
    3. Select the CreditApprovalClient Web project as shown in Figure 51.

      Figure 51. Select Web project
      Figure 51. Select Web project
    4. Be sure to unselect On Build Path. (Build Path adds this component to the classpath of the SCA module. In our case, we need to make the WAR file depend on the SCA module.) Save the Dependency Editor. This makes the WAR file part of the EAR file.

      Figure 52. Set dependency
      Figure 52. Set dependency
    5. To make the Web project see the SCA Java interface, right click the Web project and select Properties.

    6. Go to Java JAR Dependencies and select CreditApprovalSCAModuleEJBClient.jar, which is the generated EJB client JAR file that is generated underneath. (Figure 53)

      Figure 53. Set dependency
      Figure 53. Set dependency
    7. Close the editor. At this point, you can choose to perform a full build. This may not be necessary, but we always like doing a full build before deploying. If you have automatic build, you can do a Clean as shown in Figure 54.

      Figure 54. Clean for automatic builds
      Figure 54. Clean for automatic builds
  4. We are now ready to deploy and test our SCA component and Web client on WebSphere Process Server. Remember, our SCA module is realized by a J2EE application. You can switch to the J2EE perspective to view the artifacts. Keep in mind that these are generated artifacts. (We will cover these later in this article series.)

    Figure 55. J2EE perspective
    Figure 55. J2EE perspective
    1. Switch to the Servers view on the bottom of the Business Integration perspective. Right click WebSphere Process Server and select Start as shown in Figure 56.

      Figure 56. Start WebSphere Process Server
      Figure 56. Start WebSphere Process Server
    2. Wait for the server to start. Check the console and wait for the messages shown in Figure 57.

      Figure 57. WebSphere Process Server startup messages
      Figure 57. WebSphere Process Server startup messages
    3. Right-click the server again and select Add and remove projects. (Figure 58)

      Figure 58. Add and remove projects
      Figure 58. Add and remove projects
    4. Select CreditApprovalSCAModuleAdd and select Add as shown in Figure 59. This will move it into the Configured projects box on the right.

      Figure 59. Configure project on server
      Figure 59. Configure project on server
    5. Monitor the progress on the lower right corner and wait for the application to be deployed. (Figure 60)

      Figure 60. Project deployment monitor
      Figure 60. Project deployment monitor
    6. Verify at the console that the CreditApporvalSCAModuleApp is started. (Figure 61)

      Figure 61. Administrative console messages
      Figure 61. Administrative console messages
    7. Switch to the Web perspective. Right-click on the JSP and select Run => Run on Server as shown in Figure 62.

      Figure 62. Run application
      Figure 62. Run application
    8. Choose the existing WebSphere Process Server and select Set server as project default, then Finish. (Figure 63)

      Figure 63. Set server
      Figure 63. Set server
    9. When the application executes, enter the application test data shown in Figure 64.

      Figure 64. Enter SCA application test data
      Figure 64. Enter SCA application test data
    10. You should get the results shown in Figure 65.

      Figure 65. SCA application test results
      Figure 65. SCA application test results
    11. Close the browser and stop the server.

Congratulations, you have just created and tested your first SCA component!


Conclusion

Service Component Architecture (SCA) is a major shift in service-oriented architectures (SOA). SCA gives us a programming model for SOA, and will serve as a foundation for integration for years to come. Stay tuned for upcoming articles in this series, which will explore details of specific SCA features and the benefits they can bring to your applications.


More articles in this series


Download

DescriptionNameSize
Code sampleSCA_ArticleSeries.zip  ( HTTP | FTP )4 KB

Resources

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into WebSphere on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=WebSphere, SOA and web services
ArticleID=97388
ArticleTitle=IBM WebSphere Developer Technical Journal: Building SOA solutions with the Service Component Architecture -- Part 1
publish-date=10262005