Gaurav, >>>In our organisation we are thinking of replacing Websphere MQ >>>Integrator(mqsi) 2.1 with MQ Event Broker.I wanted to know if >>>anyone has any experiences with event broker.Is there something >>>that mqsi support that event broker doesn't support.Our >>>requirements are basically for simple PU-SUB and with some >>>message routing logics in message flows.We are using JMS. Also >>>what changes we need to make to do this shift.
There are several issues you need to consider. First, with WMQEB, you have only the Publication node and input and output nodes for MQ, MQe, JMS and SCADA. There are no decision nodes (like the Filter or Label/RouteToLabel nodes that exist in WMQI), so if the message routing logic in message flows that you mention uses these today, you will need to continue with WMQI and the more robust set of processing nodes it supplies. Another point is that, with WMQEB, content filtering only works with messages whose body can be parsed using the generic XML parser. If you use NEON or MRM for parsing messages, or do any message modification (stripping off headers, etc) prior to routing, again, you will likely run into the situation where WMQEB alone won't meet your requirements. Also, if your current WMQI brokers are implemented using multiple execution groups for throughput or message flow isolation, note that WMQEB only supports a single execution group. This may require you to implement (and administer) multiple WMQEB brokers where with WMQI a single broker with multiple execution groups would suffice. Please don't take the above as implying that WMQEB is a bad product, or one that could not be used in your organization. But it is a pure pub/sub engine, while you apparently have requirements for more than that (message routing logic in message flows). A strong feature of the product (and one that WMQI currently does not have) is the direct TCP/IP connection support between the broker and JMS clients. This enables very high performance pub/sub and can support very large numbers of subscribers, BUT the direct TCP/IP connection support is ONLY available to non-durable subscribers using non-persistent, non-transacted messages. I don't know if this restriction is acceptable to you. If you need assured delivery, and/or require durable subscribers, WMQEB can still be used, but will operate in a mode equivelent to what you have with WMQI today, but without the ability to satisfy your requirement for message routing logic in message flows. This is what you must consider carefully. On the other hand, you can certainly consider a strategy of having a broker domain that consists of both WMQI and WMQEB brokers, using the features of each as appropriate, as these brokers can interoperate. Regarding your question on what changes you need to make to do this shift: Any existing applications that use administered objects should not need to be modified to move from WMQI to WMQIEB. However, the administered objects they reference may need to be modified, for example, to use the direct transport type. This would be done using JMSAdmin. Regards, Christopher Frank Sr. I/T Specialist - IBM Software Group IBM Certified Solutions Expert - Websphere MQ & MQ Integrator -------------------------------------------- Phone: 612-397-5532 (t/l 653-5532) mobile: 612-669-3008 e-mail: [EMAIL PROTECTED] Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
