2

JMS or messaging is really good in tying up disparate applications and form the infrastructure of many ESB and SOA architectures.

However say Application A needs an immediate response from a service on Application B e.g. Needs the provisioning details of an Order OR Needs an immediate confirmation on some update. Is Messaging the right solution for that from a performance point of view? Normally the client would connect to a MoM on a Queue - then a listener which has to be free will pick up the message and forward to the server side processor - which will process the response and send it back to a Queue or Topic and the requesting client will follow the same process and pick it up. If the message size is big the MoM will have to factor that in as well.

Makes me wonder if Http is a better solution to access such solutions instead of going via messaging route? I have seen lots of applications use MoM like AMQ or TIBCO Rvd to actually use for immediate Request/Response - but is that bad design or is it some fine tuning or setting that makes it same as Http.

Soumya
  • 1,054
  • 2
  • 16
  • 31

1 Answers1

2

It really depends on your requirements. Typically messaging services will support one or all of the following:

  • Guaranteed Delivery
  • Transactional
  • Persistent (i.e. messages are persisted until delivered, even if the system fails in the interrim)

An HTTP connection cannot [easilly] implement these attributes, but then again, if you don't need them, then I suppose you could make the case that "simple" HTTP would offer a simpler and more lightweight solution. (Emphasis on the "simple" because some messaging implmentations will operate over HTTP).

I don't think Request/Response implemented over messaging is, in and of itself, bad design. I mean, here's the thing.... are you implementing both sides of this process ? If not, and you already have an established messaging service that will respond to requests, all other considerations aside, that would seem to be the way to go... and bypassing that to reimplement using HTTP because of some desgin notion would need some fairly strong reasoning behind it, in my view.

But the inverse is true as well. If you an HTTP accessible resource already, and you don't have any super stringent requirements that might otherwise suggest a more robust messaging solution, I would not force one in where it's not warranted.

If you are commensing totally tabula-rasa and you must implement both sides from scratch..... then..... post another question here with some details ! :)

Nicholas
  • 15,916
  • 4
  • 42
  • 66
  • Thanks . Well for new projects and want to set some standards for what kind of services go in JMS/HTTP. e.g. Ordering process - though it may do a sequence of shortlived automated events still after submitting an order we can fire and forget - so JMS fits perfect. However for certain bits like I want the status of a service - currently that's over JMS and we are thinking over moving to HTTP. - i admit we havent done any performance tests but trying to gather if anyways http is better in case of immediete reponse than JMS. Changing code is fine - just change the connecting API to HTTP from JMS – Soumya Mar 01 '13 at 16:51
  • hi Nicholas - based on my comment above can you kindly comment further? Thanks – Soumya Mar 04 '13 at 15:34
  • 1
    In the case of your 2 examples, they sound like the right fit in each case. JMS is really good at Fire-n-Forget, but for more utility-like things such as status checks, it makes sense to use HTTP, and also simplifies the invocation and expands the potential client base (it's a lot easier to issue a WGET command on the command line, than to send a JMS message....) – Nicholas Mar 04 '13 at 16:36
  • Using Spring in client and server, we use JMS for async and sync The benefit of this is that client only sees the service interface, the – shuttsy Mar 05 '13 at 11:26