Several Hybrid Runtime patterns may be utilized in a mixed Domino and WebSphere Application Server environment. There are two common application types that emerge when analyzing Application Integration patterns associated with these products. The first is based on the premise that a pre-existing Domino application requires an interface to WebSphere Application Server to support J2EE functionality, or interfaces to other back-end systems through software components provided in the WebSphere Application Server environment. An application of this nature may be described as being "collaboration-centric."

The second typical application type involves an existing J2EE-based application that lives in the WebSphere Application Server realm, requiring access to one or more back-end Domino and relational databases. An example of this scenario may include a J2EE application that presents the contents of a view in a Domino database. Applications architected in this fashion are typically associated with more robust transaction-based processing, or "transaction-centric" systems, which may include some collaborative components, such as real-time chat interfaces with customer support personnel.

While Lotus Domino on it's own may be utilized as a transaction-centric system, such as an e-commerce Web site, there are limiting factors in the product itself that might restrict its scalability and flexibility. One of these limiting factors is the lack of a robust transaction processing model in Lotus Domino itself. Typical transaction-centric systems must interface with one or more back-end systems to complete a given transaction initiated by an end-user. Enterprise Java Beans (EJBs) in J2EE systems inherently provide robust and scalable transaction processing mechanisms that manage concurrent data access and provide data consistency among multiple systems, even in the presence of failures. By itself, Lotus Domino does not include the robust and scalable transaction processing mechanisms that are required in medium to large transaction-centric Web sites.

Similarly, while components can be built onto the WebSphere Application Server to address the needs of a collaborative workspace, Lotus Domino and other Lotus Software products provide this capability out-of-the-box.

For each of the Hybrid runtime patterns below, the following information is provided:

• Situations in which the described pattern should be utilized.
• The typical Business patterns that might apply to the described Hybrid Runtime pattern, such as Self-Service, Collaboration or Information Aggregation. In some cases, the extent of either application or access integration that is found in the pattern is described, which may include specific access integration technologies that enable Lotus Domino to work with WebSphere Application Server.
• Benefits and limitations found in the use of the pattern.

As mentioned previously, the patterns described in this section are Hybrid Runtime patterns, in part because of their tie to specific IBM software products. Some diagrams that follow, however, contain generic node names rather than actual product names for the sake of simplicity, or to emphasize the fact that products are indeed interchangeable in specific logical nodes. In some cases, if a generic node name is provided, there may be multiple actual products available to serve the functionality required. The following list describes typical products that may map to generic node names presented on included diagrams, when generic node names are provided.

• HTTP server/Web server
  • IBM HTTP Server
  • Lotus Domino HTTP Server
  • Microsoft Internet Information Server (IIS)
  • Other Web servers supported by the WebSphere HTTP plug-in technology
• Web application server
  • IBM WebSphere Application Server
• Collaboration server
  • IBM Lotus Domino
  • IBM Lotus Sametime for real-time collaboration
• Database
  • IBM DB2
• Directory
  • IBM Directory Server
  • Lotus Domino
• Firewall
  • IBM Tivoli Firewall
  • Cisco PIX Firewall

Both the firewall and directory server have been included in some Runtime pattern figures. This does not imply that every situation will require a firewall or a separate directory server. The Runtime pattern diagrams illustrate best practices if your project requires a firewall or a separate directory server.

Select the hybrid Runtime pattern that best meets the needs of your e-business solution:

Domino app with WebSphere Application Server services: Single server (3.3)

Design Last Updated: 6-13-2003
(Click a node to get a detailed explanation.)

This Runtime pattern is easily deployed, and fairly common in situations where WebSphere Application Server is being implemented for the first time within a Lotus Domino-based organization. The capabilities of WebSphere Application Server might be required to provide some increased measure of scalability by replacing the native servlet engine found in Lotus Domino with the more scalable and robust engine available in WebSphere Application Server.

While this pattern enables the use of more advanced features in J2EE, including Enterprise JavaBeans (EJBs), in most cases the use of EJBs would point to a more advanced system architecture with higher levels of availability that would indicate moving Domino and WebSphere Application Server to different physical nodes.

User authentication in this pattern would be performed by the Lotus Domino Directory.

Note that currently the HTTP plug-in for the Lotus Domino 6 HTTP server is only available for use with Microsoft IIS and IBM HTTP Server (AIX). Other Web servers will likely to be supported in upcoming maintenance releases of Lotus Domino.

The most important nodes in the above diagram include:

• The Client accesses the Lotus Domino HTTP server through a Protocol Firewall, which is intended to allow HTTP (port 80) access, but block all other ports.
• Lotus Domino and WebSphere Application Server are contained on a single physical server.
• Lotus Domino is serving as the user directory in this pattern, with no additional hardware components required.

Applicable Business patterns

The four patterns in action within this Hybrid Runtime pattern are:

• Self-Service: This topology represents a pattern where users are interacting with a Web-based business system.
• Collaboration: The collaborative functions of the Lotus Domino server are used for user-to-user interaction.
• Application Integration: We can see application integration between Lotus Domino and WebSphere to provide integration between the two servers. In this topology, the integration would typically be done by accessing the other servers' classes directly through shared resources.
• Access Integration: Access Integration can be seen between the HTTP task in Domino and both the Domino server engine and the WebSphere server. This access integration exists due to the HTTP task, which is used by both servers (Domino and WebSphere Application Server).

Lotus Domino and WebSphere Application Server integration with this Runtime pattern will usually be achieved by taking advantage of shared resources, for example, calling a Java bean directly from a Domino agent inside a Domino Database. Conversely, since the Domino database and WebSphere Application Server are contained within the same physical node, a Java bean could directly manipulate the contents of a Domino database in the Domino server through local Domino Objects for Java classes, instead of remote classes that require the use of IIOP.

If it is known, however, that the future of the application will include the physical separation of Lotus Domino from WebSphere Application Server, it is advised to use remote access (IIOP) with Domino for Java Objects to simplify the work required in breaking apart these application servers.

Guidelines for use

This Runtime pattern is appropriate in situations where the transactional, functional or scalability requirements are not enormous, and are easily contained within the bounds of a single server. In other words, this pattern is appropriate for collaboration-centric Web sites, especially in intranet applications, or in relatively simple, limited transaction-based systems that are built upon the Domino platform. This pattern might also be useful in test situations.

