Introduction

The well-known publish/subscribe interaction pattern (see Wikipedia for a definition) supports one of the key principles of service oriented architectures – loose coupling. In the context of publish/subscribe, the publisher or producer of a message or event does not know about any potential subscriber or consumer of that message or event. Only a topic couples the publisher and subscriber; publishers publish to a topic and subscribers subscribe to a topic. The underlying messaging or event infrastructure is responsible for delivery from publisher to subscribers.

What does that mean for IBM WebSphere Process Server V6 (hereafter referred to as WebSphere Process Server) and IBM WebSphere Enterprise Service Bus V 6.0.1 (hereafter referred to as WebSphere ESB)? Both use the Service Component Architecture (SCA) supported by a number of industry vendors. See the developerWorks article Service Component Architecture for more information. Figure 1 shows the SCA module, which is the basic assembly model for SCA. SCA modules communicate with other SCA modules by means of exports and imports. Exports allow a module to receive requests, and imports allow a module to send requests.

Mapping publish/subscribe to an SCA environment results logically insomething like Figure 2. The publisher has an import that enables it to leverage a publish/subscribe capable communication infrastructure, and the subscriber has an export that enables it to leverage that same communication infrastructure. The key point is that it is the communication infrastructure, not the SCA environment or the publisher or subscriber, that implements the publish/subscribe interaction pattern.

WebSphere Process Server and WebSphere ESB use an SCA environment that supports several bindings for interaction between services. The most commonly used binding is the Web service binding, via HTTP or JMS, but the JAX-RPC compliant Web service binding does not naturally support a publish/subscribe interaction pattern, even via JMS. Likewise, the SCA binding does not naturally support a publish/subscribe interaction pattern. The JMS binding can support a publish/subscribe interaction pattern because JMS 1.1 mandates that JMS providers support publish/subscribe (see the Java Message Service 1.1 Specification).

This article describes the basic technique for creating publish/subscribe interaction patterns using JMS bindings with the WebSphere Application Server default messaging provider as the JMS provider. The default messaging provider, which is included with WebSphere Application Server Version 6 (hereafter referred to as WebSphere Application Server) and beyond, supports all the facilities of the JMS API. In particular, it provides queues for point-to-point interaction and topic spaces for publish/subscribe interactions. Figure 3 shows the publish/subscribe application built in this article. A publisher module uses an export with a JMS binding to publish a request to any subscribers. The JMS binding delivers the request to a default messaging provider topic space. Two subscribers, Subscriber1 and Subscriber2 receive the request from the topic space.

This article assumes you are using WebSphere ESB V6.0.1 or above. It further assumes you are familiar with IBM WebSphere Integration Developer v. 6.0.1 (hereafter referred to as WebSphere Integration Developer) or above to facilitate construction and testing of the SCA modules in the included examples.

Back to top

Set up the publish/subscribe infrastructure

Before creating the publisher and subscriber modules, you need to set up the JMS infrastructure. The first step is to create the WebSphere Application Server default messaging provider topic space, as shown in Figure 3. The second step is to create the required JMS artifacts: a JMS connection factory, a JMS topic, and a JMS activation specification. See Deploying publish and subscribe applications into the Service Integration Bus for more details.

To create the topic space, complete the following steps. WebSphere Application Server must be running so that you can use the administrative console.

1. In WebSphere Integration Developer, start a WebSphere Process Server instance and then log into the administrative console.
2. In the left navigation pane, select Service Integration => Buses. You'll see a list of several buses the SCA environment created. In particular, you should see the SCA.APPLICATION.widCell.Bus. This bus manages application-specific queues and topic spaces; however, you can create a separate bus for application specific purposes.
3. Select SCA.APPLICATION.widCell.Bus => Destinations.
4. A list of the bus destinations that are currently defined displays.
5. Click New.
6. You can create several types of destinations. In this case, publish/subscribe requires a topic space, so select Topic space and click Next.
7. Enter TheTopic as the Identifier, then click Next.
8. Click Next again, and then Finish.
9. Save the changes. You should see the new destination in the list, as shown in Figure 4.
   
   Figure 4. Bus destinations showing TheTopic
   
   
   

To enable SCA modules to use the topic space you created via a JMS binding, you need to create the required JMS artifacts: a JMS connection factory, a JMS topic, and a JMS activation specification.

1. In the navigation pane of the administrative console, select Resources => JMS Providers => Default Messaging.
2. In the Default Messaging Provider dialog, leave the scope as Node, and select JMSconnection factory, then clickNew.
3. In the Create dialog, enter the following values:
   • Name: TheCF
   • JNDI name: jms/TheCF
   • Bus name: SCA.APPLICATION.widCell.Bus
   • Leave the defaults for all other values, then click OK and save the changes. You should see the new connection factory as shown in Figure 5:
     
     Figure 5. JMS connection factory
     
     
     
