| Author |
Message
|
| tapak |
 Posted: Fri Aug 04, 2006 10:40 am Post subject: Java Vs JMS |
 |
|
Centurion
Joined: 26 Oct 2005
Posts: 149
Location: Hartford,CT
|
Any thoughts on deciding between MQ Java API and JMS for a J2EE or Java application connecting to MQ.
Here is the info I know
I see performance is faster for MQ Java API compared to JMS as per one of the support pacs .
The advantage for JMS is to separate the MQ Environment variables in a secured environment like ldap server and JMS application will do a lookup based on the MQ Variables .
If using Websphere as an application server , I guess it is easy to maintain connection pools . But what about using a non IBM application server like Weblogic ?
Appreciate very much your inputs . |
|
| Back to top |
|
 |
| fjb_saper |
| Posted: Fri Aug 04, 2006 1:41 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
you're in luck. Weblogic is supported.
Use JMS it is better suited to a J2EE environment and will allow you a multiphase commit working with the Webserver's J2EE transaction coordinator.
Enjoy 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Fri Aug 04, 2006 3:26 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Use JMS when you are in a J2EE environment.
Evaluate carefully your requirements when NOT in a J2EE environment, and evaluate the two APIs against those requirements.
JMS is heavy-weight.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| tapak |
| Posted: Mon Aug 07, 2006 5:52 am Post subject: |
|
|
Centurion
Joined: 26 Oct 2005
Posts: 149
Location: Hartford,CT
|
fjb_saper /Jeff
Thanks for the response .
Does that mean ,Weblogic transaction coordinator take care of 2 phase commit ,even if a mq series client connection is used . ?
Also , is JMS better if used in an EJB or any J2EE application like servlet/jsp application.
I thought it was possible to use two phase commit on MQ API also through a JDBC 2.0 API.
Is there documentation detailing the advantages of JMS over MQ API for J2EE application .
Appreciate very much your time . |
|
| Back to top |
|
|
| vennela |
| Posted: Mon Aug 07, 2006 7:11 am Post subject: |
|
|
Jedi Knight
Joined: 11 Aug 2002
Posts: 4055
Location: Hyderabad, India
|
| tapak wrote: |
Does that mean ,Weblogic transaction coordinator take care of 2 phase commit ,even if a mq series client connection is used . ? |
Not if you don't have Extended Transactional Client |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Mon Aug 07, 2006 7:14 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Again, if you are building a J2EE application - like a servlet/jsp or EJB - then you should use JMS. It is a J2EE standard, after all.
The only case where, when you are running code inside a J2EE container (application server), that you shouldn't use JMS is where JMS can't do what you need it to.
One of the big advantages of running code in a J2EE container is that the container will handle coordinating transactions for you.
However, you can't use the XAQueueConnectionFactory with an MQ client install. You still need either the MQ server or the Extended Transactional Client.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| tapak |
| Posted: Mon Aug 07, 2006 8:30 am Post subject: |
|
|
Centurion
Joined: 26 Oct 2005
Posts: 149
Location: Hartford,CT
|
Thank you Jeff ,for making it clear.
I was under the impression , MQ API can be used in a J2EE container managed transaction. So thought that I should go for MQ API as , the performance of MQAPI is better than that of JMS . |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Mon Aug 07, 2006 9:59 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Performance of MQ API is better than JMS performance.
But if your design requirements say "build a J2EE application"... then use JMS.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| tapak |
| Posted: Mon Aug 07, 2006 11:25 am Post subject: |
|
|
Centurion
Joined: 26 Oct 2005
Posts: 149
Location: Hartford,CT
|
I am not still comfortable with your answer that I should go for JMS , for any J2EE application as it is the standard .
I understand that JMS is the standard for J2EE based applications . But it doesnt mean JMS should be used when better performance can be achieved on using MQAPI (And my application priority is performance ).
Does using a JMS in J2EE environment give better performance compared to MQ API in J2EE application .
Also if there is no 2 phase transactions involved , is there a significant advantage of using JMS in a transaction container environment compared to MQ API . |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Mon Aug 07, 2006 11:41 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Most J2EE architects don't like mixing in non-standard (at least, non J2EE standard) technologies into a J2EE standard application, because it can cause "vendor lock-in".
If your J2EE architects don't mind, then go ahead and use the MQ API.
JMS does not perform better than the WebSphere MQ Java API in any environment.
Outside of a J2EE container and the added services it provides, the only advantage JMS has over the MQ API is that the code is "more portable", in that it can run against any JMS provider. Some people believe that it is also a simpler API.
Inside of a J2EE container, the MQ API is unable to take advantage of any of the services that the container provides - like JNDI lookup of resource information, connection pooling, authentication abstraction, and etc.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| tapak |
| Posted: Mon Aug 07, 2006 12:00 pm Post subject: |
|
|
Centurion
Joined: 26 Oct 2005
Posts: 149
Location: Hartford,CT
|
| Thank you for the clarifications . |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Mon Aug 07, 2006 2:01 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
If your JMS application is well designed the performance difference is barely noticeable, I haven't had a case yet where we could not scale and needed the last ms squeezed out.
You will have to be carefull when using selectors to only use the selectors that allow you a native mode: 'ID:xxxxx' i.e. JMSMessageId, JMSCorrelationId...
Enjoy
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| tapak |
| Posted: Tue Aug 08, 2006 6:29 am Post subject: |
|
|
Centurion
Joined: 26 Oct 2005
Posts: 149
Location: Hartford,CT
|
fjb_saper ,
Thank you for the info. Anyway I am planning to do a performance comparison on my application and see if a major difference is there .
Thanks , Deepak |
|
| Back to top |
|
|
| tapak |
| Posted: Tue Aug 08, 2006 6:53 am Post subject: |
|
|
Centurion
Joined: 26 Oct 2005
Posts: 149
Location: Hartford,CT
|
One more doubt on JMS portability . Usage of JMS avoid vendor lock in , only if we use the Generic JMS Provider . But if we are using , Websphere MQ JMS Provider , will there be a vendor lock in again .
Another question based on the above thoughts .
To avoid vendor -lock in ,can we use the Generic JMS Provider to connect to MQ . What are the functionalities not available with Generic JMS Provider when compared to Websphere MQ JMS Provider . ? |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Tue Aug 08, 2006 7:00 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
As long as your code uses JNDI to look up resources, your code knows nothing about which JMS provider is being used. Ergo, your code has no vendor-lock in. Your J2EE container might, but again your code should have no container-lock in either, nothing that would keep it from being run in any J2EE container using whatever JMS Provider the container was configured to use.
Realistically, I don't know of anyone who has changed either their JMS provider or their J2EE container provider without running lots of regression testing on their code and expending a lot of effort on the migration. The code itself may not have needed any fixing, but it still requires a lot of effort to verify that sufficiently to be production-ready.
You can't, and don't want to, use the Generic JMS Provider in WebSphere App Server to connect to WebSphere MQ.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
|
|