Examples of such sites might be:

• A company Web site where the majority of content resides within Domino databases, some selected functionality is provided by WebSphere, but only a relatively small number of users per day need that functionality.
• Web sites where Domino is the preferred deployment platform, without extensive requirements for transaction processing.
• Sites where the main focus is user collaboration, either with staff or with other users. For example, WebSphere may be used to control a host session via WebSphere Host Publisher.

In all of these example sites, the common thread is that WebSphere has a relatively minor part to play in the functionality of the site, providing ancillary services to a primary Domino application, such as servlet or JSP containment. This Runtime pattern is also well suited to test environments.

Benefits and limitations

The key benefits of this pattern include simple configuration and maintenance, as well as low hardware costs.

However, since there is no physical separation between Domino and WebSphere Application Server, this pattern does not scale well. It does provide a good starting point for implementations, however, if access interfaces are considered that allow for remote access versus those that rely exclusively on local access (such as local Domino Objects for Java).

Domino app with WebSphere Application Server services: Multiple servers (3.4)

Design Last Updated: 6-13-2003
(Click a node to get a detailed explanation.)

This Runtime pattern is a logical extension of the previous Domino app with WebSphere Application Server services: Single server pattern. It presumes the use of a Domino server for all client intervention through Domino's own HTTP server, but separates the WebSphere Application Server onto a separate physical node, in this case behind the domain firewall, allowing for improved performance and scalability.

The most important nodes in the diagram above include:

• The Client accesses the Lotus Domino HTTP server through a Protocol Firewall, which is intended to allow traffic through port 80 (HTTP) or 443 (HTTPS). All other ports are blocked.
• Lotus Domino's HTTP server is used exclusively to provide content to the client. The HTTP plug-in is utilized to redirect all servlet requests to the WebSphere Application Server.
• The Domain Firewall restricts access to the internal network to calls originating in the DMZ only; other traffic is blocked.
• The WebSphere Application Server is contained exclusively behind the Domain Firewall, providing an extra measure of security.
• Lotus Domino is providing all user directory services. WebSphere Application Server accesses the directory services through LDAP.

Applicable Business patterns

The patterns in action within this topology are:

• Self-Service: The whole Runtime pattern represents a situation where users are interacting with a Web-based business system. This business system may consist of Domino components, but the addition of WebSphere Application Server opens up access to other enterprise-wide systems that may be accessed through EJBs in JSPs or servlets.
• Collaboration: The collaborative functions of the Domino server are used for user-to-user interaction.
• Application Integration: Domino and WebSphere are integrated solutions in this pattern. Application Integration between these products may be achieved through servlet redirection from Lotus Domino to WebSphere Application Server through the use of the IBM WebSphere HTTP plug-in.
• Access Integration: Access Integration can be seen between the HTTP task in Domino and both the Domino server engine and the WebSphere Application Server. This access integration exists due to the HTTP task, which is responsible for the presentation of both servers (Domino and WebSphere Application Server).

There are a number of options for application integration between Domino and WebSphere, as described in detail in Section 3.3, "WebSphere-Domino interface methods" of the IBM Redbook, Patterns: Custom Designs for Domino & WebSphere Integration.

From the perspective of Domino Server to WebSphere Application Server integration, the two products can be configured through the Domino Administrator, setting up the Domino HTTP task to utilize a third-party servlet engine (WebSphere Application Server) instead of it's own servlet engine.

Guidelines for use

This Runtime pattern is common in sites that provide more than just a single application or system to the Web users. It is also relevant when:

• Domino is the preferred application environment historically.
• The application requires more than trivial use of Domino's features, like Workflow, Collaboration, Mail and Calendar integration, and so on.
• Internal users create Web content from a Notes client which may have workflow associated with it.
• The site is collaboration-centric rather than transaction-centric.

In this Runtime pattern, the Domino server will authenticate users if required.

Benefits and limitations

The benefits of this Runtime pattern are:

• It scales well, both horizontally and vertically.
• It can provide increased security, since you are able to put WebSphere behind a firewall in the internal network rather than keep it within the DMZ.
• It is relatively simple to implement since it does not require special coding: it is configured, not coded.

When using Lotus Domino Release 5.x, one of the limitations of this Runtime pattern is that the only HTTP server that can used in the environment is the Domino HTTP task or MS IIS, but only on the same physical server. This serious limitation introduced horizontal scalability issues at high usage at the Web server logical node.

Lotus Domino Release 6.0 eliminates this restriction in two ways. First, the HTTP Server was re-written, and is much more scalable than prior releases. Second, a new Domino HTTP plug-In architecture was introduced that allows alternative HTTP servers to be used instead of the Domino HTTP server. This plug-in uses the same architecture as the HTTP plug-in for WebSphere Application Server. This mechanism allows the HTTP server to be physically separated from the Domino Application Server.

Web redirector with Domino and WebSphere Application Server (3.5)

Design Last Updated: 6-13-2003
(Click a node to get a detailed explanation.)

This Runtime pattern takes advantage of the WebSphere HTTP plug-in, which allows Lotus Domino and WebSphere Application Server to be physically separated from a Web server that is providing HTTP access to system information. This feature allows a Web server to exist by itself in the DMZ of a typical topology, and allows the Domino server to be placed behind the domain firewall, where other application servers, such as WebSphere Application Server, would typically reside.

This is the first pattern described that utilizes the WebSphere HTTP plug-in technology, allowing the Web server to be physically separated from an application server.

User authentication using this pattern is provided through the Lotus Domino Directory. Note: Lotus Domino includes robust security features that do a superb job of protecting Domino databases, even when they are placed in the DMZ and not behind a domain firewall, as long as Domino and all associated databases are configured properly through server security settings and database Access Control List (ACL) settings. While one benefit of the Domino HTTP plug-in architecture is in the elimination of Denial of Service (DOS) attacks directly on the Domino server, the primary benefits are in the areas of scalability and flexibility in the choice of HTTP servers utilized in an environment.

The most important nodes in the diagram above include:

