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

Page 1 of 26

IBM WebSphere Developer Technical Journal: Building SOA solutions with the Service Component Architecture -- Part 3
Integrating SCA modules with imports and exports

Level: Intermediate Roland Barcia (barcia@us.ibm.com), Certified IT Specialist, IBM Jeff Brent (jeffb@us.ibm.com), Advisory Software Engineer, IBM 22 Feb 2006 Build vertical integration solutions from a variety of components with the Service Component Architecture (SCA) and IBM® WebSphere® Integration Developer.

Introduction
In Part 1 of this series, we introduced the Service Component Architecture (SCA) as a programming model for building and assembling integration solutions with an overview of what SCA is, and with definitions of some related terminology. In Part 2, we discussed references and qualifiers, and explained how to wire various components together to create an SCA module. In Part 3, we look closer at one of the major benefits of building SCA modules, which is the ability to vertically build integration solutions from a variety of components. As systems grow and become more complex, it becomes necessary to integrate various solutions horizontally; different departments in an organization may need to build their own solutions and later integrate them together, or perhaps different business partners will need to integrate their solutions over the internet. Figure 1 shows an example of this horizontal integration: Figure 1. Integrating systems

http://www.ibm.com/developerworks/websphere/techjournal/0602_barcia/0602_barcia.... 4/10/2008

IBM WebSphere Developer Technical Journal: Building SOA solutions with the Servi... Page 2 of 26

We defined SCA imports and exports in Part 1, but we will delve deeper into them here and continue building our scaleddown example. Specifically, we will focus on SCA imports and exports using an SCA binding. SCA bindings enable SCA components in one module to communicate with SCA components in another module using the SCA programming model. With this article, we have also upgraded to IBM WebSphere Integration Developer V6.0.1, which enables us to build integrated solutions that bring IBM WebSphere Process Server V6.0.1 or IBM WebSphere Enterprise Service Bus V6.0.1 solutions together. With this new version, we also add support for building various enterprise service bus (ESB) mediations. (The WebSphere ESB runtime is a subset of WebSphere Process Server; see Resources for more information.)

A review of imports and exports
As we mentioned in Part 1, the mechanisms used for module-to-module and module-to-external service invocation are called imports and exports, respectively. Imports and exports are expressed from the perspective of the module, which is a selfcontained 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 with 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 2 shows an SCA assembly with imports and exports. The figure shows how exports are an entry point from the outside world, while imports enable you to call outside the module. Figure 2. SCA imports and exports

http://www.ibm.com/developerworks/websphere/techjournal/0602_barcia/0602_barcia.... 4/10/2008

IBM WebSphere Developer Technical Journal: Building SOA solutions with the Servi... Page 3 of 26

When invoking SCA components through imports and exports, parameters are passed by-value, meaning the parameters are copied from structure to another. Figure 3 shows two SCA modules communicating with each other, and illustrates how an SCA import matches up with an SCA export. Figure 3. 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. Imports and exports can bind to other technologies such as JMS, Enterprise JavaBeans (EJB), or Web services, as illustrated in Figure 4. Binding to these technologies enables a Web service client to invoke an SCA module, or an SCA module to invoke an existing EJB module using the SCA programming model (There are some limitations to using EJB imports because they are defined by a Java™ Interface; therefore, something like BPEL -- which requires partners to support WSDL -- cannot invoke an EJB import. More on this later). Figure 4. Imports and exports with other technologies

http://www.ibm.com/developerworks/websphere/techjournal/0602_barcia/0602_barcia.... 4/10/2008

IBM WebSphere Developer Technical Journal: Building SOA solutions with the Servi... Page 4 of 26

