This question already has answers here:
JMS vs Webservices
(9 answers)
Closed 7 years ago.
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 ...
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.
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.
check the links
difference between using JMS/Messaging Middleware versus Web services
Messaging, JMS and Web Services
Web Services HTTP vs. JMS
Choosing among JCA, JMS, and Web services
Java Message Service
Web service
So if communicating Applications are Java based use JMS and if may be different then Web services... thats what which I follow.
For interoperability sake, use a web service. JMS is little used outside the Java world.
Related
In developing backend components, I need to decide how these components will interact and communicate with each other. In particular, I need to decide whether it is better to use (RESTful, micro) web services versus a message broker (e.g. RabbitMQ). Are there certain criteria to help decide between using web services for each component versus messaging?
Eranda covered some of this in his answer, but I think three of the key drivers are:
Are you modeling a Request-Response type interaction?
Can your interaction be asynchronous?
How much knowledge does the sender of the information need to have about the recipients?
It is possible to do Request-Response type interactions with an asynchronous messaging infrastructure but it adds significantly to the complexity, so generally Request-Response type interactions (i.e. does the sender need some data returned from the recipient) are more easily modeled as RPC/REST interactions.
If your interaction can be asynchronous then it is possible to implement this using a REST interaction but it may scale better if you use a fire and forget messaging type interaction.
An asynchronous messaging interaction will also be much more appropriate if the provider of the information doesn't care who is consuming the information. An information provider could be publishing information and new consumers of that information could be added to the system later without having to change the provider.
Web server and message broker have their own use cases. Web server used to host web services and the message broker are use to exchange messages between two points. If you need to deploy a web service then you have to use a web server, where you can process that message and send back a response. Now let's think that you need to have publisher/subscriber pattern or/and reliable messaging between any two nodes, between two servers, between client and server, or server and client, that's where the message broker comes into the picture where you can use a message broker in the middle of two nodes to achieve it. Using message broker gives you the reliability but you have to pay it with the performance. So the components you should use depends on your use case though there are multiple options available.
I am new into these topics. JMS and web services seem to have same purpose but I feel there is lot more differences? Can someone provide the differences? And when are these technologies applied?
Depending on your requirements and your architecture you can use both, they can even be used together.
JMS is a messaging standard specifically for Java EE. So it is better to compare Message Passing and Web Service.
A good idea is to read on wikipedia
http://en.wikipedia.org/wiki/Message_passing
http://en.wikipedia.org/wiki/Web_service
A similar discussion took place here: Difference between JMS and Web Service
As an example, in the case my architecture was exposing to the world an interface, I would most likely offer web services. If however my architecture was to connect with a fast producing events module over a secure connection, I would use message passing.
I'm going to be building an app shortly that requires reliable, reasonably high throughput messaging. Many of the endpoint consumers of our messages are SOAP web sevices however.
RabbitMQ and related technologies look very attractive - decoupling message delivery from the application, and providing a reliable message queuing system that can persist even through a reboot. This sounds very attractive, but from what I've read, RabbitMQ is designed for an architecture in which you maintain both the consumer and the publisher.
Are there any similar messaging systems that can target web services?
You will always need some mapping between the message and the parameters of the web service. Should be very easy to create a small "bridge" app to receive the message and call the web service. You would still gain teh advantages of using RabbitMQ / SOA and the arcitectures this allows
I am trying to learn different web services to understand what they are used for. But, I am confused as these terms overlap frequently. I would appreciate if someone can tell me briefly what are the differences between these terminologies. I came across some sources such as http://java.sun.com/developer/Books/j2ee/jws/ch07.pdf, however I am not able to distinctly differentiate them.
Web Service: a standards-conforming invocable service, might be written in Java, might be written in some other technology, e.g. .NET. Key point is that there is a standard language, WSDL, that describes the service. The WSDL contains information about the transport, protocol, where the service is running, the available operations and the payloads flowing to and fro.
Most Web Services you will encounter use SOAP messages (a particular XML format) over an HTTP protocol, and so the WSDL will contain the URL of where to invoke the service. More generally other message formats and protocols are possible - we'll come back to that point in a moment.
Suppose you have the WSDL for a service that you wish to invoke from a Java program, then in principle you can write Java to format a suitable XML payload and squirt the message down an HTTP connection. Perfectly doable, but very tedious, almost all the code is boilerplate code, which can be generated from the the WSDL.
Equally, if you want to create a Web Service in Java then you might begin by writing the WSDL, but once again there's lots of standard boilerplate code for reading HTTP, parsing XML etc. So in both cases you benefit from standard Java APIs for doing all that work. There have been several such APIs, JAX/RPC and JAX/WS are two such, and JAX/WS is the more recent and easier to use.
An alternative integration technology is to use messaging, there are many vendors who provide message queuing products, so it's perfectly possible to send messages from (say) Java to (say) C++, you just need to agree on the message format (no standard WSDL there to tell you).
JMS is a Java programming API that provides an abstraction about specific vendors' messaging products. If working in Java, JMS gives you portability across messaging products. The Java EE standard requires that Java EE App Server vendors provide a messaging infrastructure - I believe that as business systems get large, they nearly always need some asynchronous messaging facilities.
There are various possibilities for applying WSDL-like approaches to messaging. For example it is possible to write a Web Service using SOAP/JMS rather than SOAP/HTTP. JAXM is an emerging API in this space. Frankly I'm unclear as to its relationship to SOAP/JMS and standards such as WS-ReliableMessaging.
I venture that most but not all web services today are synchronous. A fundamental design decision existing if to implement asynchronous processing.
Is there value in implementing a processing queue system for asynchronous web services? It is a MOM/infrastructure decision with which I am toying. Instead of going system-to-system implement a middleware which will broker said transactions. The ease of management and tracking/troubleshooting of a spider web of services seems to make the most sense.
How best have you implemented asynchronous web services?
It is interesting I stumble into this question. I have exactly the same concern with the current project I am developing.
Our web services are develop using TIBCO technology, and they are also synchronous by default. We are considering creating a queue mechanism to process these requests asynchronously; the reason being: the back-end storage technology we have to interface with is notoriously slow (it is an imposed technology, and we have to deal with it)
Personally I am considering creating a 2nd WSDL definition for the asynchronous replies (which can occur from a few seconds to a few hours later than the request, depending on the load on the mentioned back-end storage.) Clients calling our Web Services will have to in turn implement a web service using this "2nd WSDL" to which we act as clients.
I'd be interested in knowing the directions you are exploring.