• The Client accesses the Lotus Domino HTTP server through a Protocol Firewall, which is intended to allow only traffic through port 80 (HTTP) or 443 (HTTPS). All other ports are blocked.
• The only server in the DMZ is the Web server, which acts as a Web server redirector, directing incoming requests to either locally stored, static HTML pages, or to other Web servers based on the composition of the URL. The WebSphere HTTP plug-in is utilized on the Web server to perform this redirection task.
• The Domain Firewall restricts access to the internal network to calls originating in the DMZ; other traffic is blocked.
• The WebSphere Application Server is contained exclusively behind the Domain Firewall, providing an extra measure of security by allowing only traffic originating in the DMZ to reach the internal network.
• The Lotus Domino Server is contained behind the Domain Firewall, providing consistency with other application servers in this environment, such as WebSphere.

Applicable Business patterns

The patterns in action within this topology are:

• Self-Service: In this pattern users interact with a Web-based business system. This business system may consist of Lotus Domino components, but the addition of WebSphere Application Server opens up access to other enterprise-wide systems that may be accessed through EJBs in JSPs or servlets. Potentially, Lotus Domino may also be utilized to access other enterprise-wide systems, through Lotus Domino technologies such as Lotus Enterprise Integrator™.
• Collaboration: The collaborative functions of either Lotus Domino, or other Lotus or WebSphere Application Server collaborative products, apply to this pattern.
• Application Integration: Lotus Domino and WebSphere are integrated in this pattern. The HTTP server (IBM HTTP Server, for instance) is also integrated through the Domino HTTP plug-in to work with both the WebSphere Application Server and Domino Application Server behind the domain firewall.
• Access Integration: This is provided through the Web redirector, controlling access to one or more back-end systems through a common front-end server.

Guidelines for use

This pattern should be utilized in an environment that requires horizontal scalability at the HTTP server and application server level, in conjunction with protected data resources behind the domain firewall.

While this pattern specifies the use of the Lotus Domino Directory for user authentication, an alternative LDAP-based directory may also be introduced to handle this task, integrated with Lotus Domino, WebSphere Application Server and the Web server being used.

Benefits and limitations

The benefits of this Runtime pattern are:

• A consistent architecture that places all persistent data nodes used in the system behind the domain firewall, including the Lotus Domino server and its associated databases.
• An elimination of Denial of Service attacks from the external network directly to the Lotus Domino server (by placing the Domino server behind the domain firewall).
• As additional HTTP plug-ins are provided with future releases of Lotus Domino and WebSphere Application Server, the ability to "plug in" additional Web servers will be provided.
• This plug-in architecture supports an added benefit of load-balancing. Requests can be redirected in a round-robin fashion, for example, to multiple, cloned application servers in a "group," more evenly distributing load to multiple servers. Other patterns in this chapter do not include any form of load-balancing or fail-over mechanisms inherent in the pattern itself.

One limitation of this pattern is the availability of WebSphere HTTP plug-ins for specific Web server and operating system platform combinations, and the additional cost associated with purchasing and maintaining a separate physical Web server.

A complete explanation of the powerful WebSphere HTTP plug-in technology is beyond the scope of this Web site. For more detailed information, refer to the IBM Redbook, IBM WebSphere V4.0 Advanced Edition Scalability and Availability or the "Web server plug-ins" section of the WebSphere Application Server V5.0 InfoCenter on the Web.

WebSphere Application Server application with Domino services (3.6)

Design Last Updated: 6-13-2003
(Click a node to get a detailed explanation.)

Web sites that are primarily transaction-centric will typically utilize this pattern. Domino services may be provided to support a back-end calendaring system, electronic mail, or custom Domino databases, such as discussion groups or workflow-oriented databases.

Specifically, the pattern described here might be fairly rare, as a transaction-centric application utilizing WebSphere Application Server would also typically include a relational database component, such as IBM DB2, and not just Lotus Domino, which would provide only a subset of services. However, for the sake of simplification, and due to the focus on Domino-WebSphere integration, additional potential nodes have not been included.

From the perspective of user authentication, the most effective solution would be the inclusion of IBM Single Sign-On in this pattern, using either Lotus Domino's directory or an alternative, compatible LDAP solution, such as IBM Directory Server. For more information, see the "Utilizing IBM single sign-on" section of the IBM Redbook Patterns: Custom Designs for Domino & WebSphere Integration. For the sake of discussion, the diagram above includes a separate logical node for the Directory Server.

The most important nodes in this diagram include:

• The Client accesses the WebSphere Application Server through a Protocol Firewall, which allows access only through port 80 (HTTP) or 443 (HTTPS). All other ports are blocked.
• Components executing in WebSphere Application Server, including JSPs, JavaBeans, or EJBs, may access Lotus Domino database resources remotely, through either Domino for Java Objects (local or remote) or Domino Collaboration Objects.
• The Domain Firewall restricts access to the internal network to calls originating in the DMZ; other traffic is blocked.
• A Directory Server is introduced, protected behind the Domain Firewall, to provide user authentication. This server may be Lotus Domino, or an alternative directory server, such as IBM Directory Server.

Applicable Business patterns

The patterns that form this Runtime pattern may include:

• Self-Service: WebSphere Application Server is providing the entire user interface to the business in this Runtime pattern.
• Application Integration: Lotus Domino and WebSphere Application Server are integrated through one or more of the interfacing mechanisms described in the "WebSphere-Domino interface methods" of Patterns: Custom Designs for Domino & WebSphere Integration. Most typically the Domino Objects for Java interface method will be utilized to access Domino from WebSphere Application Server components when this pattern is used.

Guidelines for use

This Hybrid Runtime pattern is best used in traditional transaction-centric sites that may, out of necessity, include one or more collaborative components.

Multiple methods that can be used to establish connections between WebSphere Application Server and Lotus.

Benefits and limitations

The key benefits of this Runtime pattern are:

• Security: It enables the Domino server to reside behind the firewall in the internal network with the other data sources. In that way, all of the sensitive data is stored internally, not in the DMZ.
• Scalability: WebSphere is able to provide a consistent view and speed because it can be scaled to improve performance and fault-tolerance as required by incorporating the WebSphere Edge Server.

One of the limitations of this pattern is the lack of a dedicated HTTP server in the DMZ.

WebSphere Web services with Domino (3.7)

Design Last Updated: 6-13-2003
(Click a node to get a detailed explanation.)