4. Return to the Default Messaging Provider dialog and select JMS topic, then click New.
5. Enter the following values:
   • Name: TheTopic
   • JNDI name: jms/TheTopic
   • Topic name: TheTopic
   • Bus name: SCA.APPLICATION.widCell.Bus
   • Leave the defaults for all other values, click OK, and save your changes. You should see the JMS topic as shown in Figure 6:
     
     Figure 6. JMS topic
     
     
     
6. Return to the Default Messaging Provider dialog and select JMS activation specification => New.
7. Enter the following values:
   • Name: TheTAS
   • JNDI name: jms/TheTAS
   • Destination type: Topic
   • Destination JNDI name: jms/TheTopic
   • Bus name: SCA.APPLICATION.widCell.Bus
   • Leave all other default values, click OK, and save your changes. You should see the JMS activation specification as shown in Figure 7:
     
     Figure 7. JMS activation specification
     
     
     

Back to top

Create a business logic publisher

You can now create the publisher SCA module depicted in Figure 3. In this example, the publisher module emulates business logic that must understand it is a publisher. Because of this, you must choose the binding at development time.

To create the publisher SCA module, first create a library containing a business object and an interface that the publisher and the subscribers will use. To do this:

1. In WebSphere Integration Developer, open the Business Integration perspective.
2. Select New => Library, enter PubSubLib as the Name and click Finish.
3. Expand PubSubLib and select Data Types => New => Business Object.
4. In the Name field, enter Order and click Finish.
5. Add the attributes name and item, as type string. The Order business object should appear as shown in Figure 8.
   
   Figure 8. Order business object
   
   
   
6. Next, in PubSubLib, click Interfaces => New => Interface.
7. In the Name field, enter Orders and click Finish.
8. Add a one-way operation to the interface, and name it send. The operation must be one-way to enable creation of a publish/subscribe binding.
9. Add an input parameter to the send operation with the name order and with the type set to the Order business object created above. The new interface should look like Figure 9:
   
   Figure 9. Orders interface
   
   
   
10. In the Business Integration view, click New => Module.
11. In the New Module dialog, enter Publisher and click Finish.
12. For Publisher, open the dependency editor and add the PubSubLib as a library.
13. Open the assembly diagram for Publisher.
14. Add an import to the module by selecting the import and then going to the Properties view.
15. Click the Description tab and set the Display name to Publish.
16. Select the Publish import, and apply the Orders interface.
17. Right-click Publish and select Generate Binding => JMS Binding.
18. In the Import JMS Import Binding dialog shown in Figure 10, select Publish-Subscribe for JMS messaging domain, Text for the Serialization type. Click OK. The Text binding is generally best if you're dealing with components that use XML-based messages.
    
    Figure 10. JMS Import Binding dialog
    
    
    
19. In the Properties view, select the Binding tab.
20. In the JMS Import Binding tab, enter jms/TheCF as the JNDI Lookup Name for the connection factory, as shown in Figure 11:
    
    Figure 11. JMS Import Binding connection factory
    
    
    
21. In the JMS Destinations tab, expand Send Destination Properties.
22. Enter jms/TheTopic as the JNDI Lookup Name for the topic, as shown in Figure 12:
    
    Figure 12. JMS Import Binding send destination properties
    
    
    
23. Save the module. Note that in Figures 11 and 12 some fields are grayed-out. This is because the values of those fields come from the JMS artifacts looked up using the JNDI names provided.

The publisher shown in Figure 13 is now complete. Deploy the Publisher to the WebSphere Integration Developer test environment server. You don't actually need to have any real business component driving the import because WebSphere Integration Developer's module testing capabilities will emulate a business component.

Back to top

Create a business logic subscriber

Next, create a subscriber SCA module like the one depicted in Figure 3. In this example, the subscriber emulates business logic that must understand it is a subscriber. The reason for this is that, with the current products, you must choose the binding at development time.

1. In the Business Integration view, select New => Module.
2. In the New Module dialog, enter Subscriber1 and click Finish.
3. For Subscriber1, open the dependency editor and add the PubSubLib as a library.
4. Open the assembly diagram for Subscriber1.
5. Add an export to the module by selecting the export and then going to the Properties view. Click the Description tab and make the Display name Subscribe1.
6. Select Subscribe1, and apply the Orders interface.
7. Right-click Subscribe1, then select Generate Binding => JMS Binding.
8. In the dialog shown in Figure 14, select Publish-Subscribe for JMS messaging domain, Text for the Serialization type, then click OK.
   
   Figure 14. JMS Export Binding
   
   
   
9. In the Properties view, select the Binding tab.
10. In the JMS Export Binding tab, enter jms/TheTAS as the JNDI Lookup Name for the activation specification, as shown in Figure 15:
    
    Figure 15. JMS Export Binding connection factory
    
    
    
