In Web services, service requesters and service providers communicate with each other in the form of XML messages. If you would like your software to use a web service, it must send a request message and it should receive a response. This request- response messaging pattern is the basis of all interactions between web services and the software that uses those services. These messages conform to SOAP a standard developed at Microsoft and originally standing for a Simple Object Access Protocol. That meaning has since been dropped, but it does give you an idea of its purpose; which is to allow a service requester to invoke services. SOAP provides centralization to interactions between service requesters and service providers or clients and servers. It defines how to organize requests and responses in XML, in a standard way that is understood by both parties. This standardize communication allows for inter-operability between platforms and languages. SOAP also provides instructions for how the message is bound to the underlying transport protocol, which will be HTTP in this lesson. Like a method call, in an object oriented language, the purpose of a SOAP message is to solicit an operation. In this case, from a remote web service. Imagine you are using a web service to determine the exchange rate between two currencies. Your program requests this information with a SOAP message. A SOAP message is in XML format formatted document. Here's an example of a SOAP message structure. The envelope identifies the XML document as a SOAP message and is required for SOAP. The header on the other hand, is not required. It may contain contextual information, like information about the client or routing information. The body of the SOAP message is required and contains the real message being conveyed. The body contains the information that the service provider needs to determine which service to provide and the services inputs. There are two styles of soap messaging; document and RPC style. In documents style SOAP, a SOAP message is like when a company produces a purchase order. It is a structured document that contains a request that will be understood by both parties. An RPC or remote procedure call style, looks very similar but the body of the message, looks more like a method call. It will consist of an operation and input parameters. SOAP does not dictate a style to use, only the structure of the message. Nevertheless, both of these interaction styles are commonly used. Let's have a look conceptually, at what a SOAP message might look like for our example, the currency exchange rate web service. On the left, the documents style is used. In this style, the type of request is determined by the type of document. The two currencies that the service requester wants to compare are fields in the document. On the right, there is essentially a method call in the body of the SOAP message with the two input parameters being the two currencies to compare. SOAP messages must be sent over some kind of transport protocol. Though the messages could be sent on other protocols, like SMPT which is used for email, we'll focus on using HTTP. A SOAP message can be sent using HTTP post. HTTP determines where to send the request, since this information is not directly included in the SOAP message itself. Since HTTP must acknowledge a post request, it could return the response or simply an acknowledgement that the request has been received. If the service requester waits for a response before continuing, then the messaging is said to be synchronous. While synchronous messaging is intuitive, the availability or response time of a web service may be an issue and your program may be left doing nothing while it waits for a response. Asynchronous interactions allow your code to keep executing. When response comes back from a service provider, your code can process it. A simple implementation of a SOAP request looks something like this. The client code makes a local call to a stub which converts the request into a SOAP message. The SOAP message is packaged into HTTP and sent to the service provider. Once it arrives, the HTTP server passes the content to a SOAP router, whose job is to determine the appropriate server stub and deliver the message. The stub uses the information contained in the SOAP message, to make an appropriate method call. After the service code handles the request, the process works in reverse to send the response. There are four basic messaging patterns possible. Request response; the request response pattern is when the service requester first sends a message then receives a reply from the service provider. This process is synchronous. It can be implemented over HTTP, which is inherently synchronous. The currency exchange example used a request response messaging pattern. In solicit response, which is also synchronous, the service provider instead makes a request to the service requester. This is often a confirmation. For example, the currency exchange rate could be sent to the service requester which in turn sends a confirmation, so that the service provider knows the requester has been updated. In the one way communication pattern, the service requester sends a request to the service provider but no response is expected. This could be a simple notification that the service requester is up and running. This pattern is inherently asynchronous, since no response is expected. In the notification message pattern, the service provider sends a notification to the requester without expecting a response. Perhaps, your code simply works with the latest exchange rate and gets updated every time the service notifies it. This model is well-suited to event based systems, where there are publishers and subscribers, like a blog or a weather notification service. This messaging pattern is also asynchronous. Many meaningful interactions between processes will require more complicated messaging patterns. Since SOAP messages are stateless, these interactions are implemented by relating messages some other way. Like, storing the interaction state on the client and or the server or by using extensions to Web services like WS coordination. Because of a few disadvantages, SOAP has been superseded in many applications by lighter weight methods that use HTTP more directly such as RESTful Web services. XML encoding and decoding adds overhead and does not easily accommodate some data types. Nevertheless, SOAP and its related web service infrastructure were the basis of the first major consensus on Web services. SOAP's neutrality allows systems on different platforms and in different languages to interact and pass data. The XML based structure, allows for machine readable data that can be manipulated by any machine connected to the Web.