This scenario depicts a Hybrid Runtime pattern that will likely become more prevalent as Web services mature and their use becomes more widespread. This pattern assumes the use of WebSphere Application Server as a provider of Web services. Due to the nature of Web services, however, it is easy to imagine a Lotus Domino server providing this same functionality, simply swapping Lotus Domino and WebSphere Application Server in the diagram above. The Web service Provider, in this pattern, also serves the purpose of information aggregator, pulling information from Lotus Domino databases in conjunction with IBM DB2 relational databases through one or more published Web services.

Important notes about this figure:

• The Client node in this figure is the Web service Consumer, accessing the provider through the Internet.
• The Web service Provider, in this pattern example, is IBM WebSphere Application Server.
• The service provider has published information about available Web services to a UDDI Directory.
• This implementation of Web services uses HTTP as the transport protocol.
• The SOAP client represents additional functionality required to encode and decode SOAP messages used in Web services.

Applicable Business patterns

As indicated in the figure above, the Business patterns that are applicable to this Runtime pattern include:

• Self-Service: Web services may be deployed that allow end-users to reach into back-end business systems.
• Collaboration: The Web services provided by the Lotus Domino server may center around collaborative capabilities found natively in Lotus Domino, including workflow processes, shared calendaring and scheduling, and messaging, that may be triggered or controlled by external events through a Web service interface.
• Application Integration: Lotus Domino and WebSphere Application Server work together in this pattern. WebSphere Application Server integrates with Lotus Domino, as well as, potentially, other data stores.

Guidelines for use

This pattern may be the best choice in environments in which:

• Multiple application server platforms exist (including Microsoft .Net, J2EE platforms such as IBM WebSphere Application Server and Lotus Domino), in which the single common interoperability layer may be the use of standard, published Web services.
• Supply chain integration is required with other vendors through the Internet (extended enterprise).
• Internet-based clients (end users) require access to information through a standard Web services interface.

Benefits and limitations

The key benefit of this Runtime pattern is the use of standards-based Web services, allowing platform and implementation independence and interoperability between disparate systems. In the pattern described, a Web service is provided directly from the WebSphere Application Server. However, this same service may be expanded to include extended enterprise access (supply chain or business partner integration).

While there are many benefits to the use of Web services, in some situations, Web services may be less than advantageous for performance or other reasons. For example:

• In many manufacturing environments, Electronic Data Interchange (EDI) is already used by suppliers to communicate information from one organization to another. Adding a Web services layer to a legacy EDI system would require the added complexity of serializing, then deserializing, each EDI transaction simply for the sake of utilizing Web services. This process would result in performance inefficiencies and added complexity.
• Binary data, such as images (JPEG, for instance), would also require the same serialization and deserialization of messages. Images are typically already highly optimized and compressed for transmission; encapsulating binary information into XML would be slow and inefficient. Three potential, emerging standards in dealing with binary data in XML include SOAP Messages with Attachments (SwA), Direct Internet Message Encapsulation (DIME) and Blocks Extensible Exchange Protocol (BEEP).
• Some existing legacy systems may not be Web services-compliant, and may never be.

Due to the relative immaturity of Web services, another potential limitation of this pattern lies in the lack of widely supported and standardized security mechanisms tied to Web services. IBM, Microsoft, VeriSign and other organizations are attempting to ratify security mechanisms, known as Web Services Security (WS-Security). Visit the WS-Security Web site for more information related to this new standards effort.

As Web services and related standards evolve, best practices to handle many of these shortcomings will likely emerge.

Enterprises typically have many different directories, meaning administrators have difficulty maintaining them and end users need to remember multiple logins. As a result, many organizations are looking to consolidate a variety of directories and sources of people information into one Enterprise directory. This effort is greatly aided by the widespread support for the Lightweight Directory Access Protocol (LDAP) standard by the software industry.

A further requirement is to then allow single sign-on, where a user logs on to one application and is then authenticated against many other applications that trust the initial logon. While these requirements appear to be similar, they are actually quite different. Both are discussed here.

A common source for people-related information is directories from applications with messaging and collaboration features, the most popular of which are Lotus Domino and Microsoft Exchange.

Lotus Domino's directory has been LDAP-compatible since release 5, and provides several features for consolidating and authenticating against other Domino and LDAP directories. Microsoft Exchange relies on the Windows NT4 domain in Exchange 5.5 and Active Directory on Windows 2000 for Exchange 2000. Active Directory is LDAP-compatible. See IBM Redbook Using LDAP for Directory Integration (SG24-6163) for more information on LDAP.

The many permutations of directory-related patterns with Domino 6 and WebSphere 5 are not fully covered here. However, the most common instances have been selected for discussion, including:

• Using an external LDAP directory for user information and authentication (4.1)
• Using both Active Directory and Domino Directory (4.2)
• Using both an external LDAP directory and Domino Directory (4.3)
• Using a security server to manage authentication and connections (4.4)

Using an external directory for user information and authentication (4.1)

Design Last Updated: 6-13-2003
(Click a node to get a detailed explanation.)

Many organizations do not want the administrative overhead of maintaining more than one directory for user information and authentication. Using an external directory for these tasks is a way to get around this issue, as illustrated in the diagram above.

This pattern is a simple solution to this problem, one that doesn't require third party software (except the directory itself) and is easy to set up. However, it is only applicable to specific scenarios.

Note that all the patterns here assume that Domino is using the HTTP plug-in architecture discussed in chapter 3 of the IBM Redbook Patterns: Custom Designs for Domino & WebSphere Integration. This provides the best security by avoiding having any data in the DMZ.

Applicable Business patterns

The four patterns which form this topology are:

• Self-Service: One of the user's interactions with the environment is logically with WebSphere applications. That interaction represents the Self-Service pattern.
• Collaboration: One of the user's interactions is logically with Domino collaborative applications. That interaction represents the Collaboration pattern.
• Access Integration: Clearly, when both application servers are sharing a directory for authentication purposes, the directory is providing security integration which is a subset of access integration.
• Application Integration: The directory, as well as acting as an access integrator, allows both Domino and WebSphere Application server to use the directory as storage for people or resource-related information, and in this case it fits the Application Integration pattern. We have included this pattern here, not because it is essential in this Runtime pattern, but because it is a possibility.