Import/export bindings
A key to service-oriented architecture is the ability to expose services with a number of binding options and the ability to call services using industry norms. As stated, WebSphere Process Server and WebSphere ESB provide a number of different binding types to facilitate this need. Binding types are associated with imports and exports using the Assembly Editor. Today, there are five primary binding types: 1. SCA - The binding used for SCA invocations between modules. This binding type is the simplest to configure and provides seamless integration between modules. 2. Web service - Provides the ability to invoke existing Web services and expose functionality within the module as a Web service. By default, the Web service leverages the doc-lit wrapped style and can be used with the HTTP and JMS protocol. The Web service binding capabilities are derived by the underlying WebSphere Application Server base Web service engine and are subject to the same limitations. 3. Enterprise Information Systems (EIS) - Provides the ability to integrate to existing EIS systems via a WebSphere JCA Adapter. The configuration available for this binding type will vary depending upon the target (SAP, JDBC Adapter, and so on). Enterprise Data Discovery services are typically provided with each adapter to facilitate the creation of business object and import and export bindings. 4. Java Messaging Service - Provides the ability to integrate with endpoints that use JMS for a messaging protocol. The imports and exports in this case use data bindings to help resolve to the correct business object/operation combination. 5. Stateless session bean - Provides the ability to integrate to stateless session beans using a Java interface. This capability is only available by wiring a Java reference to a Java interface. Components that use WSDL references are not permitted in WebSphere Integration Developer to wire to the Java interface provided by the stateless session bean. An intermediate component with a WSDL interface and a Java reference is required in this case. In this article, we will explore the SCA binding more closely. Subsequent articles in this series will take a closer look at some of the other import/export bindings.

SCA binding
An SCA binding provides a consistent means for communicating across module boundaries in a WebSphere Process Server or WebSphere ESB environment. The underlying protocol used by the SCA binding is selected automatically based on the invocation pattern used by the client module. SCA provides four invocation patterns. Synchronous - Client issues a request and waits for the response. Asynchronous one-way - Client issues a request and a response is not expected.

http://www.ibm.com/developerworks/websphere/techjournal/0602_barcia/0602_barcia.... 4/10/2008

IBM WebSphere Developer Technical Journal: Building SOA solutions with the Servi... Page 5 of 26

Asynchronous deferred response - Client issues a request and the response will be requested by the client at a later point in time. Asynchronous call back - Client issues a request and the target will call a service implemented by the client with the response. The WebSphere Process Server or WebSphere ESB SCA runtime will decide when to use the underlying system integration bus (for asynchronous invocation patterns), or RMI/IIOP (for the synchronous invocation pattern). The SCA binding capability is driven by the export. During the installation process of an SCA module to a WebSphere Process Server, the necessary support artifacts are created: For asynchronous invocations, cell scoped service integration bus (SIBus) destinations are created in the SCA.SYSTEM.<cell name>.Bus. For synchronous communication, a cell scoped name space binding that points to the module session bean is created; a module session bean is a stateless session bean that is used by the module for a variety of purposes, such as unit of work boundaries, security configuration, and so on. The import and export files work together, where the import file contains important information about the export, helping any number of clients to import a target service. Using the information in the .import file and the invocation pattern (sync or async) the SCA runtime identifies whether to use a SIBus destination or a WebSphere name space binding. A number of SIBus (see Resources) destinations are created to support the variety of asynchronous invocation types that WebSphere Process Server and WebSphere ESB provide; destinations are created for the module, component, imports, and exports. Each destination and forward routing path ensures that the message is routed to the correct target service. Figure 5 shows an example of SIBus destinations. Figure 5. SIBus destinations

In addition, a name space binding is created for every SCA export within a module, as shown in Figure 6. This binding is created at the cell scope and follows the naming pattern of: sca_ + <Module Name> + _export_ + <ExportName>. Figure 6. Name space bindings

Given the scope of these two sets of artifacts, the SCA export binding is visible throughout the cell. The client module and the target module can be placed on any WebSphere Process Server or WebSphere ESB server in the cell and still be able to communicate.

