What are the big advantages from JMS over Webservices or vice versa?
(Are webservices bloated? Is JMS overall better for providing interfaces?)
+6
A:
EDITED after correction from erickson:
JMS requires that you have a JMS provider, a Java class that implements the MessageListener interface for processing messages, and a client that knows how to connect to the JMS queue. JMS means asynchronous processing - the client sends the message and doesn't necessarily wait for a response. JMS can be used in a point-to-point queue fashion or publish/subscribe.
"Service" is a fluid term. I think of a service as a component that lives out on a network and advertises a contract: "If you send me X I'll perform this task for you and return Y."
Distributed components have been around for a long time. Each one communicated using a different protocol (e.g., COM, Corba, RMI, etc.) and exposed their contract in different ways.
Web services are the latest trend in distributed services. They use HTTP as their protocol and can interoperate with any client that can connect via TCP/IP and make an HTTP request.
You can use SOAP or RPC-XML or REST or "contract first" styles, but the underlying idea of a distributed component using HTTP as its protocol remains.
If you accept all this, web services are usually synchronous calls. They need not be bloated, but you can write bad components in any style or language.
You can start designing any distributed component by designing the request and responses first. Given those, you choose JMS or web services based on what kind of clients you want to have and whether or not the communication is synchronous or asynchronous.
duffymo
2009-05-12 22:57:31
JMS is not Java-only. JMS was carefully designed to allow vendors to provide Java interfaces to their proprietary message services. There are also JMS providers for open messaging protocols like ebXML. Both approaches allow a JMS-based Java application to interoperate with messaging applications on other platforms.
erickson
2009-05-12 23:04:18
Thanks for the correction, erickson.
duffymo
2009-05-12 23:09:24
So WS-* and JMS are both ways to advertise contracts for distributed communication. When should I use WS-* and when should I use JMS?I read http://www.unf.edu/~ree/1024IC.pdf . JMS outperforms WS-* for small data sets there and offers support for "offline targets" and WS-* can handle larger amounts of data better. Is that the only advantage/disadvantage? Is the afford for writing JMS endpoints equal to WS-* endpoints? How to make an decision between one of them? It seems JMS is more lightweight isn't it?
Martin K.
2009-05-13 06:33:18
When you say "large amounts", what do you mean? WS-* are poor at handling very large data because of the difficulty of large XML documents. Most JMS aren't optimized to handle huge data either, but since there is more latitude for implementation in a proprietary system, a JMS provider is in a better position to handle it. As for which to choose, it depends on the application, and how messages are to be used, not so much on the message itself (size and format). And, don't forget, a JMS provider could be implemented with WS-* services.
erickson
2009-05-13 16:25:06
A:
From the ones I've done here's the differences I've found: JMS - I'm tied to the JMS provider - however I have choices of implementation type (pub/sub, point to point) Web Service - easier to handle/architect - however its more of a direct communication between the boxes. Lots of tools to use to do the development - and a clean interface (WSDL's) so implementor and caller can be independent.
Which one to use? Depends on what the problem is.
BZ
2009-05-12 23:04:36
WSDL is by no means a guarantee of independence. If you expose Java classes, you have to make them available to both client and server. Changes in those classes exposed in WSDL require updates to both. "contract first" XML is a better way to go.
duffymo
2009-05-12 23:26:47
+2
A:
I'd say the biggest distinction is that JMS is message-oriented, rather than RPC-oriented. Out-of-the-box, most JMS providers support high-level protocols that perform retries, prevent duplicates, and support transactions.
There are many applications where these capabilities are unnecessary. But where they are needed, building them yourself on top of an RPC mechanism is complicated, expensive, and error-prone.
erickson
2009-05-12 23:10:14
HTTP and XML and SOAP does not require an RPC model. In fact the WCF within .NET has options for dealing communications as incoming and outgoing messages. It's very message-oriented. I think there are similar metaphors available in Java-based "web services" stacks.
Cheeso
2009-05-12 23:36:26
Sure, you can pass "messages" over RPC, and Java does provide that capability as well. By "message-oriented", I meant asynchronous, reliable, and transactional, which are things you don't get from a REST or WS-* based web service... although you can, of course, define the necessary higher-level protocol using individual unreliable, synchronous operations.
erickson
2009-05-12 23:46:57
+4
A:
Message based systems, including JMS, provide the ability to be "chronologically decoupled" from the other end. A message can be sent without the other end being available.
All other common A2A approaches require the partner to be able to respond immediately, requiring them to be able to handle peak loads, with little ability to spread processing.
Richard
2009-05-12 23:14:40
+1
A:
Would add this as a comment to dyffymo's post, but don't yet have the rep.
Quoting from your answer:
"Web services are the latest trend in distributed services. They use HTTP as their protocol and can interoperate with any client that can connect via TCP/IP and make an HTTP request.
You can use SOAP or RPC-XML or REST or "contract first" styles, but the underlying idea of a distributed component using HTTP as its protocol remains."
I'm assuming by web services you mean the WS-* set of protocols, WSDL, and SOAP. If so, then none of these require the use of HTTP as the "transport" protocol. The SOA set of protocols was designed to be agnostic as to the tramission protocols used, so you can use HTTP, NamedPipes, raw TCP, and even JMS as the means to transmit messages to and from a web service.
So in the case of direct use of JMS vs. use of "web services" I think it mostly boils down to tooling, comfort level, and whether you really need direct access to some JMS specific feature (which using WS-* would hide from you). At this point I would think that only fairly specilized applications would require raw JMS access.
sfitts
2009-05-13 05:01:07