Guidelines for use

This pattern is only applicable if the Domino Directory is not required to store people information and, therefore, can only be used for browser-based applications. This is because Domino must have a populated directory so that it knows where to send mail to relevant people for mail routing and delivery to work.

It relies on a feature called Directory Assistance in Domino that allows for the referral of authentication requests to other Domino or LDAP directories. WebSphere Application Server fully supports using just an LDAP directory out of the box; therefore, no major changes to WebSphere Application Server deployment are required in this pattern.

Benefits and limitations

This pattern greatly simplifies deployment of WebSphere Application Server and Domino for organizations that only want to maintain one non-Domino enterprise Directory. However, it is only of use to organizations that do not use Domino for e-mail and mail routing.

Using both Active Directory and Domino Directory (4.2)

Design Last Updated: 6-13-2003
(Click a node to get a detailed explanation.)

This pattern is most applicable for organizations that want to maintain a central Microsoft Active Directory to store user and resource information and for authentication, but still need to use Domino for e-mail.

Applicable Business patterns

The four patterns which form this topology are:

• Self-Service: One of the user's interactions with the environment is logically with WebSphere applications. That interaction represents the Self-Service pattern.
• Collaboration: One of the user's interactions is logically with Domino collaborative applications. That interaction represents the Collaboration pattern.
• Access Integration: As authentication is still against a single directory (Active Directory), this is also an Access Integration pattern.
• Application Integration: In this pattern, Domino synchronizes its user data with Active Directory using ADSync. Users authenticate against different directories according to the application they are using, but have the same username and password. As a result this is an Application Integration pattern and not an Access Integration pattern since it is not a single sign-on implementation.

Guidelines for use

This pattern is useful for organizations that do not have a policy of a single central directory, but do not wish to maintain both an Active Directory and a Domino Directory. It does not, however, address access integration, and would have to be combined with one of the other patterns to achieve this. Again, WebSphere Application Server will use either Domino or Active Directory and does not place any constraints on the implementation.

Benefits and limitations

Clearly the benefit here is reduced directory maintenance. This pattern removes the need for directory administrators to make changes to two directories when new users are added, removed, and so forth. It is also a new feature of Domino 6, and therefore does not require any third party software.

This is only a directory synchronization tool, so it does not provide any form of access integration. Solutions to that problem can be found in other patterns that can be combined with this one.

Using both External and Domino directories (4.3)

Design Last Updated: 6-13-2003
(Click a node to get a detailed explanation.)

The figure above shows Domino and WebSphere Application Server using a central LDAP directory populated by data from other sources, including Domino using a Directory Integrator. This pattern is most applicable for organizations that want to maintain a central non-Domino directory to store user information and authenticate against but still need to use Domino for mail routing. It is the most complete solution, but it is also a little more complex. It makes use of a Directory Integration tool that moves data from many sources into one central directory. This greatly reduces the administration overhead and effort of having a single up-to-date directory.

Applicable Business patterns

The four patterns which form this topology are:

• Self-Service: One of the user's interactions with the environment is logically with WebSphere applications. That interaction represents the Self-Service pattern.
• Collaboration: One of the user's interactions is logically with Domino collaborative applications. That interaction represents the Collaboration pattern.
• Access Integration: By having a single directory for both application servers, this pattern fits the Access Integration pattern.
• Application Integration: The Directory Integrator tool here brings data from many different directory and non-directory sources together into one central directory. This, therefore, is clearly an Application Integration pattern over and above the existing application integration of Domino and WebSphere Application Server.

Guidelines for use

This pattern is especially useful when several sources of people information are being maintained (directories, HR systems, telephone systems, and databases) since they can all be synchronized automatically into one directory. This can happen on an event-driven basis (a new user is added, for example) or as a batch process.

Benefits and limitations

The benefits of this pattern are realized when many different systems including a Domino and an LDAP directory need to be consolidated. It greatly reduces the administration overhead of maintaining multiple sources. It does, however, require different third party software for the Directory Integrator node.

Using a security server to manage authentication and connections (4.4)

Design Last Updated: 6-13-2003
(Click a node to get a detailed explanation.)

An alternative to using the Domino/WebSphere single sign-on feature is to use an authentication manager between the user and the servers. Tivoli Access Manager is one example of an authentication manager. It has the great advantage of being expandable to manage authentication to multiple systems at once. In more complex environments, Access Manager will enable authentication to other vendor's systems.

Access Manager can be configured to:

• Authenticate users via a common LDAP directory that all the servers share
• Maintain separate IDs and password credentials for each system, but hide that from the user, who is only ever prompted for the one password

The connection between Access Manager and WebSphere Application Server/Domino is via pre-defined connections (Junctions) which define the servers and their properties. As far as WebSphere Application Server or Domino is concerned, Access Manager is just another client with an appropriate ID and password. No alterations to the applications are needed to insert Access Manager into an existing Runtime pattern. Access Manager is able to act as a reverse proxy for both the WebSphere Application Server and Domino servers simultaneously.

Applicable Business patterns

The four patterns which form this topology are:

• Self-Service: One of the user's interactions with the environment is logically with WebSphere Application Server applications. That interaction represents the Self-Service pattern.
• Collaboration: One of the user's interactions is logically with Domino collaborative applications. That interaction represents the Collaboration pattern.
• Access Integration: When Access Manager provides the interface to the user, it is gathering all of the content from each of the servers that it fronts in a reverse proxy manner. Unifying the interaction with the Domino and WebSphere Application Server is an example of the Access Integration pattern.
• Application Integration: In an environment like this, we could have Domino accessing WebSphere Application Server resources and presenting the result via Access Manager to the user; or we could have WebSphere Application Server accessing Domino resources and presenting the results via Access Manager to the client. We have included this pattern here, not because it is essential in this Runtime pattern, but because it is a possibility.

Guidelines for use

In a typical deployment of this Runtime pattern, Access Manager would reside in the DMZ, with both Domino and WebSphere Application Server behind the firewall in the internal network.

Benefits and limitations

The benefits of implementing this topology are:

• No requirements for specific versions of either WebSphere Application Server or Domino versions to enable single sign-on
• Extensible to other non-IBM/Lotus application servers
• Able to better protect the Domino and WebSphere Application Servers in the internal network
• Another layer of security that can have it's own rules and guidelines associated to achieve a slightly more granular security model