Qualifiers with imports
An import with an SCA binding is a logical representation of an SCA component in another module. As such, you can define

http://www.ibm.com/developerworks/websphere/techjournal/0602_barcia/0602_barcia.... 4/10/2008

IBM WebSphere Developer Technical Journal: Building SOA solutions with the Servi... Page 6 of 26

qualifiers on the reference that point to the import in much the same way as shown in Figure 7. Figure 7. Add qualifier

Exports do not contain any qualifiers; instead, you put a qualifier on the component you are exporting, which is explained in detail in Part 2.

Library projects
When crossing module boundaries, one has to consider the fact that the contracts are shared. Applications communicate through interfaces and pass data objects to each other. This means that interfaces and business objects need to be visible or colocated with the modules. To reduce the replication of defining the same interfaces and data objects in every module, WebSphere Integration Developer contains a special SCA library module, which can be added to an SCA module much like a Java JAR file can be a dependent JAR in an EAR file. (In fact, this is how WebSphere Integration Developer treats a library under the covers.) This enables you to define interfaces and business objects in a single location and have all the modules share them. We will see an example of an SCA library later.

Our sample application
We will continue our Credit Approval application example used throughout the series. In this article, we will show you how to configure exports and imports by externalizing the Credit History and Credit Agency modules to separate modules. For illustration purposes, we will also show how to share SCA libraries among modules. To run this example, you will need to have WebSphere Integration Developer V6.0.1 (which supports WebSphere ESB) properly installed and running on your machine (see Resources), plus the download materials included with this article, which contain two SCA modules (Credit Agency and Credit History modules) and an SCA library with the shared interfaces and business objects. 1. Set up the workspace. a. Launch WebSphere Integration Developer. Open a new workspace and close the welcome screen. b. You will need to import the Project Interchange you downloaded. To import the Project Interchange right-click in the Business Integration view and then select Import, as shown in Figure 8. Figure 8. Eclipse Import wizard

http://www.ibm.com/developerworks/websphere/techjournal/0602_barcia/0602_barcia.... 4/10/2008

IBM WebSphere Developer Technical Journal: Building SOA solutions with the Servi... Page 7 of 26

c. Select Project Interchange and then Next (Figure 9). Figure 9. Import Project Interchange

d. Select the download file <Download_root>/SCAArticlePart3.zip, then Select All, and Finish (Figure 10). Figure 10. Select All

http://www.ibm.com/developerworks/websphere/techjournal/0602_barcia/0602_barcia.... 4/10/2008

IBM WebSphere Developer Technical Journal: Building SOA solutions with the Servi... Page 8 of 26

2. Examine the artifacts that we just imported: a. From the Business Integration perspective, expand CreditApprovalLibrary. As mentioned earlier, an SCA library is a convenient way to hold business objects and interfaces that are shared between modules. Figure 11 shows the CreditApprovalLibrary in the Business Integration View. Figure 11. CreditApprovalLibrary

You can easily create a Library project from the context sensitive menu within the Business Integration perspective by selecting New => Library. In this case, we have already provided the interfaces and DataObjects.

http://www.ibm.com/developerworks/websphere/techjournal/0602_barcia/0602_barcia.... 4/10/2008

IBM WebSphere Developer Technical Journal: Building SOA solutions with the Servi... Page 9 of 26

b. Expand both the CreditAgencySCAModule and the CreditHistory modules. c. Open the assembly editor for each module. In our previous example in Part 2, we had a single module with several components. In this example, we separated out the implementations to mimic separate solutions. Usually, an SCA module has a complete solution with several components. For the purpose of this article, we are assuming that these are full-fledged solutions developed by different development groups (with different managers, schedules, and project plans). Figure 12 shows the SCA modules in the Business Integration view. Figure 12. SCA modules

d. Both SCA modules depend on the SCA library module; this dependency can be viewed in the Dependency Editor. Right-click each SCA module, one at a time, and select Open Dependency Editor (Figure 13). Figure 13. Opening the Dependency Editor

