What are the big advantages from JMS over Webservices or vice versa?
(Are webservices bloated? Is JMS overall better for providing interfaces?)
Answer
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.