The only real limitation that this environment imposes is the cost of implementing the extra software and hardware to implement the Runtime pattern.

Domino for collaboration - Simplest pattern (4.5)

Design Last Updated: 6-13-2003
(Click a node to get a detailed explanation.)

In looking at Collaboration patterns, probably the most basic one we can picture is one with just Domino. Users could be interacting with each other via e-mail, news groups, or Web discussion forums.

Connections in this environment could use a number of protocols:

• NRPC - for Notes clients
• HTTP - for Web browser access to e-mail, news groups, or Web forums
• POP3/SMTP - for access to e-mails
• IMAP - for access to e-mails

All of these connection types represent the Collaboration pattern. Note that support for NNTP was removed in Domino 6.

Applicable Business patterns

• Collaboration: The only pattern at work here is the Collaboration pattern. It is Collaboration rather than Self-Service because the primary purpose of all of the interactions mentioned in the previous section is to communicate with other users.

Guidelines for use

It should be noted that this pattern makes use of the WebSphere HTTP plug-in since it allows the Domino server be located behind the firewall. This is recommended in even the simplest Internet-facing installations to prevent data from residing in the DMZ.

Benefits and limitations

Being a straightforward installation, configuration and management is relatively easy. Maintenance is also simple.

While the previous topologies dealt with asynchronous collaboration interaction, incorporating Sametime introduces the idea of synchronous collaboration interaction. Since Sametime will only work when installed on top of Domino, the previous patterns of directory architecture still apply to patterns involving Sametime. The two patterns that follow assume that Sametime uses an external directory.

Sametime only (4.6)

Design Last Updated: 6-13-2003
(Click a node to get a detailed explanation.)

Synchronous collaboration is provided by Sametime 3, which will only run on top of Domino 5.0.10. The option to install a stand-alone version of Sametime was removed with version 3. While it is possible to use the underlying Domino server for collaboration and messaging, this is not a recommended deployment since this can adversely affect the performance of Sametime.

Connections to the Sametime server from the various client types (Sametime Connect, Sametime Meeting client, Broadcast client) are via the appropriate protocols on the configured TCP/IP ports.

Applicable Business patterns

• Collaboration: The main pattern at work here is the Collaboration pattern. It is Collaboration rather than Self-Service because the primary purpose of all of the interactions (one-to-one, one-to-many, or many-to-many) is to communicate with other users.
• Application Integration: Since we have chosen to have an external directory, the Application Integration pattern is also apparent.

Guidelines for use

For external users, this Runtime pattern represents a fairly standard Sametime installation with Sametime residing in the DMZ typically. Internal users normally have their own internal Sametime server that they use. This internal server communicates with the DMZ Sametime server. This pattern can be further enhanced using the SIP Gateway extension to Sametime, which allows enterprises with separate Sametime communities to collaborate with each other.

Benefits and limitations

Sametime 3 introduced support for the LTPA token via the Browser Client, which greatly simplifies the end-user experience by avoiding the need to log in twice.

It is difficult with this basic Runtime pattern to move the Sametime server to the internal network and still permit external users to interact with the server. This is because Domino 5 does not support the WebSphere HTTP plug-in. The server needs to reside within the DMZ and is therefore more at risk.

It is also important to note that with Sametime 3, there is no longer the option of a standalone version. Domino must be installed and configured before Sametime can be installed.

Sametime and Domino 6 (4.7)

Design Last Updated: 6-13-2003
(Click a node to get a detailed explanation.)

In this pattern, asynchronous collaboration is provided by Domino and synchronous collaboration is provided by Sametime. Sametime 3 will only run on top of Domino 5.0.10, so any pattern that requires Sametime 3 and Domino 6 will require two versions of Domino.

Connections to the Sametime server from the various client types (Sametime Connect, Sametime Meeting client, Broadcast client) are via the appropriate protocols on the configured TCP/IP ports.

Connections to the Domino server could be for HTTP sessions, but could also be for Notes clients, POP3 or IMAP clients.

Applicable Business patterns

The three patterns at work in this topology are:

• Collaboration: This type of topology is usually used in environments where you want to incorporate instant messaging with existing Domino environments and security. Since the primary mission for the server is collaboration interaction, the Collaboration pattern is involved here. The collaborative functions of the Lotus Domino 6 server can be used for user-to-user interaction.
  The Domino 6 server can also be used for Self-Service patterns. We have not added that to the diagram for the sake of clarity. Technically, the Sametime server could be used for Self-Service patterns as well. We have not added that to the diagram mainly because it is not recommended to use a Sametime server in that manner.
• Access Integration: In a combined Domino/Sametime application, the use of single sign-on using the LTPA token prevents the user from being prompted multiple times when switching between an application that is served by Domino and services provided by Sametime. The single sign-on works in the same manner as single sign-on between Domino and WebSphere, being dependent on a token that the user's browser holds.
• Application Integration: Integration between Sametime services and Domino applications on this Domino server or other Domino servers is an example of application integration. Examples of this type of integration include providing "who is on-line" or "who is here" functionality to a Domino application that is served by Domino to Web-based users. The level of application integration might also extend to the application initiating a Sametime conversation between a help desk operator and the user.

Guidelines for use

For external users, Sametime implemented in this Runtime pattern would normally reside within the DMZ. In order to have internal users interact with the external users, an internal Sametime sever would normally be installed.

This Runtime pattern will enable you to create applications with user awareness built in. For more details and real-life scenarios illustrating this pattern, see the IBM Redbooks: B2B Collaborative Commerce with Sametime, QuickPlace and WebSphere Commerce Suite, Lotus Sametime Application Development Guide, Working with the Sametime Client Toolkits, and Working with the Sametime Community Server Toolkit.

Benefits and limitations

Sametime servers implemented in this manner can be readily integrated into more complex Domino and WebSphere environments, sharing the same single sign-on token between all of them. In that way, users will only ever be prompted once for their ID and password. Like the other Sametime topologies, this Sametime server needs to reside within the DMZ for external users to attach to it. Internal users will need their own internal Sametime server, as well, if they are to interact with the external users.

