|Oracle9i Application Server Oracle9iAS SOAP Developer's Guide
Release 1 (v220.127.116.11)
Part Number A90297-01
This chapter provides an overview of the Simple Object Access Protocol (SOAP), and includes a description of the architecture of the Oracle SOAP implementation.
This chapter covers the following topics:
The Simple Object Access Protocol (SOAP) is a lightweight, XML-based protocol for exchanging information in a decentralized, distributed environment. By combining SOAP-based requests and responses with a transport protocol, such as HTTP, the Internet becomes a medium for applications to publish database-backed Web services, such as:
SOAP has a looser coupling between the client and the server than some similar distributed computing protocols, such as CORBA/IIOP, and it provides easier communication for a client and server that use different languages. SOAP exposes a standard way for processes to communicate, yet it leverages existing technologies.
SOAP requests are easy to generate, and a client can easily process the responses. One application can become a programmatic client of another application's services, with each exchanging rich, structured information. The ability to aggregate powerful, distributed Web services allows SOAP to provide a robust programming model that turns the Internet into an application development platform.
SOAP has the following features:
The SOAP specification describes a standard, XML-based way to encode requests and responses, including:
SOAP describes the structure and data types of message payloads by using the emerging W3C XML Schema standard issued by the World Wide Web Consortium (W3C). SOAP is a transport-agnostic messaging system; SOAP requests and responses travel using HTTP, HTTPS, or some other transport mechanism.
Figure 1-1 illustrates the components in the SOAP architecture. In general, a SOAP service remote procedure call (RPC) request/response sequence includes the following steps:
The SOAP specification does not describe how the SOAP server should handle the content of the SOAP message body. The content of the body may be handed to a SOAP service, depending on the SOAP server implementation.
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance" xmlns:xsd="http://www.w3.org/1999/XMLSchema"> <SOAP-ENV:Body> <ns1:getAddressFromName xmlns:ns1="urn:www-oracle-com:AddressBook" SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"> <nameToLookup xsi:type="xsd:string" xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"> John B. Good </nameToLookup> </ns1:getAddressFromName> </SOAP-ENV:Body> </SOAP-ENV:Envelope>
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance" xmlns:xsd="http://www.w3.org/1999/XMLSchema"> <SOAP-ENV:Body> <ns1:getAddressFromNameResponse xmlns:ns1="urn:www-oracle-com:AddressBook" SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"> <return xmlns:ns2="urn:xml-soap-address-demo" xsi:type="ns2:address"> <city xsi:type="xsd:string">Anytown </city> <state xsi:type="xsd:string">NY </state> <phoneNumber xsi:type="ns2:phone"> <areaCode xsi:type="xsd:int">123 </areaCode> <number xsi:type="xsd:string">7890 </number> <exchange xsi:type="xsd:string">456 </exchange> </phoneNumber> <streetName xsi:type="xsd:string">Main Street </streetName> <zip xsi:type="xsd:int">12345</zip> <streetNum xsi:type="xsd:int">123 </streetNum> </return> </ns1:getAddressFromNameResponse> </SOAP-ENV:Body> </SOAP-ENV:Envelope>
Why do we need a standard like SOAP? By exchanging XML documents over HTTP, two programs can exchange rich, structured information without the introduction of an additional standard such as SOAP to explicitly describe a message envelope format and a way to encode structured content.
SOAP provides a standard so that developers do not have to invent a custom XML message format for every service they want to make available. Given the signature of the service method to be invoked, the SOAP specification prescribes an unambiguous XML message format. Any developer familiar with the SOAP specification, working in any programming language, can formulate a correct SOAP XML request for a particular service and understand the response from the service by obtaining the following service details.
Using SOAP streamlines the process for exposing an existing software component as a Web service since the method signature of the service identifies the XML document structure used for both the request and the response.
Oracle SOAP is an implementation of the Simple Object Access Protocol. Oracle SOAP is based on the SOAP open source implementation developed by the Apache Software Foundation.
This section describes the Oracle SOAP components shown in Figure 1-2. The topics covered include:
A SOAP client application represents a user-written application that makes SOAP requests. A SOAP client application may include the following:
SOAP clients generate the XML documents that compose a request for a SOAP service and handle the SOAP response. Oracle SOAP processes requests from any client that sends a valid SOAP request. To facilitate client development, Oracle SOAP includes a SOAP client API that provides a generic way to invoke a SOAP service. The SOAP client API supports a synchronous invocation model for requests and responses.
The SOAP client API makes it easier for you to write a Java client application to make a SOAP request. The SOAP client API encapsulates the creation of the SOAP request and the details of sending the request over the underlying transport protocol. The SOAP client API also supports a pluggable transport, allowing the client to easily change the transport (available transports include HTTP and HTTPS).
Oracle SOAP uses the security capabilities in the transport to support secure access and to support other security features. For example, using HTTPS, Oracle SOAP provides confidentiality, authentication, and integrity over the Secure Sockets Layer (SSL). Other security features such as logging and authorization, are provided by the service provider.
SOAP transports are the protocols that carry SOAP messages. Oracle SOAP supports the following transports:
SOAP administrative clients include the Service Manager and the Provider Manager. These administrative clients are services that support dynamic deployment of new services and new providers.
The SOAP Request Handler is a Java servlet that receives SOAP requests, looks up the appropriate service provider, handles the service provider that invokes the requested method (service), and returns the SOAP response, if any.
Oracle SOAP includes a provider implementation for Java classes. Other providers can be added.
The provider interface allows the SOAP server to uniformly invoke service methods regardless of the type of provider (Java class, stored procedure, or some other provider type). There is one provider interface implementation for each type of service provider, and it encapsulates all provider-specific information. The provider interface makes SOAP implementation easily extensible to support new types of service providers.
Oracle SOAP provides the provider deployment administration client to manage provider deployment information.
SOAP application developers provide SOAP services. These services are made available using the supplied default Java class provider or custom providers. Oracle SOAP includes a service deployment administration client that runs as a service to manage services.
SOAP services, including Java services, represent user-written applications that are provided to remote SOAP clients.