| Author |
Message
|
| PeterPotkay |
 Posted: Thu May 16, 2002 9:05 am Post subject: Should I use JAVA or JMS? |
 |
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
We are trying to come up with an official method for our Java applications to interface with MQ. Right now we have lots of applications, all of which coded their own interface.
For IMS, CICS, Batch COBOL and VB, we created a corporate MQ wrapper. If any application needs to use MQ in these languages, they call our wrapper and away they go. It works great, their development time is reduced, we have control over what options they use on their calls, etc.
On to JAVA. We were considering a JAVA wrapper. Some of the business folks are saying no,no,no. Just use JMS, everyone uses JMS. And other people are saying forget JMS, forget the wrapper, but put forth a standard for regular JAVA apps to follow.
So what are your thoughts? Is there anything major JMS can't do? Will a JAVA wrapper have to be anymore restrictive than our VB wrapper is? (Keeping in mind I understand that anytime you wrap anything, you lose some functionality) I tend to see more JMS questions than pure JAVA questions. I look at that 2 ways: 1. lots more people are using JMS, so there are more people asking questions. Or 2. JMS is a problem, hence all the questions.
If you had a choice to lead a company in a direction, would it be JMS or pure JAVA? (Assume MQSeries will always be the messaging system)
P.S. Can JMS support the IIH header for Bridge queues to IMS?
_________________
Peter Potkay
Keep Calm and MQ On
Last edited by PeterPotkay on Fri May 17, 2002 10:20 am; edited 1 time in total |
|
| Back to top |
|
 |
