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

Integrating SCA modules with imports and exports

Build vertical integration solutions from a variety of components with the Service Component Architecture (SCA) and IBM® WebSphere® Integration Developer.

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.



22 February 2006

Also available in Chinese Russian

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
Figure 1. Integrating systems

We defined SCA imports and exports in Part 1, but we will delve deeper into them here and continue building our scaled-down 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 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 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
Figure 2. SCA imports and exports

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
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
Figure 4. Imports and exports with other technologies

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.
  • 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
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
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 qualifiers on the reference that point to the import in much the same way as shown in Figure 7.

Figure 7. Add qualifier
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 co-located 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.

    1. Launch WebSphere Integration Developer. Open a new workspace and close the welcome screen.

    2. 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
      Figure 8. Eclipse Import wizard
    3. Select Project Interchange and then Next (Figure 9).

      Figure 9. Import Project Interchange
      Figure 9. Import Project Interchange
    4. Select the download file <Download_root>/SCAArticlePart3.zip, then Select All, and Finish (Figure 10).

      Figure 10. Select All
      Figure 10. Select All
  2. Examine the artifacts that we just imported:

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

    2. Expand both the CreditAgencySCAModule and the CreditHistory modules.

    3. 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
      Figure 12. SCA modules
    4. 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
      Figure 13. Opening the Dependency Editor
    5. 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
      Figure 14. CreditApprovalLibrary
    6. Close the editors.

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:

    1. 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
      Figure 15. Open Assembly Editor
    2. 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
      Figure 16. Create an SCA export with SCA binding
    3. An export for the CreditAgency component with an SCA binding will automatically be created, as shown in Figure 17.

      Figure 17. SCA export
      Figure 17. SCA export
    4. 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
      Figure 18. SCA export details
    5. 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
      Figure 19. No qualifiers for exports
    6. Save and close the assembly editor.

  2. Similarly, create an export for the CreditHistorySCAModule:

    1. As before, open the assembly editor for CreditHistorySCAModule.

    2. Generate the export with an SCA binding as before (Figure 20).

      Figure 20. SCA export
      Figure 20. SCA export
    3. 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:

    1. Right-click in the Business Integration view and select New => Module.

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

      Figure 21. New SCA module
      Figure 21. New SCA module
    3. Right click the newly created CreditApprovalSCAModule and select Open Dependency Editor (Figure 22).

      Figure 22. Open Dependency Editor
      Figure 22. Open Dependency Editor
    4. 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
      Figure 23. Add Library to SCA module
    5. 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.

    1. Open the CreditApprovalSCAModule assembly editor by double clicking the CreditApprovalSCAModule Assembly icon (Figure 24).

      Figure 24. Open SCA Assembly Editor
      Figure 24. Open SCA Assembly Editor
    2. Drag an SCA component Component icon (Figure 25) onto the assembly editor.

      Figure 25. Drag an SCA component onto the Assembly Editor
      Figure 25. Drag an SCA component onto the Assembly Editor
    3. Rename the component CreditApproval by clicking on the text and typing the name as shown in Figure 26.

      Figure 26. Change component name
      Figure 26. Change component name
  3. Next, we will add an interface to our component. We stored the interface in the Library project.

    1. Click the Interface icon (circled in Figure 27) on the component, then select CreditRequest from the menu.

      Figure 27. Add Interface to SCA component
      Figure 27. Add Interface to SCA component
    2. Press OK.

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


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:

    1. Drag the import icon from the palette on to the assembly editor (Figure 28).

      Figure 28. Drag an import onto Assembly Editor
      Figure 28. Drag an import onto Assembly Editor
    2. Rename the import by clicking on the text and typing in CreditAgencyImport as shown in Figure 29.

      Figure 29. Rename import
      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
    Figure 30. Add import to SCA import
  3. Add the proper binding, in this case, an SCA binding:

    1. Right-click the import and select Generate Binding => SCA Binding (Figure 31).

      Figure 31. Add SCA binding to Import
      Figure 31. Add SCA binding to Import
    2. 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
      Figure 32. Browse for export
    3. Select CreditAgencyExport (Figure 33).

      Figure 33. Select export
      Figure 33. Select export
  4. Next, we need to wire the CreditApproval component to the CreditAgencyImport.

    1. Select the CreditApproval component in the assembly editor and drag a wire to the CreditAgencyImport.

      Figure 34. Wire SCA component to SCA import
      Figure 34. Wire SCA component to SCA import
    2. 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
      Figure 35. Confirm reference creation
    3. Save the editor but keep it open. The figure below shows the final result of the wired component.

      Figure 36. Wired SCA module
      Figure 36. Wired SCA module
  5. Next, we will create the import for the CreditHistoryModule.

    1. As before, drag another import onto the assembly editor and name it CreditHistoryImport.

    2. Add the CreditHistory interface to the import, as shown in Figure 37.

      Figure 37. Add Credit History Interface
      Figure 37. Add Credit History Interface
    3. Generate an SCA binding and wire the CreditApproval to the CreditHistoryImport. Figure 38 shows the final result.

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

    1. In the assembly editor, right-click the CreditApproval component and select Generate Implementation => Java.

      Figure 39. Generate Java implementation
      Figure 39. Generate Java implementation
    2. For now, put the class in the default package (Figure 40).

      Figure 40. Default package
      Figure 40. Default package
    3. 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
      Figure 41. Create Java Interface for local Java clients
  2. We will now code the implementation.

    1. The implementation class should be open in the Java Editor. As you can see in the Java editor, WebSphere 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");
      }
    2. 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;
    3. 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
      Figure 42. Organize imports
    4. Resolve the BOFactory interface to com.ibm.websphere.bo as shown in Figure 43.

      Figure 43. Resolving BOFactory
      Figure 43. Resolving BOFactory
    5. 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
      Figure 44. Resolve the service import to com.ibm.websphere.sca
    6. 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:

    1. 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
      Figure 45. Adding and removing projects to WebSphere Process Server
    2. Select Add All to add all of the SCA modules to the server (Figure 46).

      Figure 46. Adding all modules
      Figure 46. Adding all modules
    3. Press Finish.

  2. Launch the server through the WebSphere Integration Developer component testing tool.

    1. 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
      Figure 47. Launch the Test Component feature
    2. 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
      Figure 48. Remove emulators
    3. 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
      Figure 49. Run component test
    4. In the Deployment Location dialog, select WebSphere Process Server v6.0. (Figure 50)

      Figure 50. Select WebSphere Process Server runtime
      Figure 50. Select WebSphere Process Server runtime
  3. Let's examine the invocation path and results.

    1. 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
      Figure 51. Select Return
    2. You should receive a result similar to that shown in Figure 52.

      Figure 52. Results
      Figure 52. Results
    3. 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
      Figure 53. Asynchronous call path
    4. 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


Download

DescriptionNameSize
Code sampleSCAArticleSeries3.zip  ( HTTP | FTP )37 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 Business process management on developerWorks


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