e. Examine the Dependency Editor for each to make sure that the CreditApprovalLibrary is shared between modules, in which case CreditApprovalLibrary would display, as in Figure 14. Figure 14. CreditApprovalLibrary

f. Close the editors.

http://www.ibm.com/developerworks/websphere/techjournal/0602_barcia/0602_barcia.... 4/10/2008

IBM WebSphere Developer Technical Journal: Building SOA solutions with the Se... Page 10 of 26

Create SCA exports
Next, we will create SCA exports for each module so that the module can be invoked from other SCA modules. 1. Create the export for CreditAgencySCAModule: a. In WebSphere Integration Developer, open the CreditAgencySCAModule assembly editor. Expand the CreditAgencySCAModule in the Business Integration view and double click the CreditAgencySCAModule Assembly Editor icon, as shown in Figure 15 below. Figure 15. Open Assembly Editor

b. To create the export, right-click the CreditApproval component and select Export =>SCA Binding (Figure 16). Figure 16. Create an SCA export with SCA binding

c. An export for the CreditAgency component with an SCA binding will automatically be created, as shown in Figure 17. Figure 17. SCA export

d. Examine the properties of the export by looking at the Properties view while the export is selected in the assembly editor. In the Details tab, you will notice the SCA details of the operation, as shown in Figure 18. Figure 18. SCA export details

http://www.ibm.com/developerworks/websphere/techjournal/0602_barcia/0602_barcia.... 4/10/2008

IBM WebSphere Developer Technical Journal: Building SOA solutions with the Se... Page 11 of 26

e. Switch to the Qualifiers tab (Figure 19). You will notice you cannot add any qualifiers. This is because exports just use the qualifiers of the component to which it is pointing. Figure 19. No qualifiers for exports

f. Save and close the assembly editor. 2. Similarly, create an export for the CreditHistorySCAModule: a. As before, open the assembly editor for CreditHistorySCAModule. b. Generate the export with an SCA binding as before (Figure 20). Figure 20. SCA export

c. Save and close the editor.

Create Credit Approval module
We will now create the CreditApprovalModule that will invoke the other two solutions through imports. 1. First, create a new SCA module: a. Right-click in the Business Integration view and select New => Module.

http://www.ibm.com/developerworks/websphere/techjournal/0602_barcia/0602_barcia.... 4/10/2008

IBM WebSphere Developer Technical Journal: Building SOA solutions with the Se... Page 12 of 26

b. Name the module CreditApprovalSCAModule (Figure 21). Be sure Use Default is checked, then Finish. Figure 21. New SCA module

c. Right click the newly created CreditApprovalSCAModule and select Open Dependency Editor (Figure 22). Figure 22. Open Dependency Editor

d. Because the CreditApproval module will be invoking the other two modules, we need to share the interfaces and business objects we are passing back and forth. Remember, we are using a library to store them. In the Dependency Editor, select Add in the Libraries section, as shown in Figure 23. Figure 23. Add Library to SCA module

http://www.ibm.com/developerworks/websphere/techjournal/0602_barcia/0602_barcia.... 4/10/2008

IBM WebSphere Developer Technical Journal: Building SOA solutions with the Se... Page 13 of 26

e. Select CreditApprovalLibrary and OK. 2. We will now create an invoking component. For illustration purposes, we will use a simple Java-based component; in future articles, we will show a BPEL flow invoking various components and modules. a. Open the CreditApprovalSCAModule assembly editor by double clicking the CreditApprovalSCAModule Assembly icon (Figure 24). Figure 24. Open SCA Assembly Editor

b. Drag an SCA component

(Figure 25) onto the assembly editor.

Figure 25. Drag an SCA component onto the Assembly Editor

http://www.ibm.com/developerworks/websphere/techjournal/0602_barcia/0602_barcia.... 4/10/2008

