As noted on the previous page, services on remote servers communicate with the Portal via HTTP and SOAP. HTTP and SOAP are both necessary because each standard fits the specific needs of different tasks. The sections below provide more detail:
HTTP Basics: HTTP is a lightweight protocol, used in the portal for UI presentation, basic configuration and click-through, and caching.
CSP: CSP is a platform-independent protocol based on HTTP that defines the syntax of communication between the Portal and remote servers.
SOAP Basics: SOAP involves posting and returning XML documents and is appropriate for exchanging highly structured data. SOAP is used in the server-to-server communication required for content services, identity services, and importing documents.
HTTP is a protocol used mostly for transferring Web page content and XML between a server and a client. HTTP communication is made up of Requests and Responses. Requests and Responses are essentially lists of name-value pairs of metadata (in headers), along with an optional body. The body is the data that is being transferred (i.e., an HTML page or XML file). The metadata in the headers is information about the Request or Response itself (e.g., what language the content is in, or how long the browser should cache it). The Request and Response each contain specific information, outlined next. For more detailed information on HTTP, see RFC 2616 (http://www.faqs.org/rfcs/rfc2616.html).
The client sends the server an HTTP Request, asking for content. The Request body is used only for requests that transfer data to the server, such as POST and PUT.
HTTP Request Format:
[METHOD]
[REQUEST-URI] HTTP/[VERSION]
[fieldname1]: [field-value1]
[fieldname2]: [field-value2]
[request body, if any]
HTTP Request Sample:
GET
/index.html HTTP/1.1
Host: www.plumtree.com
User-Agent: Mozilla/3.0 (compatible; Opera/3.0; Windows 95/NT4)
Accept: */*
Cookie: username=JoeSmith
The server sends back an HTTP Response that contains page content and important details, such as the content type, when the document was last modified, and the server type. The Response contains an error message if the requested content is not found.
HTTP Response Format:
HTTP/[VERSION]
[CODE] [TEXT]
[fieldname1]: [field-value1]
[fieldname2]: [field-value2]
[response body, if any (document content here)]
HTTP Response Sample:
HTTP/1.0
200 Found
Last-modified: Thursday, 20-Nov-97 10:44:53
Content-length: 6372
Content-type: text/html
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final// EN"><HTML>
...followed by document content...
Custom HTTP headers can be configured to include specialized information. The CSP extends HTTP and uses proprietary headers to pass settings between the Portal and remote server, detailed next.
Note: Header size limits are controlled by the server that hosts the code. The standard limit for IIS/ASP is 60K. Java Application Servers range from 2K to 10K. These limits are generally configurable; see your server documentation for details.
Services can also access standard HTTP headers, such as the Set-Cookie header or HTTP 1.1 basic authentication header. If you want to investigate HTTP further, you can view all the headers being passed back and forth between your browser and Web server using a tunnel tool. HTTP is used in conjunction with SSL to serve up secure content. Single Sign-On (SSO) also uses HTTP headers for basic authentication.
CSP is a platform-independent protocol that is based on the open standard of HTTP 1.1. The syntax of communication between the Portal and remote servers is defined by CSP. CSP defines custom headers and outlines how ALI services use HTTP to communicate and modify settings.
The current version is CSP 1.3, which includes backward compatibility with previous versions. CSP 1.2 is used in portal version 5.x. CSP 1.1 is used in portal version 4.5. Versions 4.x and below use CSP 1.0. You can download all versions of the protocol specification from the ALUI Developer Center on dev2dev.
The AquaLogic Interaction Development Kit (IDK), formerly the EDK, provides simplified, stable interfaces that allow you to write code that communicates using CSP. The Programmable Remote Client included with the IDK provides additional access to portal objects that are not available using CSP.
SOAP is a text-based protocol to wrap XML data for any type of transport, providing an efficient way to communicate structured data. The SOAP 1.1 specification describes SOAP:
SOAP is a lightweight protocol for exchange of information in a decentralized, distributed environment. It is an XML based protocol that consists of three parts: an envelope that defines a framework for describing what is in a message and how to process it, a set of encoding rules for expressing instances of application-defined datatypes, and a convention for representing remote procedure calls and responses.
SOAP is based on Web standards. Like HTML, SOAP uses tags to indicate the role of each piece of information. In most implementations, SOAP uses HTTP for its transport protocol. A SOAP request is an XML document that describes a method to invoke on a remote machine and any parameters to be used. A program sends a SOAP request to a SOAP server. The SOAP server tries to execute the method with the parameters it was passed, and it sends back a SOAP response (the result or an error message). A SOAP endpoint is an HTTP-based URL identifying a target for method invocation.
A common analogy illustrates this concept well. If your XML code was a letter, SOAP would be the envelope; like an envelope, SOAP protects content from unauthorized access and provides information about the sender and the addressee. All the elements of the SOAP envelope are defined by a schema. The schema URI is also the identifier for the SOAP envelope namespace: http://schema.xmlsoap.org/soap/envelope.
As in standard XML, SOAP uses namespaces to segregate content. The formal designation of a namespace is a URI, usually a URL. Namespaces ensure unique element references, and they allow a processor to pick out which instructions it should obey and treat instructions for other processors as simple data. Processors are set up to handle elements from a particular namespace. Elements that have no namespace are treated as data.
SOAP Message in HTTP Request:
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>DIS</symbol>
</m:GetLastTradePrice>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
SOAP Message in HTTP Response:
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>
You can download the complete SOAP 1.1 specification from the World Wide Web Consortium at http://www.w3c.org/TR/SOAP/.
ALI’s SOAP API exposes commonly used elements of the traditional portal API, focused on the functions required to develop applications that access portal users, Communities, Portlets, and Knowledge Directory functions. The Programmable Remote Client (PRC) provides an efficient, object-oriented way to call into the portal’s SOAP API.