At the time of writing, Sametime 3 was only supported on Domino 5.0.10, meaning that different versions of Domino would have to be installed to get the benefits of both products.

The following three hybrid Runtime patterns concern situations where single sign-on is needed but we can use two technologies to provide that functionality. The first is when just Domino, WebSphere, and Sametime are required technologies, and we can rely on the LTPA support that is provided in all three applications.

There will be times where single sign-on is required for solutions that integrate with applications that do not support LTPA; in these cases we must rely on an authentication manager such as Tivoli Access Manager.

These designs expand on the discussion found in section 3.4, "Utilizing IBM single sign-on" of the Redbook Patterns: Custom Designs for Domino & WebSphere Integration, and the Hybrid runtime pattern, "Using a security server to manage authentication and connections" shown above.

Single sign-on with Sametime, Domino, and WebSphere (4.8)

Design Last Updated: 6-13-2003
(Click a node to get a detailed explanation.)

The Runtime pattern shown above is dependent on implementing the single sign-on between all three servers. We are starting to get into quite complex Runtime patterns, which can be used to implement powerful Web environments with many uses. While WebSphere can be used for collaboration interaction, in this topology, the better tools for the job are the Domino and Sametime servers.

This topology would typically require the Sametime server and the HTTP server (for Domino 6 and WebSphere 5) to be in the DMZ.

Applicable Business patterns

The patterns at work in this topology are:

• Collaboration: With Sametime and Domino providing synchronous and asynchronous collaboration interaction, these two servers along with the users form the core of the Collaboration pattern in this topology.
• Self-Service: By adding WebSphere into this topology, we have implied more than just collaboration interaction and we have effectively added some level of Self-Service integration. While it is possible to do that without WebSphere and with just Domino, we assume that the application calls for a more transactional design than Domino is ideally suited to. We have excluded Sametime from this pattern because it is really only for collaboration interaction. While it is possible to implement Sametime "bots" that automatically respond to a user's questions, most Sametime implementations are aimed at collaboration interaction and the automated responses to user questions can easily be achieved with either Domino or WebSphere. If Sametime bots were more common, then Sametime would probably be included in the Self-Service pattern.
• Access Integration: Provided the implementation prerequisites have been met, access integration occurs on the user's machine with all three servers. The client machine is a key part of the access integration because the authentication token that is valid for all three servers is stored on their machine.
• Application Integration: The application integration in this Runtime pattern could be between Domino, Sametime, and WebSphere. Examples of this are presented in the Sametime-related Redbooks cited previously.

Guidelines for use

To implement this topology for external users, Sametime and either Domino or WebSphere would normally reside within the DMZ. The third server (Domino or WebSphere) could also reside in the DMZ, or it could be in the internal network behind the firewall. This is because an external Sametime server cannot be used to serve the internal users, so whichever server is going to interact with the users should reside in the DMZ.

In order for the Sametime server to share it's single sign-on token with both the Domino and WebSphere servers, Sametime must be installed on top of a Domino 5.05 (or later) server. Users would then be able to authenticate with Domino, for instance, and then begin using Sametime with the Sametime server, knowing who the users are and that they are entitled to use Sametime.

Benefits and limitations

One of the benefits of this solution to the multiple server authentication problem is its simplicity for both administrators and users. Once users have authenticated and hold a token, they can easily access resources on the other server without the need to key in their ID and password again.

The Runtime pattern has some limitations, specifically:

• The Sametime server and related Domino server need to reside within the DMZ for external users to attach to them. Internal users will need their own internal servers, as well, if they are to interact with the external users. Having servers residing in the DMZ puts them at more risk that internal servers.
• In order to support the single sign-on, users must support cookies because the authentication token is stored on the client inside a cookie.
• It is not extensible to non-IBM/Lotus application servers.

Sametime and Domino with Tivoli Access Manager (4.9)

Design Last Updated: 6-13-2003
(Click a node to get a detailed explanation.)

By inserting Access Manager between the users and the servers, as illustrated in Figure 4-9, we can take advantage of Access Manager's abilities to provide single sign-on across multiple disparate systems.

Here, Access Manager is acting as a reverse proxy for all client access. Exactly the same application integration that occurred in the previous topology will apply with this Runtime pattern as well. The only difference with this topology is how the access integration is implemented.

Applicable Business patterns

The patterns involved in this Runtime pattern do not depend on how Sametime is installed, as they did in the previous Runtime pattern. The patterns are:

• Access Integration: Access Integration in this Runtime pattern makes use of Access Manager's global sign-on feature to integrate the access to both the Sametime and Domino servers without requiring the user to enter their ID and password again. Therefore, we have access integration occurring between Access Manager, WebSphere Applications Server (the HTTP Server), Sametime, and Domino.
• Application Integration: This topology is an example of application integration when the application on the Domino server exhibits "who is here" or "who is online" features.
• Collaboration: The Collaboration pattern is involved here because the main aim of the environment is to enable users to interact with other users.

Guidelines for use

In a typical deployment of this topology, Access Manager would reside in the DMZ, with both Domino and Sametime behind the firewall in the internal network.

Since the Sametime server is now on the internal network and therefore more secure, internal users can access it directly, which eliminates the requirement to have additional Sametime servers (provided they have the spare capacity, of course).

Benefits and limitations

The benefits of implementing this topology are:

• It is extensible to other non-IBM/Lotus application servers.
• It is able to better protect the Domino and Sametime servers in the internal network.
• It provides another layer of security that can have it's own rules and guidelines associated, to give a slightly more granular security model.

The only real limitation that this environment imposes is the cost of the extra software and hardware to implement the topology.

Combined Sametime, Domino, and WebSphere with Access Manager (4.10)

Design Last Updated: 6-13-2003
(Click a node to get a detailed explanation.)

This Runtime pattern is similar to the previous one except we are no longer making use of the Domino/WebSphere single sign-on token. Not being dependent on the Domino/WebSphere single sign-on token has a number of implications:

1. Sametime no longer needs to be installed as on overlay on an existing Domino installation.
2. All of the servers (Sametime, Domino and WebSphere) can be moved back into the internal network (or second level DMZ), with only the Access Manager in the DMZ.
3. The Domino server could potentially be any version from R4.5 onward and still be able to maintain the global sign-on integration.
4. WebSphere could be at any version and still be able to maintain the global sign-on integration.
5. Users no longer need to support cookies in order to authenticate across multiple systems.

