| Author |
Message
|
| queuetip |
 Posted: Fri Mar 16, 2007 10:56 am Post subject: JMS vs. Proprietary Java Interface - Opinions Requested |
 |
|
Acolyte
Joined: 03 Feb 2005
Posts: 67
|
We would like to have our architecture support JMS because of the typical flexible benefits of it's nature.
I am digging into the MQ JMS interface to see if it has restrictions or limitations that using the proprietary MQ Java interface does not have. From what I have read to this point I don't see any.
Additionally, if using JMS introduces a significant amount of coding complexity and ambiguity in any particular area - then I'd like to know that too.
To give you an idea of what MQ techniques our app uses, here's a list:
* Request / reply model (correlation id)
* Sync gets
* Async gets with triggering
* Logical message grouping
* Concurrent processing against a common queue (horizontal)
* Transaction processing (commits and rollbacks)
* Significant performance hits are always good to know
Just trying to leverage this group's experience and background for comparing the 2 java coding models - especially looking for the gotchas!
Thank you!
Mike
 |
|
| Back to top |
|
 |
| jefflowrey |
| Posted: Fri Mar 16, 2007 5:25 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
The "fleixibility" and "vendor-neutrality" of JMS is typically over-hyped.
At least in the sense that, almost nobody ever really changes their messaging provider without doing lots of modifications and changes to their applications for other things, and so the "vendor-neutrality" of JMS does not ever actually produce any significant business-value.
In my opinion, and in my experience.
As for flexibility - JMS provides a specific kind of "view' onto the messaging layer, and this view comes with a fair number of assumptions and gotchas that generally end up being in some sense "equivalent" to the assumptions and gotchas of using a proprietary solution.
In my opinion and in my experience.
On the third hand, it makes it a lot easier to support third-party applications, even if you have to spend a month educating the third-party on the peculiarities of WMQ with JMS (as they likely developed with the JMS "provider" that comes with JBoss, and thus have no real concept of an enterprise messaging solution).
In my opinion and in my experience!
Your Millage *WILL* Vary.
I'm just a guy who posts *way* too much.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Fri Mar 16, 2007 9:05 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
I have to concurr with Jeff.
Each provider has different "quircks" and performance pittfalls.
You will need to at least take a look at optimizing the performance of your app if you switch JMS provider...
At the same time and this is entirely due to the way the JMS API is implemented and the design of the implementation of the service, each JMS provider will have its own limitations: some will work with a get accross servers, some won't. Some will be stand alone (i.e. the provider gives you all the soft that is needed to make it work), some will require a DB as backbone and persistency store ...
Enjoy 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| Michael Dag |
| Posted: Fri Mar 16, 2007 11:40 pm Post subject: |
|
|
Jedi Knight
Joined: 13 Jun 2002
Posts: 2607
Location: The Netherlands (Amsterdam)
|
I fully agree with Jeff too, how many times I heard people say let's go for JMS it's a standard... bla bla
but they forget (or sometimes don't even know  ) that only certain parts of the API is standardised (there are providers with specific extensions that are not JMS standard), so each provider has a different implementation/behaviour...
_________________
Michael
MQSystems Facebook page |
|
| Back to top |
|
|
| queuetip |
| Posted: Mon Mar 19, 2007 6:59 am Post subject: |
|
|
Acolyte
Joined: 03 Feb 2005
Posts: 67
|
Thank you for your insight! OK - it sounds like JMS API may be overhyped and dependent upon the JMS provider.
Since I am putting hooks in for other queuing software to be used to pass data into our system, I am still slightly leaning towards JMS at this point.
However, that depends on whether or not MQ can effectively support the MQ design features we are using today through JMS. Here they are again:
| Quote: |
[list=]* Request / reply model (correlation id)
* Sync gets
* Async gets with triggering
* Logical message grouping
* Concurrent processing against a common queue (horizontal)
* Transaction processing (commits and rollbacks) [/list] |
Thus...
1. Does MQ support all these features through JMS?
2. If so, is the MQ JMS interface significantly complex, "bulky" or performance- challenged?
3. Are there any features MQ does not support through JMS?
Thanks again!
Mike
:D |
|
| Back to top |
|
|
| Tibor |
| Posted: Mon Mar 19, 2007 9:23 am Post subject: |
|
|
Grand Master
Joined: 20 May 2001
Posts: 1033
Location: Hungary
|
As far as I remember there are more pros and cons and Java vs. JMS topic in mqseries.net.
For example JMS API does'nt support the message grouping and/or segmentation. But when you have to send messages with RFH2 header the JMS solve it quickly... etc.  |
|
| Back to top |
|
|
| queuetip |
| Posted: Tue Mar 20, 2007 7:21 am Post subject: |
|
|
Acolyte
Joined: 03 Feb 2005
Posts: 67
|
Thanks for the feedback, Tibor.
| Quote: |
As far as I remember there are more pros and cons and Java vs. JMS topic in mqseries.net.
For example JMS API does'nt support the message grouping and/or segmentation. But when you have to send messages with RFH2 header the JMS solve it quickly... etc. |
I looked around and I couldn't find the topic with pros and cons. It would appreciate a link if you can find it!
Are you saying message grouping isn't supported by JMS? Or do you "work around" it using the RFH2 header? What about the entire list of functionality I mention above?
Thanks!
Mike |
|
| Back to top |
|
|
| Tibor |
| Posted: Tue Mar 20, 2007 8:23 am Post subject: |
|
|
Grand Master
Joined: 20 May 2001
Posts: 1033
Location: Hungary
|
|
| Back to top |
|
|
|
|
