IBM - SOA Using SCA Part 1

IBM WebSphere Developer Technical Journal: Building SOA solutions with the Servi...
Page 1 of 34
IBM WebSphere Developer Technical Journal:

Building SOA solutions with the Service Component
Architecture -- Part 1
Oh great, another programming model?
Level: Intermediate
Roland Barcia (barcia@us.ibm.com), Certified IT Specialist, IBM

Jeff Brent (jeffb@us.ibm.com), Advisory Software Engineer, IBM
26 Oct 2005
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.
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
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
http://www.ibm.com/developerworks/websphere/techjournal/0510_brent/0510_brent.ht... 4/10/2008
IBM WebSphere Developer Technical Journal: Building SOA solutions with the Servi... Page 2 of 34
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
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
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
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
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
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
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
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
<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
<scdl:component xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
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">
</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
<scdl:references xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
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">
</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
<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
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)
Figure 10. Create new module
c. The New Module wizard should display (Figure 11). Name the Module CreditApprovalSCAModule.
Figure 11. Create new module
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:
Listing 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.
IBM WebSphere Developer Technical Journal: Building SOA solutions with the Se... Page 10 of 34
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.
a. 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
b. Name your business object CreditApplication as shown in Figure 13.
Figure 13. Define business object
c. 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
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.
Figure 15. Add Attribute icon
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.
Figure 17. Define attributes
d. 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.)
e. Save and close the Business Object Editor.
Figure 18. Defined business object
f. The XML schema should look something like the code sample below.
Listing 9
<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.
a. 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
b. As mentioned earlier, you can change the type by selecting the type column as shown in Figure 19.
Figure 19. Change attribute type
c. 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.
a. Right-click on the Interfaces menu item and select New => Interfaces as shown in Figure 20.
Figure 20. Create a new interface
b. 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
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.
a. 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.
b. 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
c. An operation will be created on the editor. Name the operation calculateCreditRating. (Figure 23)
Figure 23. Define operation
d. 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
e. Name the input CreditApplication.
f. 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
g. Next, select the Add Output icon as shown in Figure 26.
Figure 26. Add Output icon
h. Select CreditRating as the type, similar to what we did with the input.
Figure 27. Define output
i. Save and close the Interface Editor.

j. 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
The WSDL file should look like the code sample below.
Listing 10
<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.
a. Open the SCA Assembly Editor by double clicking the CreditApprovalSCAModule menu item, as shown in
Figure 29.
Figure 29. Open SCA Assembly Editor
b. 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
c. A text box will appear. Select Component with No Implementation Type as shown in Figure 31.
Figure 31. Component Creation text box
d. You should now see an SCA component on the Assembly Editor named Component1. (Figure 32)
Figure 32. SCA component icon
e. 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
2. We now have an SCA component with an interface, but no implementation. We will now use the Assembly Editor to
generate the implementation.
a. 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
b. 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
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
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
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
3. A list of available run times will display. Select Eclipse 1.4 JVM, then Finish. (Figure 38)
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
5. On the right side, you will see the result. (Figure 40)
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:
a. 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
b. 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
c. Press OK to create a matching reference. (Figure 43)
Figure 43. Create a matching reference
d. 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
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.
a. 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
b. Select C:\SCA_ArticleSeries\Part1\CreditApprovalClient.war. Unselect Add module to an EAR Project.
Figure 46. Importing a WAR file
c. Select Yes to switch to the Web perspective. (Figure 47)
Figure 47. Switch to the Web perspective
d. 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
e. 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:
a. Open the Dependency Editor by right-clicking the CreditApprovalSCAModule and select Open Dependency
Editor. (Figure 49)
Figure 49. Open Dependency Editor
b. Expand the J2EE section, then press the Add button. (Figure 50)
Figure 50. Configure dependencies
c. Select the CreditApprovalClient Web project as shown in Figure 51.
Figure 51. Select Web project
d. 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
e. To make the Web project see the SCA Java interface, right click the Web project and select Properties.
f. 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
g. 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
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
a. 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
b. 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
c. Right-click the server again and select Add and remove projects. (Figure 58)
Figure 58. Add and remove projects
d. 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
e. Monitor the progress on the lower right corner and wait for the application to be deployed. (Figure 60)
Figure 60. Project deployment monitor
f. Verify at the console that the CreditApporvalSCAModuleApp is started. (Figure 61)
Figure 61. Administrative console messages
g. 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
h. Choose the existing WebSphere Process Server and select Set server as project default, then Finish. (Figure 63)
Figure 63. Set server
i. When the application executes, enter the application test data shown in Figure 64.
Figure 64. Enter SCA application test data
j. You should get the results shown in Figure 65.
Figure 65. SCA application test results
k. 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

Part 2: Assembling SCA components
Part 3: Integrating SCA modules with imports and exports
Part 4: Integrating with JMS and Web services
Download
Name Size Download method
SCA_ArticleSeries.zip 4 KB FTP | HTTP
Information about download methods
Resources
IBM WebSphere: Deployment and Advanced Configuration
WebSphere Process Server: IBM's new foundation for SOA
Introduction to Service Data Objects
Simplified Data Access with SDO
About the authors

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

IBM - SOA Using SCA Part 1

Diunggah oleh

Informasi Dokumen

Deskripsi Asli:

Judul Asli

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

IBM - SOA Using SCA Part 1

Diunggah oleh

Hak Cipta:

Format Tersedia

IBM WebSphere Developer Technical Journal: Building SOA solutions with the Servi...

IBM WebSphere Developer Technical Journal:

Roland Barcia (barcia@us.ibm.com), Certified IT Specialist, IBM

From the IBM WebSphere Developer Technical Journal.

Figure 1. SCA in WebSphere Process Server

Figure 2. Define dependencies between components

Figure 3. Components packaged with dependencies

Figure 4. Standalone reference for non-SCA artifacts

Figure 5. SCA imports and exports

Figure 6. SCA imports and exports

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?

the data included in the data object.

Figure 8. WebSphere Process Server business objects

public DataObject calulateCreditScore(DataObject creditApp)

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");

WebSphere Integration Developer and WebSphere Process Server

Build your first SCA project

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

Figure 9. Open a blank workspace in WebSphere Integration Developer

2. Close the Welcome screen.

Figure 10. Create new module

Figure 11. Create new module

Create the business objects

Figure 12. Create a new business object

b. Name your business object CreditApplication as shown in Figure 13.

Figure 13. Define business object

Figure 14. Business Integration menu

2. We will now define the attributes of the CreditApplication business object.

Figure 15. Add Attribute icon

Figure 16. Define attribute

Figure 17. Define attributes

e. Save and close the Business Object Editor.

Figure 18. Defined business object

3. We will now create a second business object to represent the response.

Figure 19. Change attribute type

c. Save and close the Business Object Editor

You now have two business objects created.

Define the service interface

Figure 20. Create a new interface

Figure 21. Create a new interface

Figure 22. Add Request Response Operation icon

Figure 23. Define operation

Figure 24. Add Input icon

e. Name the input CreditApplication.

Figure 25. New business object is now a valid type

g. Next, select the Add Output icon as shown in Figure 26.

Figure 26. Add Output icon

Figure 27. Define output

i. Save and close the Interface Editor.

Figure 28. View WSDL file

Generate the component and provide an implementation

1. First, we will define the SCA component.

Figure 29. Open SCA Assembly Editor

Figure 30. Drag interface onto Assembly Editor

Figure 31. Component Creation text box

Figure 32. SCA component icon

System.out.println("*** BOFactory created ");

System.out.println("*** credit rating object created ");