لطفا منتظر باشید ...
Chapter 6: XML Messaging and RPC with SOAP
The Oracle E-Business Suite of applications offers companies a new and better way to conduct business. The E-Business Suite combines customer relationship management (CRM), supply chain management, and internal operations as a fully integrated solution. The Oracle E-Business XML Services component, which is available in release 11.5.6 of Oracle Applications, provides a framework and system infrastructure for deployment, management, and run-time execution of XML Services, the foundation for developing a new generation of Web-enabled e-business applications. Central to this notion of XML Services is the concept of XML messaging based on SOAP, which underlies the communication of these applications via their key integration points (for example, XML Services, how XML Services are invoked, what events trigger them, and how event subscribers are able to handle them).
Introducing SOAP
The Simple Object Access Protocol (SOAP) is a lightweight, XML-based protocol for exchanging information in a decentralized, distributed environment. SOAP consists of three parts:
The SOAP Envelope, which defines an overall framework for expressing what is in the message, who should process the message, and whether the processing is optional or mandatory.
A set of encoding rules for expressing instances of application-defined data types. These rules define a serialization mechanism that converts the application data types to XML and vice versa.
A SOAP remote procedure call (RPC) convention for representing remote procedure calls and responses.
The major design goal for SOAP is simplicity and extensibility. SOAP has a looser coupling between the client and the server than some similar distributed computing protocols, such as Common Object Request Broker Architecture/Internet Inter-ORB Protocol (CORBA/IIOP). All this makes the protocol even more compelling. SOAP is transport protocol independent and thus can be used with any transport protocol. At the same time, when used with HTTP for remote service invocation over the Internet, SOAP emerged as a de facto standard for delivering programmatic content over the Web. SOAP 1.2 became a W3C recommendation in June 2003; however, the Oracle XFK 10g implementation is based on SOAP 1.1, which is a W3C note.
Since SOAP is XML based, it is platform and operating system independent. It supports communication between a client and server that use different programming languages. SOAP requests are easy to generate, and a client can easily process the responses. By using SOAP, one application can become a programmatic client of another application's services, with the two applications exchanging rich, structured information. SOAP provides a robust programming model that creates the possibility to aggregate powerful, distributed web services (such as XML services) to turn the Internet into an application development platform of the future.
Literal, Encoded SOAP Messages
The SOAP specification describes a standard, XML-based way to encode requests and responses, including:
Requests to invoke a method/function as a service, including in parameters
Responses from a service method/function, including return value and out parameters
Errors from a service
An illustration of a SOAP message format appears in Figure 6-1.
Figure 6-1: SOAP message format
Basically, the message itself is the key for a SOAP message; the payload is encoded in XML and has no knowledge of processing, while the header may contain processing details.
Consider the following example: a GetLastTradePrice SOAP request is sent to a StockQuote service. The request takes a string parameter, the company ticker symbol, and returns a float in the SOAP response. The XML document represents the SOAP message. The SOAP Envelope element is the top element of the XML document. XML namespaces are used to disambiguate SOAP identifiers from application-specific identifiers. The example uses HTTP as the transport protocol. The rules governing XML payload format in SOAP are entirely independent of the fact that the payload is carried in HTTP (because SOAP is transport independent). The SOAP request message embedded in the HTTP request looks like this:
POST /StockQuote HTTP/1.1
Host: www.stockquoteserver.com
Content-Type: text/xml; charset="utf-8"
Content-Length: nnnn
SOAPAction: "Some-URI"
<SOAP-ENV:Envelope xmlns:SOAP-
ENV="http://schemas.xmlsoap.org/soap/envelope/"
SOAP-ENV:encodingStyle=
"http://schemas.xmlsoap.org/soap/encoding/">
<SOAP-ENV:Body>
<m:GetLastTradePrice xmlns:m="Some-URI">
<symbol>ORCL</symbol>
</m:GetLastTradePrice>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
What follows is the response HTTP message containing the XML message in SOAP format as the payload:
HTTP/1.1 200 OK
Content-Type: text/xml; charset="utf-8"
Content-Length: nnnn
<SOAP-ENV:Envelope xmlns:SOAP-
ENV=http://schemas.xmlsoap.org/soap/envelope/
SOAP-ENV:encodingStyle=
"http://schemas.xmlsoap.org/soap/encoding/"/>
<SOAP-ENV:Body>
<m:GetLastTradePriceResponse xmlns:m="Some-URI">
<Price>34.5</Price>
</m:GetLastTradePriceResponse>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
One-Way and Two-Way SOAP Messaging and RPCs
The preceding example is an example of two-way SOAP messaging in that both the request and response are encapsulated in SOAP messages. A one-way SOAP message is one that simply sends out a request or a message, without needing an acknowledging SOAP message in return. In addition, SOAP allows the encapsulation and exchange of RPCs and responses.
Using SOAP for RPCs is not limited to HTTP requests and responses. In order to invoke a method, the following is needed:
A method name
An optional method signature
The parameters to the method
The URI of the target object
Optional header data
The method calls and responses are embedded in the SOAP Body using the following representation:
The method invocation is a data structure whose name and type is the same as the method name.
The data structure contains fields that act as accessors for each parameter of the method, each of whose name, type, and order are the same as in the method signature.
The method response is also a data structure, similar to the data structure that models the data invocation, except that the name is typically name_Response and the first accessor is the return value.
A method fault is encoded in the SOAP Fault section.
If additional information relevant to the encoding of a method request exists, it must be expressed within the SOAP Header section. For example, an alternative book ID may be embedded in the SOAP Header when passing along a SOAP message concerning the sale of a book, since this book ID would not be part of the method signature and can be extracted from the header by code on the receiving side.
