Oracle WebCenter Interaction and Oracle WebCenter Ensemble both act as a gateway server, brokering transactions between client computers and remote servers.
Services on remote servers communicate with the portal via HTTP and SOAP as shown in the simplified diagram below. For example, when a browser requests a My Page from the portal, the portal makes simultaneous requests to each remote server to retrieve the portlet content for the page. The remote server reads the current user's preferences from the HTTP headers sent by the portal and sends back the appropriate HTML. The portal inserts the HTML into the table that makes up the page. Any images stored in the Image Service are retrieved and displayed by the browser.
HTTP and SOAP are both necessary because each standard fits the specific needs of different tasks. 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 much more lightweight protocol, used in the portal for UI presentation, basic configuration and click-through, and caching. For an introduction to SOAP, see About SOAP.
CSP is a platform-independent protocol 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 portal services use HTTP to communicate and modify settings. For details on CSP, see About HTTP and CSP.
A 'gateway server' acts as a middleman, brokering transactions between a client computer and another server. This configuration is typically used to serve content to clients that would otherwise be unable to access the remote server, but it can be used to impose additional security restrictions on the client. The gateway hides the remote server; to the end user, the content appears to come directly from the gateway server.
This architecture makes the portal the single point of access for content, and allows remote servers to reside on a private network or behind a firewall. As long as the portal can connect to the remote server, users can view the content, even if they cannot access it directly. To the browser, the portal appears to be the source of content on the remote server.
When a user interacts with a portal service, any request made to a URL in the gateway is automatically rerouted through the portal. To the user, the content appears to come from the portal; the remote server is an unknown back-end system.
There are many benefits to this configuration. The most useful to portal services are:
The collection of URLs that should be gatewayed for a service is configured in the Web Service editor on the HTTP Configuration page. In the Gateway URL Prefixes list, you must enter the base URLs for any directories that should be gatewayed.
Keep the following warnings and best practices in mind when implementing services that use the gateway: