|
|
|
|
A web service makes software application resources available over networks using standard technologies. Because web services are based on standard interfaces, they can communicate even if they are running on different operating systems and are written in different languages. For this reason they are an excellent approach for building distributed applications that must incorporate diverse systems over a network.
The following topic outlines the standard technologies that you use to build web services and the advanced functionality available through asynchronous web services.
Web services are able to expose their resources in this generally accessible way because they adhere to recognized standards. A web service:
The Web Service Description Language (WSDL) is a standard XML format for describing web services. A WSDL file describes a particular web service so that other software applications can interface with it.
WSDLs are generally publicly accessible and provide enough detail so that potential clients can figure out how to operate the service solely from reading the WSDL file. If a web service translates English sentences into French, the WSDL file will explain how the English sentences should be sent to the web service, and how the French translation will be returned to the requesting client. For more information on WSDL files see WSDL Files: Web Service Descriptions.
Extensible Markup Language (XML) messages provide a common language by which different applications can talk to one another over a network. Most web services communicate via XML. A client sends an XML message containing a request to the web service, and the web service responds with an XML message containing the results of the operation. In most cases these XML messages are formatted according to SOAP syntax.
Simple Object Access Protocol (SOAP) specifies a standard format for applications to call each other's methods and pass data to one another. The types of messages supported by a particular web service are delineated in the service's WSDL file.
Web services receive requests and send responses using widely used protocols such as HyperText Transfer Protocol (HTTP) and Java Message Service (JMS). A web service may support more than one protocol. The protocols that a web service supports are published in the WSDL file.
The following illustration shows the relationship between a web service (in the center), its client software applications (on the left), and the resources it uses, including databases, other web services, and so on (on the right). A web service communicates with clients and resources over standard protocols such as HTTP by exchanging XML messages. The WebLogic Server on which the web service is deployed is responsible for routing incoming XML messages to the web service code that you write. The web service exports a WSDL file to describe its interface, which other developers may use to write components to access the service.
Many business processes take more than a few moments to complete, but traditional architectures make it hard to handle long-running tasks efficiently. Workshop for WebLogic helps you architect asynchronous web services easily using conversations and callbacks. Conversations help manage the typical problems in asynchronous messaging, namely correlating messages and managing some information or state between message exchanges. In an ongoing conversation, a web service can notify a client when the results of an operation are ready using a callback.
In addition, WebLogic Sever supports the use of Java Message Service (JMS) queues as message buffers to ensure that web service messages are not lost regardless of server load. JMS can also be used to communicate with back end resources. For more information on using buffers see Creating Buffered Web Services in the WebLogic Server documentation.
BEA WebLogic Platform supports two models for asynchronous web services. One model uses "callbacks"; the other uses "asynchronous request-response". The two models differ in the way that the web service and the client divide up the work of coordinating the asynchronous communication.
On the callback model of asynchronous web services, both the web service and its client (a web service control) are specially designed for asynchronous communication with one another. On this model, the web service is explicitly designed to be called asynchronously, including specially annotated callback methods that send data back to the client. Similarly the web service control is explicitly designed to listen for and receive callbacks from the web service using specially annotated event set methods.
For more information on the callback model see Web Service Callbacks.
The asynchronous request-response model places all of the burden of asynchronous coordination on the client. On this model the target web service does not need to be explicitly designed to be asynchronously called. The only requirement of the target web service is that it comply with the WS-Addressing standard. The client takes on all of the burden of coordinating the asynchronous response or failures that are later returned by the web service.
For more information on the asynchronous request-response model, see Invoking a Web Service Using Asynchronous Request-Response.
 |
