| Author |
Message
|
| siqi |
 Posted: Wed Aug 04, 2004 6:02 am Post subject: really a basic question, JMS vs. base Java classes |
 |
|
Newbie
Joined: 04 Aug 2004
Posts: 4
|
I have programed with JMS on SonicMQ. Now I am start working with
MQSeries. I kind of got confused with basic concept.
So please advice me whether the following is correct:
1) MQI is a low level protocol between MQSeries client and queue manager
2) With Java, you can use MQ base java classes to issue
MQI calls and the MQ base java classes are kind of wrapper
on MQI, so you can pass all the option MQQQ_BIND_ON_OPEN
for MQOPEN easily
3) MQ base java is preferred joice if you have applications written
both in Java and C or C++ or .Net
4) JMS maps to the MQI as much as possible, but if you have to use
MQOO_BIND_ON_OPEN option, then you have to use both
MQ base java jar and JMS jar files and use customer JMS header
to carry these options (but where is the document for mapping
in details).
5) JMS is preferred if we have everything programmed in Java.
Really appreciate your reply. |
|
| Back to top |
|
 |
| bower5932 |
| Posted: Wed Aug 04, 2004 6:30 am Post subject: |
|
|
Jedi Knight
Joined: 27 Aug 2001
Posts: 3023
Location: Dallas, TX, USA
|
Some of your questions are philosophical and won't have clear cut answers. I'll give you my spin on them:
1) The MQI is the API that is used so that a program can communicate with a queue manager. It consists of calls to connect to the queue manager, open queues, and put/get messages. There are versions of it in C, COBOL, RPG (and I'm probably leaving others out).
2) The Java classes are built on an object model where you deal with various WMQ objects. It is similar to the MQI. However, I'd describe the MQI as procedural and the Java and C++ interfaces as object-oriented.
3) Any time you say preferred, I'd have to say 'it depends'. I'm not sure that I know enough about what you are doing to say there is a clear-cut answer.
4) I wouldn't say that the JMS maps to the MQI at all. The JMS is an open standard and WMQ has supplied a set of class libraries for it. These classes allow you to use JMS calls and under the covers, work is done against a queue manager. The details on how the JMS provider (ie, WMQ) specific information is given to the JMS can be found in the Using Java manual. There is a section on administration and another on the setting/mapping of fields in the RFH2 header.
5) JMS is preferred - I'd have to say that this depends on what you are doing. |
|
| Back to top |
|
|
| siqi |
| Posted: Wed Aug 04, 2004 6:44 am Post subject: |
|
|
Newbie
Joined: 04 Aug 2004
Posts: 4
|
| bower5932 wrote: |
3) Any time you say preferred, I'd have to say 'it depends'. I'm not sure that I know enough about what you are doing to say there is a clear-cut answer.
|
I think what I want to know is wehther I can do everything with JMS
as I can do with MQ base java and how difficult since
it seems to me that JMS is not as close to MQI as MQ base Java.
Thanks for your reply.
[/quote] |
|
| Back to top |
|
|
| siqi |
| Posted: Wed Aug 04, 2004 7:06 am Post subject: |
|
|
Newbie
Joined: 04 Aug 2004
Posts: 4
|
| siqi wrote: |
| bower5932 wrote: |
3) Any time you say preferred, I'd have to say 'it depends'. I'm not sure that I know enough about what you are doing to say there is a clear-cut answer.
|
I think what I want to know is wehther I can do everything with JMS
as I can do with MQ base java and how difficult since
it seems to me that JMS is not as close to MQI as MQ base Java.
Thanks for your reply.
|
[/quote]
Basically we have applications written in Java, C, C++ and
all the applications have to be connected through MQSeries.
I am only working on Java side and am facing the decision,
should I go with JMS or MQ base Java. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Wed Aug 04, 2004 7:11 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
The only thing your other applications - C, C++, plain Java, COBOL, VB, .NET, etc. - will care about is the CONTENTS of the message.
How you choose to populate those contents is up to you.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| siqi |
| Posted: Wed Aug 04, 2004 7:15 am Post subject: |
|
|
Newbie
Joined: 04 Aug 2004
Posts: 4
|
| jefflowrey wrote: |
The only thing your other applications - C, C++, plain Java, COBOL, VB, .NET, etc. - will care about is the CONTENTS of the message.
How you choose to populate those contents is up to you. |
It is a good point, but if it is really the same, what is the real
reason for MQ base Java anymore? it is not standardized.
It seems to me from this forum that more people write in
MQ java base than in JMS. What is the real reason for not
only write in JMS? |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Wed Aug 04, 2004 7:28 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
| siqi wrote: |
It is a good point, but if it is really the same, what is the real
reason for MQ base Java anymore? it is not standardized.
It seems to me from this forum that more people write in
MQ java base than in JMS. What is the real reason for not
only write in JMS? |
Because JMS is only defined in J2EE, not in J2SE.
Because JMS is MORE generic than the Java MQ API - this means less MQ specific controls and functionality.
Because portability of Java code from MQSeries to another messaging provider is deemed useless in a particular context (why would I write an MQ monitoring tool that was "portable" to Sonic...?)
Because the MQ API is standardized within itself - and rather than having C++ code using one object model and JMS code using a different one, an organization wants them to be the same object model.
But mostly because, it depends.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| bower5932 |
| Posted: Wed Aug 04, 2004 10:00 am Post subject: |
|
|
Jedi Knight
Joined: 27 Aug 2001
Posts: 3023
Location: Dallas, TX, USA
|
| One thing that you can get with the base Java API is some systems administration. Granted, you have to get SupportPac MS0B to get it. The JMS is simply for sending/receiving messages (and mostly in the J2EE environment). If you think you'll want to change properties of some of the objects, you'll end up using MS0B to do it. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Wed Aug 04, 2004 10:03 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| Quote: |
I think what I want to know is wehther I can do everything with JMS
as I can do with MQ base java
|
As of now, not 100% of everything base Jave MQ can do is allowed in JMS. Probably like 99%. But if you need that 1%....
Plus, the JMS to MQ interface is slower than base jave classes to MQ.
From an MQ Admin perspective, I don't like JMS. It is harder to solve problems (but that's my own fault cause I dont know it). And JMS absolutly hammers MQ, even when there are no messages flying thru. Constantly open and closing queue and the queue manager to do inquiries, get with waits that cant be extended, all these connectio pools using up the number of channels I can have at one time, etc.
People from the Java side of the house seem to love it and can't understand why anyone would even consider doing any messageing without JMS.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| tina |
| Posted: Wed Aug 04, 2004 11:26 am Post subject: |
|
|
Newbie
Joined: 03 Aug 2004
Posts: 6
|
| PeterPotkay wrote: |
| Quote: |
I think what I want to know is wehther I can do everything with JMS
as I can do with MQ base java
|
People from the Java side of the house seem to love it and can't understand why anyone would even consider doing any messageing without JMS. |
I think I am one of them:)
The reason is that if I later have to work with another messaging
system, I do not need to learn a new API.
But I got your point. Thanks you guys, |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Wed Aug 04, 2004 2:17 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Hi Peter, Jeff,
Just a little bit additionnal information for all those JMS fans.
If you are carefull you can use JMS as a stand alone java app.
I have done it.
You don't have to use JNDI. Just use the MQ[Queue | Topic]ConnnectionFactory and set your attributes from property files.
Use the Session.createQueue method to access your queues.
However I will have to concurr that when you are looking at administration
JMS is not the preferred way (c seems the way to go there). Not even Java. If my memory serves me right the java admin pak is quite recent.
I have built the tools I needed to do some projects in JMS. I can't quite understand the gripe about number of connections and so on...
Each MDB has a connection to the queue. We expected that. Well now just make sure all resources are correctly released on passivation and bean destruction/finalization and such. This will go a long way in avoiding trouble.
Just my 2cts. |
|
| Back to top |
|
|
| JLRowe |
| Posted: Thu Aug 05, 2004 4:37 am Post subject: |
|
|
Yatiri
Joined: 25 May 2002
Posts: 664
Location: South East London
|
Using the MQ[Queue | Topic]ConnnectionFactory implementations ties you into MQ as the JMS provider.
If you are not running under J2EE, you can use the fscontext JNDI provider to hold your QCF's and Q's in a file, and still decouple your code from the JMS provider. Also, allowing easy re-use of the code on J2EE if the time ever comes. |
|
| Back to top |
|
|
| bower5932 |
| Posted: Thu Aug 05, 2004 6:09 am Post subject: |
|
|
Jedi Knight
Joined: 27 Aug 2001
Posts: 3023
Location: Dallas, TX, USA
|
| I use JMS as a stand-alone application all of the time. However, I never use the MQ specific objects. jlrowe is right about using the fscontext and preparing yourself for J2EE. If you are going to use the MQ specific JMS objects, you might as well go with the base java classes. |
|
| Back to top |
|
|
|
|