| mrlinux |
| Posted: Thu May 16, 2002 9:27 am Post subject: |
|
|
Grand Master
Joined: 14 Feb 2002
Posts: 1261
Location: Detroit,MI USA
|
Well I have worked for other places that have put a wrapper around MQSeries and it worked well. Where Iam currently working we tend
to have everthing in XML with the exception stuff to the mainframe which all the non mainframe apps requesting info from the mainframe send there request in XML to our MQSI Message Broker which converts from
XML/COBOL and COBOL/XML for replies. We also have some web apps
with WebSphere and we are using JMS, I havent made up my mind how I feel about JMS, mostly because we have chosen not to use any MQ specific
JMS features and this really hampers things especially in the MQMD access.
_________________
Jeff
IBM Certified Developer MQSeries
IBM Certified Specialist MQSeries
IBM Certified Solutions Expert MQSeries |
|
| Back to top |
|
|
| sjackson |
| Posted: Thu May 16, 2002 9:56 am Post subject: |
|
|
Apprentice
Joined: 28 Jun 2001
Posts: 26
Location: Milwaukee
|
Our development group evalated both last year and went with the base MQ Java classes. It gave them more control than JMS, and they found JMS performance to be rather slow, by comparison.
I saved this comparison from last year -
--------
MQSeries classes for Java:
- Provides Java language support for MQSeries applications
- implements an object oriented model for accessing MQSeries resources
- Supports various connection (transport) options:
- client connection (TCP/IP, CORBA/IIOP)
- bindings connection (JNI)
- Gives parity with support for C/C++, COBOL
- traditional MQSeries object model approach
- greater flexibility, more control
- relatively straight forward to use
- requires an understanding of the MQ API (MQI)
MQSeries Classes for JMS:
- MQSeries implementation of a Java standard
- simpler programming model, introduces a higher level of
abstraction
- application programmer may not need MQ specific skills.
- Utilizes the MQSeries classes for Java to access MQSeries resources.
- abstraction layer has associated performance overhead
- reduced control and flexibility (from a traditional perspective)
- Provides extra function over the MQSeries classes for Java:
- Asynchronous message delivery (onMessage method)
- Message Selectors
- Structured message classes
- Transactional Support
- Provides an administration tool for defining administration objects
and storing them in an enterprise directory service (JNDI namespace)
--------
HTH.
Scott |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Thu May 16, 2002 10:22 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
I was able to pull this from your message Scott, and would be grateful if anyone else can provide these types of pluses and minuses
JMS cons
1.) performance - message throughput suffers
2.) flexability - ability to utilize 100% of MQ Functions not there
JAVA cons
1.) more comlex interface (although if within a wrapper not an issue)
How do Message Driven beans play into this?
(Realize you are talking to a mainframe guy here! I started taking JAVA classes at night this week and just learned what a JVM and JDK are  , so my level set is pretty low) Everything I learned about JAVA so far has been from the MA88 support docs.
I'm having a tough time making a recomendation of Java or JMS when I haven't yet used either. Reading docs is tough since I don't understand some of the stuff they refer to yet. I learn better by doing than reading, which is what I plan to do once I get rolling with these classes. Basically I need opinions from people who actually deal with this stuff every day.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| leot |
| Posted: Thu May 16, 2002 10:57 am Post subject: |
|
|
Novice
Joined: 21 Apr 2002
Posts: 24
Location: NYC
|
I've used JMS in the past (as implemented by WebLogic), and am using plain Java MQSeries API currently (for about 6+ months), but not IBM's JMS implementation.
My recommendation would be based on several considerations:
- IBM did a reasonably good job at wrapping their very non-OO underlying API into Java API, but inebitably, there are some things that are impossible to bridge;
- JMS, as some previous folks correctly noted, is yet another level of abstraction, so something again will be lost during conversion from pure Java to JMS API. Totally agree on performance overhead, too;
- pure Java interface has its problems, I'm sure, and you do not want to deal with yet another layer (JMS) riding on top of it.
Bottom line: if yours is a shop with relatively little Java, and lots of mainframe/COBOL/MQ experience - go with pure Java API. Don't worry about the fact that "with JMS switching to another implementation would be easier" - consider how likely abandoning MQSeries is in your particular situation. JMS may represent too much of a paradigm shift, and it may take some time for your developers to take it. When they do, it will be more natural migration to a new standard (JMS), if it proves necessary.
- Leonid |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Thu May 16, 2002 11:07 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
We are doing more and more JAVA everyday, hence the importance of this question to us. I (maybe incorrectly) consider the biggest (omly?) selling point for JMS to be it's ability to switch from one messaging system to another with minimal application changes, and if you never plan to switch, is there any reason to go to JMS?
The people pushing us to use JMS say, "Why wouldn't you use JMS?" I say,
"Why would we?"
How do Message driven beans play into this? That's something the pro JMS
people bring up.
Funny you should say that about the developers and ease of use. Pro JMS guys are saying that would be a plus, that if we were a JMS shop, it would be easier to hire coders, since more know JMS? What do I know, I gotta take their arguements as gospel since I don't know any better. Sure appreciate your input guys.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| amurugan |
| Posted: Thu May 16, 2002 4:58 pm Post subject: |
|
|
Voyager
Joined: 10 Sep 2001
Posts: 75
Location: india
|
hi peter ,
whetehr to use mqseries base java or mqs eries jms depends upon your soluton . Are you using any application server . Are you using J2EE applications. if so then i thnk you can use jms as its getting to be the defacto standard among all the major MOMS and even in application servers using J2EE architecture . but then if your applications are going to be vanilla java solutions then i think you can use mqseries base java . if you feel that you are not going to shift to any other MOM other than mqseries for a longtime in future then in think you can use mq series base java but if you have application servers and other MOMS in your environment then i think its better to go ahead wioth jms as even system integration products are using JMS and even connectors are starting to use jms for passive integration . So let me know whether does this helps you
In mqseries v trust ,
Murugan |
|
| Back to top |
|
|
| varmamvn |
| Posted: Thu May 16, 2002 5:49 pm Post subject: |
|
|
Novice
Joined: 16 Mar 2002
Posts: 21
|
Hi Peter,
JMS is definately a very attractive solution, since once you map the Queues and QMs into JNDI, you can always access it from anywhere. This is a major plus over Base Java, where it would work only if it exists on the same server as MQ.
Also, MDB's are the best way to have application level listeners inside an application server. MQ series would trigger the MDB's onMessage() when it finds a message, instead of Base Java processes waiting on a particular Queue.
But all said and done, if you encounter strange problems in JMS, then it is even more difficult to resolve. I'm saying this because, I faced a problem wherein when I use JMS, the correlation ID sent by the remote application is getting lost. I tried to get some help for all kinds of sources, but none was able to 
Thanks
Varma |
|
| Back to top |
|
|
| amurugan |
| Posted: Thu May 16, 2002 6:02 pm Post subject: |
|
|
Voyager
Joined: 10 Sep 2001
Posts: 75
Location: india
|
hi varma ,
YOu were mentioning that you were loosing the correlation id . is your sending applications using mq base APIS or mq series jms apis . did u tried to get the corelation id using JMSMessage.getIStringProperty(JMSMessage.JMSCorrelationID). Let me know whether does this solve your problem .
Regards,
Murugan |
|
| Back to top |
|
|
| amurugan |
| Posted: Thu May 16, 2002 6:02 pm Post subject: |
|
|
Voyager
Joined: 10 Sep 2001
Posts: 75
Location: india
|
hi varma ,
YOu were mentioning that you were loosing the correlation id . is your sending applications using mq base APIS or mq series jms apis . did u tried to get the corelation id using JMSMessage.getIStringProperty(JMSMessage.JMSCorrelationID). Let me know whether does this solve your problem .
Regards,
Murugan |
|
| Back to top |
|
|
| amurugan |
| Posted: Thu May 16, 2002 6:39 pm Post subject: |
|
|
Voyager
Joined: 10 Sep 2001
Posts: 75
Location: india
|
hi varma ,
In my previou smail i had said that to use the jms headers using getXXX property and setXXXproperty . I am sorry . you can access and mutate the correlation id using JMSMessage.getCorrelationID() and setCorrelationID(). hope you got it working
cheers,
Murugan |
|
| Back to top |
|
|
| amurugan |
| Posted: Thu May 16, 2002 6:40 pm Post subject: |
|
|
Voyager
Joined: 10 Sep 2001
Posts: 75
Location: india
|
hi varma ,
In my previou smail i had said that to use the jms headers using getXXX property and setXXXproperty . I am sorry . you can access and mutate the correlation id using JMSMessage.getCorrelationID() and setCorrelationID(). hope you got it working
cheers,
Murugan |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Fri May 17, 2002 5:55 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
Murugan,
Our set up is Java apps running on servers without MQSeries installed locally. These apps client connect to our MQ Concentrator boxes. Developrs on their PCs also client connect to these Concentrators.
I would say that we are 99.99999% certain that we would never switch from MQ as our messaging platform.
Other than ease of switching to another messaging system in the future
( a nonfactor for us ) or ease of interfacing with JMS (assuming you know
JMS, which seems like a lot of people do), I am still searching for the
thing that screams "Use JMS! Because JMS affords you X, and regular JAVA MQ doesn't!" Or do the above two features pretty much sum up all of JMS's pluses?
What about this J2EE thing? I must admit I don't know what implications J2EE has, (or even what it is yet! I am just starting to study JAVA now. Please bear with me guys.) How does J2EE apply to JMS vs. JAVA? Does one support it and the other not?
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Fri May 17, 2002 5:58 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| Quote: |
| Also, MDB's are the best way to have application level listeners inside an application server. MQ series would trigger the MDB's onMessage() when it finds a message, instead of Base Java processes waiting on a particular Queue. |
Varma,
What is the benifit of triggering the MDB versus just triggering the Base JAVA process? Are both methods supported in both base JAVA and JMS?
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| varmamvn |
| Posted: Sat May 18, 2002 4:18 am Post subject: |
|
|
Novice
Joined: 16 Mar 2002
Posts: 21
|
Peter,
MDB's run under the application server's control and thus have many fancy features like pooling, transaction support, etc.... Whereas, in Base Java processes we need to struggle to implement all these features. Also, MDB's integrate very well with the other J2EE architecture bits. It has become a norm in the J2EE world to use MDB's whenever we need perform asynchronous processing.
JMS is part of the J2EE architecture. Please dont get confused between the two. J2EE has other specifications like EJB, JSP, Java Mail, JNDI, etc... Collectively, all these specifcations are referred to as J2EE.
_________________
Regards
Varma
varmamvn@mailcity.com |
|
| Back to top |
|
|
|
|
