AquaLogic User Interaction Development Guide

     Previous Next  Open TOC in new window   View as PDF - New Window  Get Adobe Reader - New Window
Content starts here

About Server Communication and the Gateway

ALI and 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 My 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 ALI services use HTTP to communicate and modify settings. For details on CSP, see About HTTP and CSP.

The Gateway

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 ALI 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 ALI services are:


  • Dynamic functionality and personalization: The portal intercepts requests from portlets, which allows it to include information stored in the ALI database in HTTP requests and responses. Most of this information is accessible through IDK methods. In many situations, an adaptive tag provides the functionality you need, including navigation and login elements. Custom tags can be created for additional functionality.
  • Security: Services can allow users to access content that is not publicly available. Files stored on a secure server can be made available by including specific URLs in the configuration of the gateway. NOTE: The gateway is a powerful feature, and can compromise security if incorrectly configured. Allowing direct access to a remote server that hosts unprotected private content could create a dangerous security hole.
  • Performance: The portal caches gatewayed content, decreasing response time for end users and improving performance on the remote server. While gatewaying works efficiently for content like HTML, it is generally not appropriate for binary data like static images. Images do not need to be transformed, and gatewaying large images can adversely affect the performance of the portal. This is one reason the Image Service should be used to prevent routing static images through the gateway.

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:


  • URL transformation: The portal must transform code so that gatewayed URLs open correctly. Before the portal sends a response, it parses the HTML and looks for any URLs included in the Gateway URL Prefixes list for the associated Web Service object. The portal transforms any URLs that should be gatewayed before returning the response to the client. Relative URLs are transformed to point to the correct location.
  • Scripting limitations: JavaScript constructs that dynamically create URLs can cause problems, because they are run after content is already transformed. VBScript is not transformed by the gateway; you can continue to use dynamic scripts and VBScript as long as your code is gateway-aware. To manually mark a URL for transformation, use the pt:url tag. To disable transformation, use pt:transformer with a pt:fixurl attribute of 'off.' For details, see Transforming URLs Using Adaptive Tags.
  • URL encoding: It is a best practice to encode all headers that are URLs to prevent unexpected transformation. In JSP, encode all URLs that are written. If the code writes URLs in the body of a page (for example, a link to a preferences page) it should be encoded. The standard Java servlet command response.encodeURL() is the preferred method, but you can also use URLEncoder.encode(url). In the .NET Framework, the HttpUtility.URLEncode class provides the necessary functionality. Note: In .NET, there is no need to encode the redirect URL; this is handled automatically on the back end.
For details on pagelets and the gateway, see About Pagelets and the Gateway.

  Back to Top      Previous Next