Author |
Message
|
Michael Dag |
Posted: Sat Dec 01, 2007 1:09 am Post subject: MA93 - WebSphere MQ Service Definition - Discussion/Comments |
|
|
 Jedi Knight
Joined: 13 Jun 2002 Posts: 2607 Location: The Netherlands (Amsterdam)
|
|
Back to top |
|
 |
Michael Dag |
Posted: Sat Dec 01, 2007 3:48 am Post subject: |
|
|
 Jedi Knight
Joined: 13 Jun 2002 Posts: 2607 Location: The Netherlands (Amsterdam)
|
Congratulations on this piece of work!
Trying to wrap my mind around the concepts, I have some questions:
- don't the wmq IRI's have 'names' ? or am I missing something?
is the IRI only a way of addressing a wmq object?
for example MYQUEUE on MYQMGR would become:
wmq:/msg/queue/MYQUEUE@MYQMGR
but still only contains all MQ 'related' information. since I have no experience with a repository like WSRR how would you store this in a repository (or is that not the purpose?) ?
I can understand the purpose if you had something 'named' like:
wmq:/name='MYDEST1'/msg/queue/MYQUEUE@MYQMGR
or EndPoint('MYDEST1')=wmq:/msg/queue/MYQUEUE@MYQMGR
and from an 'application' point of view were able to 'reference' MYDEST1 as the selected destination,
for example in a WMB MessageFlow and WMB would lookup the value of MYDEST1 in the repository.
IMHO the value of this would be I no longer need to change Queue Properties in BAR files at deployment time...
(sure you can also use Alias Queues and change the TARGQ of an Alias Definition in different environments...)
Did I miss something with regards to 'naming' these IRI's ? _________________ Michael
MQSystems Facebook page |
|
Back to top |
|
 |
Mark Phillips |
Posted: Sun Dec 02, 2007 4:26 am Post subject: |
|
|
Newbie
Joined: 30 Nov 2006 Posts: 2
|
Thanks Michael, Good question
In its simplest form the IRI is (as you say) just a way of addressing a WMQ object. However an IRI can be also augmented with the properties described in MA93's Service Definition spec to allow it to become a more complete stand-alone service description.
For example, Section 2.10.2 of the Binding Spec. (p34) shows an IRI (see below) describing a request-response application which processes an insurance quote request and places a response on a reply queue.
Code: |
wmq:/msg/queue/INS.QUOTE.REQUEST?connectQueueManager=MOTOR.INS
&replyTo=msg/queue/INS.QUOTE.REPLY
&format=MQSTR
&persistence=MQPER_NOT_PERSISTENT
&reportOptions=MQRO_PASS_MSG_ID |
This IRI does not have a name associated with it so if you were developing your own catalogue or tools based on IRI's you would need some kind of framework to add a name and some descriptive text. How you do that is outside the scope of the IRI specification, but it would be reasonable to store the IRI in some sort of database with supplemental information.
Service repositories like WSRR usually deal specifically with WSDL rather than stand-alone IRI's. The benefit of WSDL is that it provides a standard way to name a service and the operation(s) associated with it and also allows the message formats to be described in detail. Example 3.3.5 on page 45 of the Binding spec. shows the WSDL equivalent to the IRI in section 2.10.2. The request and reply IRIs are stored in the WSDL port element, and the other properties have been moved to more appropriate parts of the WSDL.
You are correct when you say that one of the ways you could use the service definition is in place of changing queue properties in a BAR file and then redeploying a flow. One of the most common use cases I've come across is to use the service definition in a Message Broker for dynamic routing (using the WSRR lookup node in a message flow to retrieve a service definition and then route messages accordingly). In October we announced that WSRR v6.1 would have better support for WMQ, and this will come via support for the Service Definition.
Incidentally, I'd recommend that people who are interested, but who are new to this stuff, should skim read the IRI spec and the bulk of the Service Definition spec. and look in more detail at the IRI examples and messages in 2.10 - comparing them with the WSDL examples in 3.3. Those examples should help to put the specifications in context.
Hope that helps
Cheers
Mark. |
|
Back to top |
|
 |
ashoon |
Posted: Thu Oct 02, 2008 7:55 am Post subject: datapower support? |
|
|
Master
Joined: 26 Oct 2004 Posts: 235
|
wondering if the WS-Proxy within DataPower supports this URL endpoint? _________________ IBM Certified - SOA Solution Designer & WebSphere Datapower SOA Appliances |
|
Back to top |
|
 |
fjb_saper |
Posted: Thu Oct 02, 2008 8:20 pm Post subject: |
|
|
 Grand High Poobah
Joined: 18 Nov 2003 Posts: 20756 Location: LI,NY
|
We hear a lot about SOA and the new way to specify the service endpoints.
However I have yet to see a way to reference JNDI information on an appserver that would really give you speed and connection pooling.
You cannot want to incur the connection overhead for each call...
Is there a way to be able with SOAP to tap into the power of the JNDI repository and the connection pool to enjoy the speed advantage from the J2EE environment??  _________________ MQ & Broker admin |
|
Back to top |
|
 |
muralihegde |
Posted: Wed Oct 15, 2008 3:18 am Post subject: |
|
|
Centurion
Joined: 30 Apr 2002 Posts: 108
|
Hi,
Is this specification supported by WESB? We have a requirement currently where to use pure SOAP-MQ messages (not soap-JMS). This specs appear to do the same, but does WESB support this implementation?
In a red paper,
http://www.redbooks.ibm.com/abstracts/redp4350.html
I could see a sample implementation using WMB.
But is it possible to achive the same in WESB?
Thanks,
-Murali |
|
Back to top |
|
 |
mborowicki |
Posted: Mon Jul 27, 2009 5:57 am Post subject: |
|
|
Newbie
Joined: 13 May 2009 Posts: 7
|
Is there any tool that understands such WSDL ?
Can I generate proxy classes or at least validate that WSDL with MQ binding is correct? |
|
Back to top |
|
 |
fjb_saper |
Posted: Mon Jul 27, 2009 9:24 pm Post subject: |
|
|
 Grand High Poobah
Joined: 18 Nov 2003 Posts: 20756 Location: LI,NY
|
mborowicki wrote: |
Is there any tool that understands such WSDL ?
Can I generate proxy classes or at least validate that WSDL with MQ binding is correct? |
My guess is that any tool should be capable of doing this... However you will at least need the provider jars and the relevant soap jars (from the provider) on your classpath...
Have fun  _________________ MQ & Broker admin |
|
Back to top |
|
 |
mborowicki |
Posted: Tue Jul 28, 2009 2:06 am Post subject: |
|
|
Newbie
Joined: 13 May 2009 Posts: 7
|
In this case I am the provider of the service.
In case of SOAP/HTTP services the procedure is simple:
- I prepare WSDL file with SOAP/HTTP binding
- consumer of the service can use many tools to invoke the service (eg. wsdl2java from axis, wsdl.exe from .NET, SoapUI for testing)
Some of the services we provide have MQ interface (ie. we expose input and output queues and XSD definition of request/response message). I like the idea to use WSDL file to describe these services in the same way as HTTP/SOAP services.
I have already created WSDL files for some of our MQ services.
I am wondering is ther any tool that understands such WSDL files.
For example, SoapUI does not see any operation in WSDL with MQ binding. |
|
Back to top |
|
 |
|