| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| RE: MQSeries vs EGate |
« View previous topic :: View next topic » |
| Author |
Message
|
| Coltsnecknj |
 Posted: Tue Jan 29, 2002 10:26 am Post subject: |
 |
|
Newbie
Joined: 28 Jan 2002
Posts: 1
|
| Where can I find a comparative study of these two middleware products? My company currently uses EGate and I would be interested in knowing the advantages that MQSeries provides over our current product. |
|
| Back to top |
|
 |
| zpat |
| Posted: Wed Jan 30, 2002 1:51 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5849
Location: UK
|
MQSI v2 has very good MQSeries interfaces and good transactionality (commit/rollback) with XA support. It allows non-persistent messages to flow through without disk I/O.
Documentation and support is of IBM standard and of course they understand MQSeries well plus you can run a broker on OS/390 now.
[ This Message was edited by: zpat on 2002-01-30 02:22 ] |
|
| Back to top |
|
|
| rwa |
| Posted: Tue Feb 05, 2002 7:33 am Post subject: |
|
|
Voyager
Joined: 22 Jan 2002
Posts: 76
Location: Duesseldorf/Germany
|
We tested e*Gate and MQSeries to evaluate which product to use. These two products cannot be compared directly because e*Gate is more than just a middleware. For a comparision you have to add MQIntegrator to MQSeries. This combination can be compared.
The design of both products are different.
All logic of e*Gate is in the adaptors. Therefore it is small and easy to handle but it is hard to implement if the sender and receiver should not know each other. This has the advantage that this product is very flexible. Also the transactional support is build in the adaptors. This has the problem that messages can be delivered zero or two times in the case of failure.
MQSeries with Integrator has the logic and transactional support build centric, if the adaptors are build "stupid". Therfore it is not so flexible but save. We have not seen the problems with garanteed delivery as in e*Gate. Also the number supported adaptors and operating systems is higher. Because of the expirience with e*Gate we sticked with "stupid" adaptors in the tests. Also only MQSeries had a suffient Pub/Sub functions to fullfil our needs.
Therfore we desided for MQSeries with Integrator.
I know this reply is very short as an answer but hopefully this gives a hint how to compare the two products.
Rainer |
|
| Back to top |
|
|
| bduncan |
| Posted: Tue Feb 05, 2002 2:33 pm Post subject: |
|
|
Padawan
Joined: 11 Apr 2001
Posts: 1554
Location: Silicon Valley
|
I was one of several engineers in charge of evaluating eGate; our management had decided that we would replace MQSeries/MQSI company-wide with eGate. I spent nearly three months working on this project, and ultimately, was unable to convince management that eGate was an inferior product, and that we would be wise to continue working with MQSeries. My main issues with eGate were lack of redundancy (they basically relied on third-party failover products which did nothing more than fail the filesystems over) and the lack of XA-support for many of their adapters. eGate is also not multithreaded. This means that their eWays (agents in charge of propogating events) can suck up your system resources real quick. One of the funniest things one of the eGate consultants said was when I was asked how many queues our MQSeries queue managers managed. I said that certain systems had a few dozen, but there was technically no limit to the number of queues the queue manager handled; and there wasn't performance degradation for having more versus less queues (all else being equal). The eGate consultant simply couldn't fathom this; they recommend that each of their queue managers only manage a SINGLE queue. So basically, when they converted one of our MQSeries systems to eGate, we went from having 1 queue manager with 16 queues and one application for handling the messages - to an eGate system with 16 queue managers, 16 queues, and 32 applications to handle those messages. Oh, and we had to purchase another 2Gb of RAM and 80Gb of hard disk space for our enterprise level sun server to handle this additional "load". I don't have many good things to say about eGate; but if your application doesn't have high message throughput requirements, an eGate solution is still cheaper than buying MQSeries, so it might be for you. But if you have any technical questions about eGate, I can try and help you, because I did receive eGate training...
_________________
Brandon Duncan
IBM Certified MQSeries Specialist
MQSeries.net forum moderator |
|
| Back to top |
|
|
| zpat |
| Posted: Wed Feb 06, 2002 12:50 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5849
Location: UK
|
We evaluated E-Gate and MQSI head to head in a proof of concept - the selection (which initially reviewed the whole marketplace) was professionally managed by a PWC consultant working with us.
MQSI won. We already had MQSeries established which helped as use of E-Gate was seen to be introducing another messaging transport. There were other advantages to MQSI as I noted above. At the time E-gate used the "Monk" language which was not favoured. And of course as major IBM customers, the IBM factor was present.
[ This Message was edited by: zpat on 2002-02-06 00:51 ] |
|
| Back to top |
|
|
| bduncan |
| Posted: Wed Feb 06, 2002 11:15 am Post subject: |
|
|
Padawan
Joined: 11 Apr 2001
Posts: 1554
Location: Silicon Valley
|
Yes, the fact that eGate used this proprietary "Monk" language bothered me as well. The newest version of their product supported Java eWays, but as we discovered, the Java API to eGate didn't have all the functionality of the Monk API, so for certain things, it was impossible to use Java.
_________________
Brandon Duncan
IBM Certified MQSeries Specialist
MQSeries.net forum moderator |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