IBM WebSphere Developer Technical Journal: Building SOA solutions with the Se... Page 14 of 26

c. Rename the component CreditApproval by clicking on the text and typing the name as shown in Figure 26. Figure 26. Change component name

3. Next, we will add an interface to our component. We stored the interface in the Library project. a. Click the Interface icon (circled in Figure 27) on the component, then select CreditRequest from the menu. Figure 27. Add Interface to SCA component

b. Press OK. We have just created an SCA component. This SCA component will invoke our other two modules through imports.

http://www.ibm.com/developerworks/websphere/techjournal/0602_barcia/0602_barcia.... 4/10/2008

IBM WebSphere Developer Technical Journal: Building SOA solutions with the Se... Page 15 of 26

Create imports
With our exports completed, we are now ready to create our SCA imports. We need to create an SCA import for each export we are going to call. In our case, we will: Call the CreditAgency module, as well as CreditHistory. Update the qualifier for the CreditHistory import to handle proper transactional behavior when invoking a component asynchronously. Assume the History request will take some time to invoke, so we will issue the history request asynchronously. After the request, invoke the CreditAgency module synchronously. After obtaining the credit score, get the History Response in a deferred fashion. 1. First, create the import for the CreditAgency invocation: a. Drag the import icon from the palette on to the assembly editor (Figure 28). Figure 28. Drag an import onto Assembly Editor

b. Rename the import by clicking on the text and typing in CreditAgencyImport as shown in Figure 29. Figure 29. Rename import

2. Next, we will add the proper interface. In this case, the interface for the import must match the import for the corresponding export in the CreditAgencySCAModule. Click the Interface icon that is over the Import (circled in Figure 30), then select the CreditAgency interface. Figure 30. Add import to SCA import

http://www.ibm.com/developerworks/websphere/techjournal/0602_barcia/0602_barcia.... 4/10/2008

IBM WebSphere Developer Technical Journal: Building SOA solutions with the Se... Page 16 of 26

3. Add the proper binding, in this case, an SCA binding: a. Right-click the import and select Generate Binding => SCA Binding (Figure 31). Figure 31. Add SCA binding to Import

b. With the import highlighted in the assembly editor, go to the Properties view and select the Binding section (Figure 32). Click Browse. Figure 32. Browse for export

c. Select CreditAgencyExport (Figure 33).

http://www.ibm.com/developerworks/websphere/techjournal/0602_barcia/0602_barcia.... 4/10/2008

IBM WebSphere Developer Technical Journal: Building SOA solutions with the Se... Page 17 of 26

Figure 33. Select export

4. Next, we need to wire the CreditApproval component to the CreditAgencyImport. a. Select the CreditApproval component in the assembly editor and drag a wire to the CreditAgencyImport. Figure 34. Wire SCA component to SCA import

b. Press OK in the dialog box to create a reference on the CreditApproval component (Figure 35). (References were discussed in Part 2.) Figure 35. Confirm reference creation

c. Save the editor but keep it open. The figure below shows the final result of the wired component. Figure 36. Wired SCA module

http://www.ibm.com/developerworks/websphere/techjournal/0602_barcia/0602_barcia.... 4/10/2008

IBM WebSphere Developer Technical Journal: Building SOA solutions with the Se... Page 18 of 26

5. Next, we will create the import for the CreditHistoryModule. a. As before, drag another import onto the assembly editor and name it CreditHistoryImport. b. Add the CreditHistory interface to the import, as shown in Figure 37. Figure 37. Add Credit History Interface

c. Generate an SCA binding and wire the CreditApproval to the CreditHistoryImport. Figure 38 shows the final result. Figure 38. Final result

Remember, we are assuming that the Credit History component takes a bit longer, so we first fire off an asynchronous request to get the History, and retrieve the response at a point later in time. While the CreditHistory is executing, we will get the Credit Score from the CreditAgency module. We will then grab the response from the CreditHistory. We can make the invocation to the Credit History module asynchronous by using the correct SCA API for the "service". In this case, we wish to use the deferred response invocation pattern described earlier.

