Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Difference between JMS and Web Service [duplicate]

Tags:

I need to develop a system which accepts orders and returns confirmation. Orders could come from java or non java clients.

Not sure whether to go for web service implementation or JMS.

Any suggestions ...

like image 795
SyAu Avatar asked Sep 02 '10 06:09

SyAu


People also ask

What is the difference between JMS and Web services?

JMS is an API which abstracts messaging middleware, like ActiveMQ or IBM MQSeries. Messaging middleware has a store-and-forward paradigm and asynchronous message passing, while web services tend to promote a synchronous procedure calling paradigm.

When should I use JMS vs Web services?

JMS and WS both enable distribute applications. The difference is asynchronous(JMS) vs synchronous (Web Services). Web Services can be implemented in SOAP or REST styles. JMS is a api which supports communication in two modes - point-to-point and publish-subscribe.

What is difference between JMS and REST API?

REST is a service/pattern to give you an organized way to access a stateless resources. MOM Systems/JMS is a pattern designed aroubd sharing messages between systems. Its about data in, data out in a reliable fashion. You can't really compare JMS to REST because they solve different problems.

What services are provided by JMS?

Java Message Service (JMS) is an implementation of such a messaging system. It provides an API for creating, sending, receiving, and reading messages. Java-based applications can use it to connect to other messaging system implementations.


2 Answers

JMS is an API which abstracts messaging middleware, like ActiveMQ or IBM MQSeries.

Messaging middleware has a store-and-forward paradigm and asynchronous message passing, while web services tend to promote a synchronous procedure calling paradigm. In distributed systems where a lot can go wrong, dealing with things asynchronously tend to focus the mind better to the things you need to do when part of the system is not available or poorly performing and the code needed to deal with that tends to be a lot less complicated.

Clustering parts become trivial if you have multiple servers listening on the same queue, parallelism and load balancing is for free in this case.

Personally I find JMS much easier to work with and more robust and reliable than web services, but the messaging middleware must support all platforms you want to use. If all the components who need to talk to each other are under your control, I would give a messaging middleware with a JMS interface serious consideration.

If the other party is external then probably Web Services rule, and in that case you could think of a using thin layer to convert the external web service to an internal message passing infrastructure so you still have the most of the advantages.

If it is "just slapping an remote API on a webapp" then of course it does not pay either to setup asynch messaging.

like image 198
Peter Tillemans Avatar answered Oct 26 '22 00:10

Peter Tillemans


You can use both depending on your interoperability, scale, distribution and integration requirements.

Web service approaches utilising SOAP, XML RPC and REST provide something quite interoperable given the use of HTTP as the protocol. From a service side, you might receive a web service request and then marshal it into a message. Your message could then be delivered to a messaging bus.

JMS is a reasonable API for interfacing with a messaging bus and I've found that Active/MQ very good here. Active/MQ supports JMS across many languages.

With messaging you can utilise the Request/Reply Enterprise Integration Pattern to receive responses and return them via your web service. However think about the merit of providing immediate feedback as to whether the order has been processed vs feeding back the fact that an order has been received; you might not need to implement request/reply to acknowledge that an order has been received.

The benefits of messaging can be found here: http://www.eaipatterns.com/Messaging.html

You may even want to look at Apache Camel to simplify the development of highly scalable and distributed service layers.

like image 36
Christopher Hunt Avatar answered Oct 25 '22 23:10

Christopher Hunt