Applicable Business patterns

The patterns associated with this topology are:

• Collaboration: With Sametime and Domino providing synchronous and asynchronous collaboration interaction, these two servers are enabling all of the collaboration interaction.
• Self-Service: With WebSphere in this topology, we have implied more than just collaboration interaction. A common reason for inserting WebSphere into the topology is to add some level of Self-Service integration. While it is possible to do that without WebSphere, and with just Domino, we assume that the application calls for a more transactional design than Domino is ideally suited to.
• Access Integration: Access Integration occurs in this Runtime pattern between the servers and Access Manager. The user is no longer involved in the access integration since Access Manager is performing all of the integration with regard to authentication. The user no longer needs to accept the authentication token.
• Application Integration: The application integration in this topology could be between Domino, Sametime, and WebSphere. Examples of this are included in the Sametime-related Redbooks cited previously.

Guidelines for use

In a typical deployment of this topology, Access Manager would reside in the DMZ, with Domino, Sametime, and WebSphere behind the firewall in the internal network. Since the Sametime server is now on the internal network, internal users can access it directly, which eliminates the requirement to have additional Sametime servers (provided they have the spare capacity, of course).

Benefits and limitations

The benefits of implementing this topology are:

• It is extensible to other non-IBM/Lotus application servers.
• The Domino and WebSphere servers are better protected in the internal network.
• It provides another layer of security that can have it's own rules and guidelines associated, to give a slightly more granular security model.

The only real limitation that this environment imposes is the cost of the extra software and hardware to implement the topology.

Load Balancer and Domino (9.3)

Design Last Updated: 6-13-2003
(Click a node to get a detailed explanation.)

When you have multiple identical Domino servers, fronted by Load Balancer, the configuration shown above works well with Basic authentication.

Once a browser user has authenticated with one of the servers, the browser will pass the validated user name and password on all subsequent requests to any of the servers; since they all have the same IP address, the browser is unaware that it is talking to several different servers. If the servers share the same Domino Directory, the same user name/password combination will be valid on each server and the user is only prompted to enter the user name and password once.

Using Domino's session (cookie) authentication, once the user has authenticated against any one server, the browser will return the cookie on every subsequent request to any of the Domino servers (since, as far as the browser knows, they are all the same server with a single IP address).

However, the Domino servers do not have any knowledge of each other's cookies. So when the browser sends back to Domino B the value of the DomAuthSessId cookie issued by Domino A, Domino B does not recognize the cookie. Domino B prompts the user to sign on again and sends a new value of DomAuthSessId back to the browser, overwriting the value set by Domino A.

If Load Balancer then routes the user back to Domino A, the user will again be re-prompted to log in. This scenario would clearly be unacceptable.

If you want to load balance across identical Domino servers and to use cookie-based authentication, one option is to use the sticky port setting in Load Balancer. Requests originating from any given IP address should then always be routed to the same server (except in case of server failure), thus minimizing the likelihood of users being asked to re-logon.

Note that WebSphere advanced edition does support persistent cookies (stored in a shared DB2 repository). In a similar configuration multiple WebSphere servers would recognize each other's cookies.

Caching Proxy and Domino (9.4)

Design Last Updated: 6-13-2003
(Click a node to get a detailed explanation.)

Just like the scenario with Load Balancer, multiple Domino servers behind a reverse proxy cache (Caching Proxy) can be set up to work well with Basic authentication. You should set up realm definitions mapping to all paths.

Once a browser user has authenticated with one of the servers, the browser will pass the validated user name and password on all subsequent requests; since they all have the same IP address the browser is unaware that it is talking to several different servers. If the servers share the same Domino Directory, the same user name/password combination will be valid on each server and the user is only prompted to enter the user name and password once. Using Domino's session (cookie) authentication, once the user has authenticated against any one server, the browser will return the cookie on every subsequent request to any of the Domino servers (since as far as the browser knows they are all the same server with a single IP address).

Like the Load Balancer scenario, Domino cookie-based authentication will be unusable in this scenario because each Domino server will be assigning its own value to the DomAuthSessId cookie and the browser does not distinguish the servers as separate.

Content-based routing

Caching Proxy in conjunction with Load Balancer can be used to provide content-based routing and load balancing across multiple groups of identical back-end servers. Because of the problems with realm names and cookies described previously, this will work best with a single group of back-end servers if authentication is being used.

If you decide to use the caching capabilities of the Caching Proxy component of WebSphere Edge Server, you have to consider how to make sure that pages which should be cached are cached, and that pages which should not be cached are not cached.

Guidelines for use

In a typical deployment of this topology, Access Manager would reside in the DMZ, with Domino, Sametime, and WebSphere behind the firewall in the internal network. Since the Sametime server is now on the internal network, internal users can access it directly, which eliminates the requirement to have additional Sametime servers (provided they have the spare capacity, of course).

Cache control

According to RFC 2616, by default, a response is cacheable if the requirements of the request method, request header fields, and the response status indicate that it is cacheable. There are two ways in which the server can issue cache control directives:

• HTTP headers, whereby the server can indicate that a page is not to be cached, or if it is cached, when it should be expired from the cache.
• A <META HTTP-EQUIV="name" CONTENT="content"> tag inserted in the <HEAD> section of the page's HTML.

The Meta dictionary on vancouver-webpages.com states that:

"While HTTP-EQUIV META tag appears to work properly with Netscape Navigator, other browsers may ignore them, and they are ignored by Web proxies...Use of the equivalent HTTP header, as supported by e.g. Apache server, is more reliable and is recommended wherever possible."

HTTP headers can be generated by CGI scripts or Java programs or, with Domino, LotusScript agents. On Domino, the DSAPI can also be used to overwrite HTTP header information, but this requires programming skills that may not be present in all Domino installations.

Apache and other Web servers also allow HTTP header information to be specified using side files in a directory whose name is defined in the httpd.cnf (httpd.conf) file. The directory name defaults to .Web and the extension for the files defaults to meta according to the httpd.cnf file that is shipped with Domino on NT. However, although these entries exist in Domino's httpd.cnf file, the Domino server does not honor the definitions.