Integrating WebSphere MQ services with WebSphere Service Registry and Repository: Part 1: Understanding WebSphere MQ service metadata

This two-part article series shows you how to use WebSphere Service Registry and Repository (WSRR) to register WebSphere MQ services for SOA reuse, visualization, and impact analysis. Part 1 describes the WebSphere MQ service metadata that is catalogued in WSRR, how WebSphere MQ resources are used to create MQ business objects, and how to manually update the properties in a WebSphere MQ WSDL document for troubleshooting and advanced work. Part 2 will show you how to create a Business Space for populating a graphical view of MQ business objects and their dependent services in order to do impact analysis.

Share:

Fenglian Xu, Software Engineer, IBM

Photo of Fenglian XuDr. Fenglian Xu is a Software Engineer on the WebSphere Service Registry and Repository Development team at the IBM Software Lab in Hursley, United Kingdom. Previously, she worked on the WebSphere Enterprise Service Bus Development team. Her expertise includes IBM middleware product integration in service-oriented architectures, and she is also an IBM developerWorks Contributing Author. She earned a B.S. in Mathematics from Xian Jiaotong University in 1989, and a Ph.D. in Computer Science from the University of Southampton in 1998. You can contact Fenglian at xufengli@uk.ibm.com


developerWorks Contributing author
        level

Mark Phillips (m8philli@uk.ibm.com), Software Developer, IBM

Photo of Mark PhillipsMark Phillips has worked as a software developer with the WebSphere MQ Development Team at the IBM Hursley UK Lab since 1995. He currently works on the WebSphere MQ Technical Strategy Team, with responsibility for Web services, messaging clients, and APIs. You can contact Mark at m8philli@uk.ibm.com.



Peter Cullen (pete.cullen@uk.ibm.com), Test Architect, IBM

Photo of Peter CullenPeter Cullen is a Software Engineer and Test Architect on the WebSphere Service Registry and Repository (WSRR) Team at the IBM Software Development Lab in Hursley, United Kingdom. Prior to working with WSRR, Peter spent seven years working on the WebSphere MQ team, where he specialized in functional testing. You can contact Peter at pete.cullen@uk.ibm.com.



Bernard Z. Kufluk (bernard@uk.ibm.com), Advisory Software Engineer, IBM

Bernard Kufluk photoBernard Kufluk has been working as a Software Developer on the WebSphere Service Registry and Repository Core Development team for six years. During the past 12 years, he has worked on various IBM products including WebSphere Voice Application Access, WebSphere Voice Response, and Intelligent Notification Services. You can contact Bernard at bernard@uk.ibm.com.



05 October 2011

Also available in Chinese

Software requirements

To follow this article, you must have the following IBM software installed on your machine:

  • IBM® WebSphere® MQ Explorer V7.0.1 or later
  • IBM WebSphere Service Registry and Repository V7.5 (hereafter called WSRR)

The WebSphere MQ Parser is enabled by default if you are running the governance enablement profile, but will need to be enabled manually if you are using the basic profile. For more information, see Plug-in configuration for the WebSphere MQ integration feature in the WSRR Information center.

You can download the examples used in this article at the bottom of the article.

Introduction to WebSphere MQ applications