11. Select JMS Destinations => Receive Destination Properties.
12. Enter jms/TheTopic as the JNDI Lookup Name for the topic, as shown in Figure 16.
    
    Figure 16. JMS Export Binding Receive Destination Properties
    
    
    
13. Save the module. As with the Publisher import, some fields are grayed-out because the values of fields come from the JMS artifacts looked up via the JNDI names provided.
14. To prove that Subscriber1 gets and can process the information sent by the publisher, add a simple Java component to the module and wire it to the export, as shown in Listing 1:
    
    Listing 1. Send method implementation for Subscriber1 Java component
    

    public void send(DataObject order) { //TODO Needs to be implemented. System.out.println("Got to Subscriber1"); }

    
    
15. Double-click on the Java component to add an implementation. Insert a simple output to the console as shown in Figure 17.
    
    Figure 17. Subscriber1 module assembly diagram
    
    
    
16. Save the module. The Subscriber1 module is now complete. You can now deploy Subscriber1 to the test environment server.

Duplicate the Subscriber1 instructions above for a second subscriber called Subscriber2, then deploy Subscriber2.

Back to top

Test the business solution

With Publisher and Subscriber1 and Subscriber2 modules deployed to the test server, you can now test.

1. Open the publisher assembly diagram, right-click in the diagram and click Test Module.
2. Enter some arbitrary values for the attributes of the Order business object and click Continue.
3. In the dialog, choose the server to which you deployed the modules and click Finish.
4. Click the Console tab. You should see something like Figure 18. The output in the console shows that both subscribers got the message sent by the publisher. In this implementation, the request is placed directly in the topic space by the import, and the request is delivered to both subscribers via the default messaging provider communication infrastructure.
   
   Figure 18. Test configuration and results
   
   
   

Back to top

Create an integration logic publisher

What if you don't want your business logic to understand that it is using a publish/subscribe interaction pattern? Or perhaps more importantly, what if you have an existing piece of business logic you want to be a publisher, even if it is currently implemented with a point-to-point interaction pattern? One solution is to implement the publish/subscribe interaction pattern with WebSphere ESB.

Figure 19 shows what you can do with WebSphere ESB. A publisher mediation mediates a requester that uses a one-way operation using a point-to-point interaction pattern by accepting the request and publishing it to any subscribers using the technique described above. In this case, the binding between the requester and the publisher mediation does not have to be publish/subscribe capable. The binding could be any of the bindings, SCA, Web services, or JMS (via a queue rather than a topic space), that do not support a publish/subscribe interaction pattern.

To create the mediation module in WebSphere Integration Developer (see Getting started with WebSphere Enterprise Service Bus and WebSphere Integration Developer for more information), do the following:

1. In the Business Integration view, select New => Mediation Module.
2. In the New Mediation Module wizard, enter MedPublisher and click Next.
3. On the next page, select PubSubLib and click Finish.
4. Open the assembly diagram for MedPublisher.
5. Add an export to the module by selecting Export, then going to the Properties view.
6. Click the Description tab and make the Display name PubOrders.
7. Select PubOrders, and apply the Orders interface.
8. Right-click PubOrders and select Generate Binding => Web Service Binding.
9. Click Yes, then select soap/http and click OK in the next dialog.
10. Add an import to the module. Follow the instructions for the Publisher import binding to create the publish/subscribe interaction pattern.
11. Wire the export to the mediation flow component (Mediation1) and wire the mediation flow component to the import.
12. Save the module; the module should look like Figure 20:
    
    Figure 20. Mediation module
    
    
    
13. Open the mediation flow editor for Mediation1 and wire the send operation in the export (represented by the Orders interface) to the send operation in the import (represented by the OrdersPartner).
14. In the request flow, wire the send operation in the export (represented by the Request node) to the send operation in the import (represented by the Invoke node), as shown in Figure 21. This creates a pass-through mediation, which essentially does nothing; you can add mediation primitives of various sorts for logging or transformation to the request flow if you need to. Because the operation is one way, there is no response flow in the mediation flow editor. If the export operation was not one way there would be a response flow that would have to produce some fake response, since there is no response from the one-way operation on the import.
    
    Figure 21. Mediation flow
    
    
    

The MedPublisher is now complete. You can deploy the MedPublisher to the test environment server.

You must now perform an extra bit of set-up before creating a business module that represents the existing requester in Figure 19.

1. Open the Physical Resources view.
2. Expand the MedPublisher project and find PubOrders_OrdersHttp_Service.wsdl, which is the WSDL file representing the MedPublisher mediation module.
3. Copy the file and paste it into the PubSubLib project. Placing it in the library makes the full description of MedPublisher, including the endpoint address, available to any project that uses the library.

Now create a business module that represents the requester in Figure 19. Follow the instructions above to create a business module called Requester with an import named Orders. This example assumes the existing requester uses a Web service binding.

1. Right-click Orders and click Generate Binding => Web Services Binding.
2. Select the Orders import, then open the Properties view.
3. Select the Binding tab and click Browse.
4. In the dialog, scroll to PubSubLib, select PubOrders_OrdersHttp_Service.wsdl, and click OK.
5. Save the module. You must create the mediation module before the business module, so that you can actually bind the import to a specific service implementation. If the requester already exists, then it already has a specific binding to an implementation that you must change to point to the mediation module's export.

You can now deploy the requester to the test environment server. If you test the requester module in the same way you tested the original publisher module, you'll see that both Subscriber1 and Subscriber2 get the message sent by the requester. In this case, of course, the requester sends a request to MedPublisher, and MedPublisher in turn places the request on the topic space via the import, and the default messaging provider communication infrastructure delivers the request to both subscribers.

Back to top

A few more thoughts on the publish/subscribe interaction pattern

Examine Figure 19 once again. It suggests two additional areas of discussion:

1. What if, in the point-to-point interaction pattern between the requester and publisher mediation, the requester already uses a publish/subscribe interaction pattern, as shown in Figure 2? No problem. In that case, you can implement the publisher mediation with an export that is a subscriber, just as with the import in the Subscriber1 described above. In essence, the publisher mediation re-publishes the topic to which it subscribes, with the potential for logging and transformation between the the publisher and subscribers.
2. What if the desired subscribers do not or cannot use a publish/subscribe interaction pattern? For example, what if the subscribers are Web services? Figure 22 shows an architectural view:
   
   Figure 22. Publish/subscribe with point-to-point
   
   
   

   In this case the publisher mediation requires an explicit list of subscribers and must actively send the request to each. This interaction pattern is sometimes called recipient list. Neither SCA nor WebSphere ESB currently has any pre-built support for the recipient list interaction pattern. You can construct a set of custom mediation primitives (see Developing custom mediations for WebSphere Enterprise Service Bus) for WebSphere ESB to implement the pattern, but that's beyond the scope of this article.

Back to top

Conclusion

This article discusses some of the capabilities (and limitations) of WebSphere Process Server and WebSphere ESB related to the publish/subscribe interaction pattern. The article shows you how to implement the pattern in various architectural patterns. You should now be able to leverage the publish/subscribe interaction pattern in your service oriented solutions built on the WebSphere product family.

Resources

• developerWorks SOA and Web services zone: Get technical information and resources for IBM SOA and Web services.
  
  
• developerWorks WebSphere Web services zone: Get technical information and resources for WebSphere Web services.
  
  
• Publish/subscribe: A Wikipedia definition.
  
  
• Service Component Architecture: This developerWorks article defines and links to the various SCA specs, Javadoc, and API source files.
  
  
• Java Message Service Specification, Version 1.1: The JMS specification.
  
  
• Deploying publish and subscribe applications into the Service Integration Bus: This developerWorks article describes how to configure WebSphere Application Server V6 to use the Service Integration Bus as its JMS provider for publish/subscribe applications.
  
  
• Getting started with WebSphere Enterprise Service Bus and WebSphere Integration Developer: This developerWorks article introduces you to WebSphere ESB and its accompanying tooling, WebSphere Integration Developer.
  
  
• Developing custom mediations for WebSphere Enterprise Service Bus: This developerWorks article introduces the use of custom mediations using the WebSphere Integration Developer V6 for WebSphere ESB V6.
  
  

About the author

Greg Flurry is a Senior Technical Staff Member in IBM's SOA Advanced Technology group. His responsibilities include working with customers on service-oriented solutions and advancing IBM's service-oriented products. If you have comments for the Greg about this article, send them to wsdd@us.ibm.com.

Comments (Undergoing maintenance)

Back to top

Trademarks  |  My developerWorks terms and conditions

Table of contents

• Introduction
• Set up the publish/subscribe infrastructure
• Create a business logic publisher
• Create a business logic subscriber
• Test the business solution
• Create an integration logic publisher
• A few more thoughts on the publish/subscribe interaction pattern
• Conclusion
• Resources
• About the author
• Comments

Next steps from IBM

• Try: WebSphere Integration Developer (in the SOA Sandbox: Connect)
• Demo: Process automation, adoption pattern
• Webcast: Develop innovative applications efficiently using the right application foundation in today's economy
• Briefing: WebSphere flexible business processes
• Buy: WebSphere Integration Developer (in the SOA Sandbox: Connect)

My developerWorks community

Dig deeper into WebSphere on developerWorks

Rate a product. Write a review.

Write a review for Rational products today!

Special offers