Supported Protocols

When designing your web service in WebLogic Workshop, you can choose which protocols your web service supports for sending and receiving data. A protocol is a low-level network scheme for passing messages between systems. It provides a set of rules for formatting and encoding data in a standard way.

WebLogic Workshop currently supports two protocols: HTTP, or Hypertext Transport Protocol, the basic protocol used by web browsers and web servers; and JMS, or Java Messaging Service, a component of the J2EE specification. WebLogic Server includes WebLogic JMS, and can also support other third-party messaging systems.

Your web service can support one or both protocols. Each method and callback on your service can also support either or both protocols. To specify which protocol a service or one of its methods or callbacks uses, set the attributes of the protocol property of that service, method, or callback. For more information on setting the protocol property, see Supported Message Formats.

HTTP

The most common protocol supported by web services is HTTP (Hypertext Transport Protocol, the basic protocol used by web browsers and web servers). Although HTTP has been most commonly used to transmit World Wide Web documents up until now, it can be used to transmit almost any document. The fact that it is ubiquitous and flexible and that most firewalls are trained to allow HTTP messages to pass through makes it a useful protocol for web services which need to be available to users in geographically dispersed locations, over the Internet.

HTTP is also a useful protocol for web services that require synchronous, two-way communication. When a client calls a method of your web service over HTTP, that method may immediately return a value to the client.

However, HTTP lacks many features that are crucial to the enterprise, most notably reliable asynchronous messaging. In order for two systems to exchange messages via HTTP, both systems must be available. If one is not, there is no guarantee that the message will be delivered; HTTP provides no means for persisting that message. Also, HTTP does not provide transactional support, so complex operations cannot be reliably executed over HTTP. For enterprise applications that require asynchronous messaging and transactions, consider using JMS as the transport protocol for your web service.

JMS

JMS is a useful protocol for distributed enterprise applications that require asynchronous, loosely-coupled, highly reliable communication. When a message is exchanged via JMS, the system posting the message can be completely independent of the system that retrieves the message. JMS serves as the middleman; the participating systems don’t have to communicate in any way, or even be simultaneously available, to exchange information asynchronously. The message is guaranteed to be delivered, because JMS persists the message until it is retrieved by its intended recipient.

JMS also supports transactions, so that complex operations are performed in a controlled, coordinated manner. Transactions guarantee that an operation involving a number of resources will either succeed completely or fail completely, so that the system is left in a stable state either way.

When your service uses JMS as a transport protocol, it employs a JMS queue. JMS queues are one-way, so synchronous return messages are not sent to your service when you send data over JMS. Methods using the JMS protocol must have a void return. Your service should return results to the client either by using a callback or by using a JMS control to put another message on the queue.

Related Topics

Supported Message Formats