Generate the implementation
1. We will now create an implementation for the CreditApproval component. In our example, we will use a simple Java component. a. In the assembly editor, right-click the CreditApproval component and select Generate Implementation => Java. Figure 39. Generate Java implementation

http://www.ibm.com/developerworks/websphere/techjournal/0602_barcia/0602_barcia.... 4/10/2008

IBM WebSphere Developer Technical Journal: Building SOA solutions with the Se... Page 19 of 26

b. For now, put the class in the default package (Figure 40). Figure 40. Default package

c. Select Yes in the Implement As... dialog to create a matching Java interface, in case you want to add local Java client later (Figure 41). Figure 41. Create Java Interface for local Java clients

2. We will now code the implementation. a. The implementation class should be open in the Java Editor. As you can see in the Java editor, WebSphere

http://www.ibm.com/developerworks/websphere/techjournal/0602_barcia/0602_barcia.... 4/10/2008

IBM WebSphere Developer Technical Journal: Building SOA solutions with the Se... Page 20 of 26

Integration Developer added convenient helpers for getting the partners by examining the module assembly. If we had generated the Java class first, then these methods would not exist.
public CreditAgency locateService_CreditAgencyPartner() { return (CreditAgency) ServiceManager.INSTANCE .locateService("CreditAgencyPartner"); } public CreditHistory locateService_CreditHistoryPartner() { return (CreditHistory) ServiceManager.INSTANCE .locateService("CreditHistoryPartner"); }

b. Paste the code below (from <download_root>/SCAArticleSeries3/codeSnippet1.txt) inside the calulateCreditScore method. The asynchronous invocation pattern is highlighted in bold type.
ServiceManager serviceManager = new ServiceManager(); // create credit rating return data object using the BO factory BOFactory bof = (BOFactory)serviceManager.locateService("com/ibm/websphere/bo/BOFactory" ); DataObject creditRating = bof.create("http://CreditApproval", "CreditRating"); creditRating.setString("customerId", creditApp.getString("customerId")); // create and call credit history service using async deferred response invocation // pattern. CreditHistoryAsync cha = (CreditHistoryAsync) serviceManager.locateService("CreditHistoryPartner"); Ticket tix = cha.getCreditLimitAsync(creditApp); CreditAgency creditAgency = (CreditAgency) locateService_CreditAgencyPartner(); Integer creditScore = creditAgency.getCreditScore(creditApp); Double creditLimit = cha.getCreditLimitResponse(tix, Service.WAIT); creditRating.setInt("creditScore", creditScore.intValue()); creditRating.setDouble("creditLimit", creditLimit.doubleValue()); return creditRating;

c. You should have a few compile errors in the Eclipse Editor (assuming you have automatic builds enabled) because we are missing imports. Right-click anywhere in the Java editor and select Source => Organize Imports, as shown in Figure 42. Figure 42. Organize imports

d. Resolve the BOFactory interface to com.ibm.websphere.bo as shown in Figure 43. Figure 43. Resolving BOFactory

e. Resolve the Service interface to com.ibm.websphere.sca as shown in Figure 44. Figure 44. Resolve the service import to com.ibm.websphere.sca

http://www.ibm.com/developerworks/websphere/techjournal/0602_barcia/0602_barcia.... 4/10/2008

IBM WebSphere Developer Technical Journal: Building SOA solutions with the Se... Page 21 of 26

f. Save the assembly editor.

Test the solution
We are now ready to test our solution. When integrating modules, each module should first be properly unit tested. For our purposes, we will assume that the various development teams (CreditHistory and CreditAgency) have appropriately tested their components. 1. Add all three modules to WebSphere Process Server: a. In WebSphere Integration Developer, go to the Servers view, right-click WebSphere Process Server and select Add/Romove Project (Figure 45). Figure 45. Adding and removing projects to WebSphere Process Server

