| Author |
Message
|
| joppe |
 Posted: Mon Oct 10, 2011 3:31 am Post subject: Websphere MQ - JMS? |
 |
|
Newbie
Joined: 10 Oct 2011
Posts: 4
Location: Oslo - Norway
|
Hi!
I've just getting started with MQ and I was wondering if you guys could help me getting started. First of all the reason i'm learning MQ is to be able to work with integration between Java and COBOL applications. I have created a small test application with JMS, Glassfish and Java EE (MDM) before, so i'm not completely unfamiliar with queuing.
That said, I have just installed Websphere MQ 7 and I got a little confused. I thought that MQ was a seperate message provider and more or less a rival to JMS and that MQ had interfaces for more languages. Apparently not as when I created a new queue in MQ explorer I get a option to create a corresponding JMS object. So how would communication between Cobol(mainframe) and Java actually work, would you have a JMS queue that the java side talks to, a link between a "JMS queue" and a "MQ queue" and then a MQ-queue that Cobol communicates through?
Thanks in advance.
Joppe |
|
| Back to top |
|
 |
| zpat |
| Posted: Mon Oct 10, 2011 3:53 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
If using MQ for JMS transport, your JMS queue is an MQ queue.
JMS is an API, not a message transport.
To interoperate, make sure you send non-JMS messages from JMS.
q.setTargetClient(JMSC.MQJMS_CLIENT_NONJMS_MQ) ; |
|
| Back to top |
|
|
| joppe |
| Posted: Mon Oct 10, 2011 4:56 am Post subject: |
|
|
Newbie
Joined: 10 Oct 2011
Posts: 4
Location: Oslo - Norway
|
Aha, that clarifies a bit. So you could say Websphere MQ supports different platform API's rather than different languages. I was under the impression that the MQ platform had one common API ported to different platforms. So I would use the JMS-API when communicating through a java application and a different one when communication from C++ or Cobol?
When interoperating and you set your targetClient as you wrote (JMSC.MQJMS_CLIENT_NONJMS_MQ) would you then need a corresponding JMS queue to a ordinary Local MQ-Queue? And how would the communication actually work between those queues? Or do you only need a JMS-QUEUE?
I feel this is just like starting with OOP, when you first get your mindset around it, you find out that it wasn't as complicated as you thought it was.  |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Oct 10, 2011 6:05 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| joppe wrote: |
| So I would use the JMS-API when communicating through a java application and a different one when communication from C++ or Cobol? |
The corresponding wrapper for non-Java is XMS, or you can use the native API directly. They're all the same opperations on the same underlying WMQ object.
| joppe wrote: |
| When interoperating and you set your targetClient as you wrote (JMSC.MQJMS_CLIENT_NONJMS_MQ) would you then need a corresponding JMS queue to a ordinary Local MQ-Queue? And how would the communication actually work between those queues? Or do you only need a JMS-QUEUE? |
The JMS standard specifies properties that must exist in the message for it to meet the standard. If you send a message from JMS to non-JMS, you need to either suppress the properties using the property my most worthy associate quotes, or code your COBOL/C++ to properly interpret the properties. There are good and sufficient reasons why you'd want to read JMS properties in COBOL.
| joppe wrote: |
| I feel this is just like starting with OOP, when you first get your mindset around it, you find out that it wasn't as complicated as you thought it was. |
The basics are straightforward enough. Just remember you have:
- The underlying WMQ which is providing all the transport, message storage and handling
- The message itself, either formatted in accordance with the JMS standard or not depending on design
- The method of formating & manipulating the message through the transport, either using the JMS api, native api or whatever.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Mon Oct 10, 2011 6:10 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| Vitor wrote: |
| joppe wrote: |
| So I would use the JMS-API when communicating through a java application and a different one when communication from C++ or Cobol? |
|
You use the JMS API when you are communicating through a JEE application. If you are simply using JSE, then you use the Java API.
| Vitor wrote: |
| The corresponding wrapper for non-Java is XMS, or you can use the native API directly. They're all the same opperations on the same underlying WMQ object. |
Again, XMS is a correspondant to the JMS API, which is all well and good in other languages. But you can, and should consider, just using the normal MQ API in those languages as well, particularly when communicating with applications that are written in languages that DO NOT have access to the XMS API.... like COBOL. |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Oct 10, 2011 9:18 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| mqjeff wrote: |
| You use the JMS API when you are communicating through a JEE application. If you are simply using JSE, then you use the Java API. |
I should know better than to try Java questions.
| mqjeff wrote: |
| Vitor wrote: |
| The corresponding wrapper for non-Java is XMS, or you can use the native API directly. They're all the same opperations on the same underlying WMQ object. |
Again, XMS is a correspondant to the JMS API, which is all well and good in other languages. But you can, and should consider, just using the normal MQ API in those languages as well, particularly when communicating with applications that are written in languages that DO NOT have access to the XMS API.... like COBOL. |
I was attempting to convey that there is an alternative wrapper, not that it's the only alternative. Hence my mention of the native apis. I didn't mean to convey it's the only alternative, or applicable in all cases.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| joppe |
| Posted: Mon Oct 10, 2011 9:44 am Post subject: |
|
|
Newbie
Joined: 10 Oct 2011
Posts: 4
Location: Oslo - Norway
|
Thanks guys, this is really helpful.
I will try them all, JMS, JSE, XMS and last but not least the normal MQ API. I'm sure I will get stuck a couple of times and run straight back into this forum, but I wont make you do my "homework".
If you have any resources (tutorials etc.) on the different API's please do share.
| Quote: |
| There are good and sufficient reasons why you'd want to read JMS properties in COBOL. |
You got me intrigued. If you only use the normal MQ API would you ever get into this situation? |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Oct 10, 2011 2:10 pm Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| joppe wrote: |
| You got me intrigued. If you only use the normal MQ API would you ever get into this situation? |
If the Java application includes useful information (by which I mean the application putting business information, not the information included as part of the JMS standard), your non-Java application might need to interogate it. Equally, you might not. It all depends on the design and the circumstances, there's not a "right" and "wrong" way to do it.
Apart from sending JMS information to a COBOL application that doesn't expect it, or sending a non-JMS message from COBOL to a Java application that does expect it. 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Mon Oct 10, 2011 10:41 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| joppe wrote: |
| Aha, that clarifies a bit. So you could say Websphere MQ supports different platform API's rather than different languages. I was under the impression that the MQ platform had one common API ported to different platforms. So I would use the JMS-API when communicating through a java application and a different one when communication from C++ or Cobol? |
Not quite. WMQ supports different APIs in different languages. You can use either base Java or JMS. The same way you can use XMS (JMS like for non java languages) or C.
| joppe wrote: |
| When interoperating and you set your targetClient as you wrote (JMSC.MQJMS_CLIENT_NONJMS_MQ) would you then need a corresponding JMS queue to a ordinary Local MQ-Queue? And how would the communication actually work between those queues? Or do you only need a JMS-QUEUE? |
No a queue is a queue is a queue. The JMS construct in the MQExplorer just allows you to create a JNDI definition for a queue. That definition will still need to point back to an existing queue.
| joppe wrote: |
| I feel this is just like starting with OOP, when you first get your mindset around it, you find out that it wasn't as complicated as you thought it was. |
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Mon Oct 10, 2011 10:49 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| mqjeff wrote: |
| You use the JMS API when you are communicating through a JEE application. If you are simply using JSE, then you use the Java API. |
Let's be a little bit more precise here. If you are simply using Java and not running in a J2EE container, you have the choice of whether you want to use Java base programing or a stand alone JMS programing model.
Be aware that the choice may/will have consequences and your mileage will vary. 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
|
|
