| Author |
Message
|
| gosanjeev |
 Posted: Wed Oct 06, 2004 9:20 am Post subject: Any advantages of using MQ Java rather than MQ JMS? |
 |
|
Newbie
Joined: 06 Oct 2004
Posts: 3
|
I would like to find out if using MQ Java can provide any benefits with respect to performance or portability over MQ JMS.
Thanks,
Sanjeev Chakravarty |
|
| Back to top |
|
 |
| MQGuy2000 |
| Posted: Wed Oct 06, 2004 10:22 am Post subject: |
|
|
Centurion
Joined: 20 Jul 2003
Posts: 131
|
- JMS provides Loose coupling between the APplication tier and messaging tier.
- relatively easy for Java programmers as the API is similar to JDBC...
~M |
|
| Back to top |
|
|
| gosanjeev |
| Posted: Wed Oct 06, 2004 10:39 am Post subject: What about connection pooling advantage in MQ Java? |
|
|
Newbie
Joined: 06 Oct 2004
Posts: 3
|
| The Websphere MQ for Java provides additional support for creating connection pools. Isn't that a feature missing in MQ JMS? |
|
| Back to top |
|
|
| bower5932 |
| Posted: Wed Oct 06, 2004 10:54 am Post subject: |
|
|
Jedi Knight
Joined: 27 Aug 2001
Posts: 3023
Location: Dallas, TX, USA
|
The MQ Java provides a programmatic interface for administration (ie, PCFs via SupportPac MS0B). The MQ Java also performs better than the JMS.
However, the JMS is a standard and this tends to be the biggest reason that people I work with choose it. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Wed Oct 06, 2004 11:17 am Post subject: Re: What about connection pooling advantage in MQ Java? |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
| gosanjeev wrote: |
| The Websphere MQ for Java provides additional support for creating connection pools. Isn't that a feature missing in MQ JMS? |
It's missing in JMS to the extent that there's no way to code a connection pool yourself. JMS assumes that the JMS Provider will provide connection pools, and handle that for you.
This is one reason why JMS is slower.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| MQGuy2000 |
| Posted: Wed Oct 06, 2004 12:21 pm Post subject: |
|
|
Centurion
Joined: 20 Jul 2003
Posts: 131
|
Agreed.
But I see loose coupling as the biggest advantage.
If for some reason there is change in the messaging middleware from MQSeries to other like Tibco...
There will be minimal code change (should be nothing if coded properly). You need to alter the JNDI references to point to the new middleware.
By using MQ for Java, we need to change a lot of code. |
|
| Back to top |
|
|
| gosanjeev |
| Posted: Wed Oct 06, 2004 12:43 pm Post subject: |
|
|
Newbie
Joined: 06 Oct 2004
Posts: 3
|
| We should look at both the issues:loose coupling and performance hit. If MQ is deployed extensively and a huge investment being already made then it might be a safe bet to adopt a tight coupling solution in order to gain better performance. JMS is an easy interface to write connectivity code and development effort may not be that extensive if a change is required at a later time. Again, the trade-off is performance if loose coupling is chosen and vice-versa. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Wed Oct 06, 2004 2:50 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
I will not dispute the fact that JMS is somewhat slower than MQ base java. So what ? What applications are you working that really requires you to write MQ base java ?
Have you done benchmark and stress testing and can you proove that you really need the added performance? Otherwise just go with JMS....
Just my opinion...  |
|
| Back to top |
|
|
| JLRowe |
| Posted: Thu Oct 07, 2004 2:01 am Post subject: |
|
|
Yatiri
Joined: 25 May 2002
Posts: 664
Location: South East London
|
I don't see why JMS should be that much slower than the base mq classes in the basic putting and getting of messages, it only does a bit of field mapping.
Of course, initially accessing the JMS resources via JNDI will be an overhead, but it beats hardcoding QM + Q names into your code. |
|
| Back to top |
|
|
| RogerLacroix |
| Posted: Thu Oct 07, 2004 6:26 am Post subject: |
|
|
Jedi Knight
Joined: 15 May 2001
Posts: 3264
Location: London, ON Canada
|
Never ever hard-code names (regardless of the product).
Use property files for Java or ini files for C or for mainframe people, use sysin members. Always but always externalize configuration parameters.
Regards,
Roger Lacroix
_________________
Capitalware: Transforming tomorrow into today.
Connected to MQ!
Twitter |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Thu Oct 07, 2004 8:17 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| Quote: |
If for some reason there is change in the messaging middleware from MQSeries to other like Tibco...
|
has anyone ever heard any company switching to a different messaging system after investing time and effort in MQ? JMS proponents always bring this feature up. I wonder how many times this feature ever actually saves the day.
(maybe a myopic view from a schmo (me) that has only done IT at 1 company his entire life. I don't see us ever changing from MQ. To ingrained now.)
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| rammer |
| Posted: Thu Oct 07, 2004 11:43 pm Post subject: |
|
|
Partisan
Joined: 02 May 2002
Posts: 359
Location: England
|
| Quote: |
| has anyone ever heard any company switching to a different messaging system after investing time and effort in MQ? |
Yes, who I work for stated MQ was the chosen product for Messages, so why on a billion pound project are we suddenly using MSMQ when every body is skilled is MQ!!!!!!!!! - get me out of here.
I tend to think the reason is the Microsoft have decided to offer a few freebies!! |
|
| Back to top |
|
|
| JLRowe |
| Posted: Fri Oct 08, 2004 1:45 am Post subject: |
|
|
Yatiri
Joined: 25 May 2002
Posts: 664
Location: South East London
|
| With regards to JMS (and all the other API's), there is the aspect of competition also. Switching JMS providers, application servers or databases does not happen much in my experience, but it keeps up the competive pressure and the vendors on their toes. A customer may decide to use a different provider for a new project, any API skills learnt already are re-usable even though the specifics of each product are not. |
|
| Back to top |
|
|
| ewsachse |
| Posted: Thu Dec 02, 2004 8:23 am Post subject: |
|
|
Newbie
Joined: 02 Dec 2004
Posts: 3
|
| The MQ API gives you total control over the messaging. If your application is tightly integrated with MQ, then it is the better choice. |
|
| Back to top |
|
|
|
|