b. Select Add All to add all of the SCA modules to the server (Figure 46). Figure 46. Adding all modules

http://www.ibm.com/developerworks/websphere/techjournal/0602_barcia/0602_barcia.... 4/10/2008

IBM WebSphere Developer Technical Journal: Building SOA solutions with the Se... Page 22 of 26

c. Press Finish. 2. Launch the server through the WebSphere Integration Developer component testing tool. a. From the assembly editor of the CreditApproval modules, right-click the CreditApproval component and select Test Component, as shown in Figure 47. Figure 47. Launch the Test Component feature

b. Go to the Configurations tab and remove the two emulators, as shown in Figure 48. Emulators enable you to mimic a partner if one is not available, since we have the actual components, we do not need to mimic them. Figure 48. Remove emulators

http://www.ibm.com/developerworks/websphere/techjournal/0602_barcia/0602_barcia.... 4/10/2008

IBM WebSphere Developer Technical Journal: Building SOA solutions with the Se... Page 23 of 26

c. Back on the Events page, enter some input data in the Initial request parameters, as shown in Figure 49, and then Continue. Figure 49. Run component test

d. In the Deployment Location dialog, select WebSphere Process Server v6.0. (Figure 50) Figure 50. Select WebSphere Process Server runtime

http://www.ibm.com/developerworks/websphere/techjournal/0602_barcia/0602_barcia.... 4/10/2008

IBM WebSphere Developer Technical Journal: Building SOA solutions with the Se... Page 24 of 26

3. Let's examine the invocation path and results. a. Go back to the Events tab. Select the last Return from the call path to see the result as shown in Figure 51. Figure 51. Select Return

b. You should receive a result similar to that shown in Figure 52. Figure 52. Results

http://www.ibm.com/developerworks/websphere/techjournal/0602_barcia/0602_barcia.... 4/10/2008

IBM WebSphere Developer Technical Journal: Building SOA solutions with the Se... Page 25 of 26

c. If you examine the call order, you will see the asynchronous invocation: instead of request - response - request response, we have async request - request - response - async response. (Figure 53) Figure 53. Asynchronous call path

d. Close the test editor without saving and stop the server.

Conclusion
Imports and exports enable us to expose out solutions in service-oriented fashion. In this article, you learned how to integrate SCA solutions using SCA import and exports. In Part 4, we will examine integrating with other solutions using some of the other bindings such as Web services and JMS.

Acknowledgements
The authors would like to thank Eric Herness for reviewing the article.

More articles in this series
Part 1: Oh great, another programming model?

http://www.ibm.com/developerworks/websphere/techjournal/0602_barcia/0602_barcia.... 4/10/2008

IBM WebSphere Developer Technical Journal: Building SOA solutions with the Se... Page 26 of 26

Part 2: Assembling SCA components Part 4: Integrating with JMS and Web services

Download
Description Code sample Name SCAArticleSeries3.zip Size Download method 37 KB FTP | HTTP

Information about download methods

Resources
WebSphere Service Integration Bus resources WebSphere Enterprise Service Bus product information Building an Enterprise Service Bus with WebSphere Application Server V6 Deploying message-driven beans and JMS applications into the Service Integration Bus Deploying publish and subscribe applications into the Service Integration Bus A practical introduction to message mediation WebSphere Process Server: IBM's new foundation for SOA Introduction to Service Data Objects Simplified Data Access with SDO IBM WebSphere: Deployment and Advanced Configuration

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.

http://www.ibm.com/developerworks/websphere/techjournal/0602_barcia/0602_barcia.... 4/10/2008

Master your semester with Scribd & The New York Times

Special offer for students: Only $4.99/month.

Master your semester with Scribd & The New York Times

Cancel anytime.