A WebSphere MQ application can be a standalone application (for instance a C, C#, COBOL, or Java™ program), or it can be an application running in a hosted environment like CICS or a JEE application server. No matter how the WebSphere MQ application is implemented, it can be classified as either a service requester or a service provider:

Service requester
Always starts by putting messages to a queue or a topic. The requester may or may not receive a response message from a service provider.
Service provider
May start by either sending or receiving a message. A service provider can also be a service requester of another service provider. Any service provider application can be represented as a WSDL service with the WebSphere MQ Service Definition specification and the WebSphere MQ IRI specification. For more information, see IBM SupportPac: WebSphere MQ Service Definition Specification.

WebSphere MQ WSDL has been extended from the standard Web service WSDL with an additional namespace: xmlns:wmqservice=http://www.ibm.com/xmlns/prod/wmq/bindings/1.0. Anything under the wmqservice namespace belongs to WebSphere MQ applications only, and can be sub-elements of the WSDL elements in Listing 1:

Listing 1. WSDL elements
   <wsdl:binding>...</wsdl:binding>
   <wsdl:operation>
      <wsdl:input>...</wsdl:input>
      <wsdl:output>...</wsdl:output>
   </wsdl:operation>
   <wsdl:fault/>...</wsdl:fault>
   <wsdl:service>
      <wsdl:port>...</wsdl:port>
      <wsdl:port>...</wsdl:port>
   </wsdl:service>

Throughout this article you will find examples of elements with the namespace <wmqservice: >.

The article describes two scenarios in which WebSphere MQ application service providers process messages using different types of message exchange patterns. It will show you how to build, catalog, and visualise WebSphere MQ application services using the WebSphere MQ Explorer Service Definition Wizard, which is available with WebSphere MQ V7.0.1 or WSRR.

Figure 1 shows the first scenario, in which an insurance call center service requester application uses point-to-point message exchanges to perform two operations to the following two services:

CalculatePremium service
An application server service provider uses a request-response message exchange pattern to calculate an insurance premium and return the response to a quote.
UpdatePremium service
An application sever service provider uses a one-way message exchange pattern to update an insurance premium but does not return any response.
Figure 1. A point-to-point scenario logical architecture
A point-to-point scenario logical architecture

This scenario assumes that the following MQ objects are created and used by the WebSphere MQ applications:

  • MQ Queue Manager: INS.PREMIUM.QM
    • MQ Queue Name: CALC.PREMIUM.REQ
    • MQ Queue Name: CALC.PREMIUM.RESP
    • MQ Queue Name: UPDATE.PREMIUM.REQ

Figure 2 below shows the second scenario, in which a stock exchange application uses a pair of one-way message patterns in a publish/subscribe message exchange:

Shareholder service requester application
Registers an interest to the topic Stock/Price/NYSE/IBM by subscribing to it, and receives any messages published to this topic.
PublishStockPrice service provider
Publishes the stock price to the topic, so that shareholders can receive the results.
Figure 2. Publish/subscribe scenario logic architecture
Publish/subscribe scenario logic architecture

This scenario assumes that the following MQ objects are created and used by the WebSphere MQ applications:

  • MQ Queue Manager: StockQM
  • MQ Topic Name: Stock/Price/NYSE/IBM

WebSphere MQ WSDL document

The WebSphere MQ message exchanges described in these scenarios can be described by WSDL documents, which you can create using WebSphere MQ Explorer tool or a text editor. For an example of how to generate a simple WebSphere MQ WSDL document from an existing WebSphere MQ application with the WebSphere MQ Explorer, see Cataloging WebSphere MQ applications with WebSphere Service Registry and Repository. The generated WSDL will not contain any connection information unless it was explicitly provided. This article will show you an example with connection details, so that the WebSphere MQ service requesters can determine how to connect to the WebSphere MQ server. You can use the information provided in this article to edit your own MQ WSDL documents prior to importing them into WSRR.

WebSphere MQ business model in WSRR

Figure 3. WebSphere MQ business model
WebSphere MQ business model

Figure 3 shows the business model used for WebSphere MQ services in WSRR. It mandates that a WSDL service has at least one WSDL port, and that each WSDL port has a request destination and optionally a request connection. The WSDL port may also have a response destination and a response connection. The request destination is either a queue or a topic on a queue manager. A connection defines a route for the client application and specifies how a request message is delivered to a destination.

The WSDL port has a reference to the MQ connection object even though the destination already has a reference to the same object, because MQ business objects are sharable in WSRR. A destination object may be shared by multiple ports if all the ports have the same destination name and qualified queue manager name. However, the same destination may have a connection for one port but not for the others, or it may have different connection objects for each port. Therefore, the link from the WSDL port to each MQ connection must indicate that the MQ connection object on the MQ destination belongs to that port.

Destination

Destination is an abstract class and it has a name property. The destination must be of type MQ Queue or MQ Topic. The destination can also have a qualified queue manager with a name property. The uniqueness of a destination object is determined by the destination name and its associated queue manager name.

Queue

A queue is used by a service provider to send or receive messages. When a WebSphere MQ WSDL file with a request-response message exchange pattern and corresponding queues is loaded into WSRR, both a request queue object and a response queue object are created if they do not already exist. As you can see from the WSDL code in Listing 2, the two queues have different queue names but the same qualified queue manager. Two queue objects are created with the same queue manager:

Listing 2. RequestQuote service
<service name="RequestQuoteService">
  <port binding="tns:RequestQuoteService_Wmq_Binding" name="RequestQuoteService_Wmq_Port">
    <wmqservice:address
      location="wmq://localhost:1414/msg/queue/CALC.PREMIUM.REQ@INS.PREMIUM.QM?
      connectQueueManager=INS.PREMIUM.QM&channelName=premiumChannel"/>
    <wmqservice:replyTo>wmq:/msg/queue/CALC.PREMIUM.RESP@INS.PREMIUM.QM?
      connectQueueManager=INS.PREMIUM.QM&channelTableLib=premiumChannelTableLib&
      channelTableName=premiumChannelTableName</wmqservice:replyTo>
    <wmqservice:connectQueueManager>INS.MOTOR.QM</wmqservice:connectQueueManager>
    <wmqservice:connectionName>premiumConnection</wmqservice:connectionName>
    <wmqservice:channelName>SYSTEM.DEF.SVRCONN</wmqservice:channelName>
    <wmqservice:transportType>MQXPT_TCP</wmqservice:transportType>
  </port>
</service>
Figure 4. A request queue object and response queue object created in WSRR
A request queue object and response queue object created in WSRR

Figure 4 shows the two queue objects, the two connection objects, and the queue manager object that is created in WSRR when this WSDL is imported.

Topic

A topic is a new type supported in WSRR V7.5. A topic object is created when a WebSphere MQ WSDL with a topic is loaded into WSRR. Here is an example of a service port :

Listing 3. PublishStockPrice service
   <service name="PublishStockPrice">
   <port binding="tns:PublishStockPrice_Wmq_Binding" name="PublishStockPrice_Wmq_Port">
      <wmqservice:address location="wmq:/msg/topic/Stock/Price/NYSE/IBM@StockQM"/>
   </port>
   </service>
Figure 5. Topic object created in WSRR
Topic object created in WSRR

Figure 5 shows that the following two objects and a relationship between MQ business objects are created in WSRR:

  • A topic object: Stock/Price/NYSE/IBM
  • A queue manager: StockQM
  • A relationship from the Topic object to the Queue manager object: sm63_queueManager

Both destination and topic are new in WSRR V7.5. Prior to V7.5, a topic in an MQ WSDL was created as a queue. If you want to upgrade the WebSphere MQ instances in your WSRR system from those based on a previous version of the WSRR WebSphere MQ model, you can enable the WebSphere MQ upgrade plug-in to change the queues that actually are topics to topic objects. For more information, see WebSphere MQ upgrade plug-in.

Connection

A connection provides the information for a client to establish a connection to a queue manager, and to resolve the address of the target service. WebSphere MQ provides two types of connections:

Server-binding model
Causes a WebSphere MQ application to connect to a queue manager on the same host as the application.
Client-binding model
Causes a connection over a network to a queue manager that may be running on a remote host.

Figure 3 above shows that a connection has the following properties:

connectQueueManager
Specifies the name of the queue manager to which the requesting service should connect.
channelTableName
Specifies the name of the WebSphere MQ channel table.
channelTableLib
Specifies the location of the WebSphere MQ channel table.

If there is no value specified for both channelTableName and channelTableLib, You can use channelName, connectionName, and transportType to specify the details of a channel connection.

channelName
Specifies a channel to be used when a WebSphere MQ service requester makes a WebSphere MQ client-binding connection.
connectionName
Specifies the connection string to be used when a service requester makes a WebSphere MQ client-binding connection. For TCP/IP, the string is in the form of a host name that can be optionally followed by a colon and the port number: hostname[:port]. When specified in the IRI, the connectionName is the portion of the IRI between wmq:// and /msg/destination.
transportType
Specifies the transport type to be used when a WebSphere MQ service requester makes a WebSphere MQ client-binding connection. The default type is TCP/IP, and the other valid value is LU 6.2.

Each port can have at most two connection objects for the request and response destination respectively. The response connection properties are specified in the replyToIRI element in the WSDL. The request connection properties may be presented in multiple places in a WebSphere MQ WSDL file. The WebSphere MQ WSDL specification, with which WSRR complies, specifies the precedence of the connection properties, and the details are explained below. Table 1 lists possible scenarios for the connection properties in a WebSphere MQ WSDL file, and what connection objects are created in WSRR:

Table 1. Connection properties in a WebSphere MQ WSDL file
PortLocation IRIreplyTo propertyConnection objects created in WSRR
Connection propertiesYYY
  • A request connection object
  • A response connection object
YY
  • A request connection object
  • A response connection object
Y
  • A request connection object
Y
  • A request connection object
  • No connection object

Precedence of the connection properties for the request connection

You can specify the request connection properties in both port and location IRI, as shown in the first row of Table 1. The property value from the location IRI takes precedence over the others according to the MQ Service Definition specification. The complex scenario is that some connection properties are provided in the port, and some of the others are specified in the IRI location. In that case, a connection object is created by taking a combination of the properties and applying the precedence rules. The location parameter from the IRI takes precedence if the same property is provided in multiple places in the same WSDL file. Listing 4 is an example of a WebSphere MQ WSDL port snippet with request connection properties:

Listing 4. Snippet of a service with multiple MQ connection properties
<service name="RequestQuoteService">
   <port binding="tns:RequestQuoteService_Wmq_Binding"
      name="RequestQuoteService_Wmq_Port">
      <wmqservice:address 
      location="wmq://localhost:1414/msg/queue/CALC.PREMIUM.REQ@INS.PREMIUM.QM?
      connectQueueManager=INS.PREMIUM.QM&channelName=premiumChannel"/>
      <wmqservice:replyTo>wmq:/msg/queue/CALC.PREMIUM.RESP@INS.PREMIUM.QM?
      connectQueueManager=INS.PREMIUM.QM&channelTableLib=premiumChannelTableLib&
      channelTableName=premiumChannelTableName:</wmqservice:replyTo>
      <wmqservice:connectQueueManager>INS.MOTOR.QM</wmqservice:connectQueueManager>
      <wmqservice:connectionName>premiumConnection</wmqservice:connectionName>
      <wmqservice:channelName>SYSTEM.DEF.SVRCONN</wmqservice:channelName>
      <wmqservice:transportType>MQXPT_TCP</wmqservice:transportType>
   </port>
</service>

All the request connection properties in this example are listed in Table 2:

Table 2. Multiple occurrences of the same connection property
Connection property nameLocation IRIPortValues used for connection
connectQueueManagerINS.PREMIUM.QMINS.MOTOR.QMINS.PREMIUM.QM
channelNamepremiumChannelSYSTEM.DEF.SVRCONNpremiumChannel
connectionNamelocalhost:1414premiumConnectionlocalhost:1414
transportTypeMQXPT_TCPMQXPT_TCP

Figure 6 shows that the request connection property values match the expected values in the last column of Table 2:

Figure 6. The request connection object and the response connection object properties
The request connection object and the response connection object properties

The uniqueness of a connection object is decided by all the connection properties shown in Figure 1. For two connection objects to equate to the same and thus be correlated to the same object in WSRR, the connection properties must have the same values, which enables better management and reuse in WSRR.

Conclusion

This article provided a detailed explanation of the WebSphere MQ business models in WSRR. A good understanding on how the business models properties are automatically generated from the WSDL file is important for troubleshooting and advanced techniques. Part 2 of this article series will explore the graphical view of WebSphere MQ models.

Acknowledgements

The authors would like to thank Gary Chapman, Ian Heritage, Laura Olson, and Jerry L. Stevens of IBM for their technical reviews and their advice on the contents of this article.


Download

DescriptionNameSize
Code sampleMQServices.zip3 KB

Resources

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

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

 


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

All information submitted is secure.

Choose your display name



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

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

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

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

 


All information submitted is secure.

Dig deeper into WebSphere on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=WebSphere
ArticleID=763864
ArticleTitle=Integrating WebSphere MQ services with WebSphere Service Registry and Repository: Part 1: Understanding WebSphere MQ service metadata
publish-date=10052011