When to use Java and Message Broker?

Question

I am a developer at my office where SOA development is at its peaks. We use IBM MQ, IBM Message Broker and Java/J2EE Technologies.

I have been currently put into project where Message Broker is used to develop a middleware which interacts between two applications. I am not quite sure if Message Broker is the right option for such kind of a project since Java can do the same piece of work in a much efficient way, which led me to search Internet for advantages in using the two.

I read in different sites that Message Broker is used to transform,route and enhance messages, this can very well be done using java efficiently. So this led me to this question "When to use Java and When to use Message Broker for development?" It would be great if someone can help me with the advantages of using the two.

-RDJ

Answer 1

Message brokers enable eg operations people to monitor all integrations in one place. Also, if a data format changes it can be trivial to determine which integrations are affected by the change.

Each individual integration could probably be implemented in Java (or any other language, for that matter), but you'd end up but with a bunch of point-to-point integrations, which is one of the problems message brokers try to solve.

If you were to design a generalized transformation/routing solution in Java, you would be designing a message broker :) Which would be interesting, but not really necessary, seeing as plenty of commercial and open source message brokers are already available.

Answer 2

As I understand you are trying to, for example, implement the functionality in core java instead of going with a ready Message Broker and similar SOA related technologies. My suggestion is - do not reinvent the wheel. The point is, even if you try to do so, eventually you will face the same technical issues and lead to a similar solution. Why not focus on business logic instead of trying to develop an equivalent of something which is already there which is probably more tested and trusted.

Answer 3

From a more practical standpoint, websphere message broker offers a way to integrate non-java applications (C, COBOL, PHP, VB ...) which is often difficult to accomplish with java.

Also, Java is not particularly well suited to process XML. Both ESQL and XSLT are much better vehicles for xml transformation that Java.

Webshpere message broker is also able to deal with messaging outside the limitations of JMS (it can do JMS as well).

You might look at Websphere ESB which is kind of like a Java implementation of message broker. This product expect external non-java applications to adapt themselves to the Java world, so it has less integration capability, but I think java people will find it comfortable to work with.

Answer 4

Messaging is usually used when you have Heterogeneous application integration and may be used as a replacement for RPC specially when it is Asynchronous. It is also used to loosen the coupling between applications and as the backbone of an event-driven architecture. Using message to improve application scalability is very common. In some cases it is used for the systems which are not always available but guarantee to fulfill the request when they become available. Also it is used for systems which have more than one consumer per request.

Answer 5

Websphere Message Broker is an ESB whereas Java on the other hand is a programming language . There are ESBs which use Java as their implementation language like Axis , Fuse but are they powerful enough to parse XMLs , orchestrate services , integrate with mainframe systems .Webservice design and development in Message Broker is easy and user -friendly .ESQL as correctly pointed out is powerful for XML transformation and processing is the implementaion language used in Message Broker . Again , integration with MQ , HTTP , File nodes is seamless and efficent in MB .

Answer 6

First thing to understand is that the Java-API for Broker sits on top of the C-API and does not give you full access to all the available functionality.

Secondly its Ugly, I would not use it for simple mapping transformations, and of course these days there is the visual mapper as well.

That said its still useful in special circumstances. One example where I used it was to match merge some message content. Basically the scenario was receive Msg1 containing 2000+ elements and then get a corresponding message Msg2 containing 2000+ elements that provided additional detail.

So in ESQL you are reduced to starting with Msg1.element[1] and then scanning Msg2 for a match, to optimise you can delete elements from Msg2 as they get used up. Still it was horrendously expensive in terms of CPU especially once things started to scale up from 2000+ to 5000+. And it took a long time, over 5 minutes for really large messages.

The alternative was to use the Java compute node and load the content of the second message into a Java Tree object, this reduced the processing time to about 3 seconds.

So if you are just doing transformation steer clear of the Java compute node. If however you are doing something more complex and/or CPU intensive then certainly give the Java compute node a try.