The specific business functionality supported by applications that integrate WebSphere and Domino varies from one industry to another, and for each individual implementation of this type of solution. Patterns architects have performed a somewhat improvised assessment of the various solutions that might be created which combine WebSphere and Domino, and anticipated the most common problems developers would encounter when building these applications, along with solutions that can be used to address these problems. Such successful approaches are captured in the following hybrid Runtime patterns.

The designs are referred to as "hybrid Runtime patterns" because they show both the middleware nodes commonly seen on a normal Runtime pattern, plus a graphical representation of the Business and Integration patterns used in combination with one another to create this solution design.

Additionally, because these hybrid Runtime patterns are directly constructed with WebSphere and Domino in mind, the middleware node names are mapped directly to Domino, WebSphere, and related products in the figures, instead of generic node names that are used throughout the rest of the Web site. The following table displays the relationship between the generic node names and the actual products discussed in the following diagrams.

• Web server
  • IBM HTTP Server
  • or the HTTP Server thiat is part of Domino
• Web application server
  • IBM WebSphere Application Server
• Collaboration server
  • IBM Lotus Domino
  • or IBM Lotus Sametime Server
• Authentication Server
  • Policy Directory WebSEAL

Note also that the terms "WebSphere" and "WebSphere Application Server" are used interchangeably here, even though WebSphere refers to an entire product line. Other products will be referred to by their full names.

In an environment where Domino is providing the interface to the client, connection to WebSphere can be achieved using any of the connection methods: OSE Remote, servlet redirector, IIOP, SOAP, and HTTP.

Associated Patterns

Three patterns combine to create this hybrid Runtime pattern:

• Self-Service (aka User-to-Business): The whole hybrid Runtime pattern represents a pattern where users are interacting with a Web-based business system.
• Collaboration (aka User-to-User): The collaborative functions of the Domino server are used for user-to-user interaction.
• Application integration: Domino and WebSphere are connected, to provide integration between the two servers. In this hybrid Runtime pattern, there are a number of options for application integration between Domino and WebSphere, including OSE Remote, Servlet redirector, IIOP, SOAP, and HTTP.

Guidelines for use

The Domino application with WebSphere Integration platform hybrid Runtime pattern is common in sites where you are providing 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 process-oriented rather than data-oriented.

Benefits

The benefits of this hybrid Runtime pattern include:

• 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.

Limitations

One of the limitations of this hybrid Runtime pattern is that the only HTTP server that is used in the environment when using the OSE Remote is the Domino HTTP task or MS IIS. (Future versions of Domino may support other Web servers). This may introduce horizontal scalability issues at high usage. The Domino R5 HTTP task is based on the old Domino Go WebServer, which does not perform as well as, for example, the IBM HTTP server.

Probably the simplest of all the hybrid Runtime patterns, loading WebSphere on top of a Domino server is often the simplest and best pattern for smaller systems. This pattern gives Domino the WebSphere servlet engine which is fast robust and scalable.

This hybrid Runtime pattern also enables more advanced features, such as Enterprise JavaBeans (EJBs), to be used if the advanced edition of WebSphere Application Server is loaded. However, EJBs are often used in applications that have scalability and availability requirements that, anyway, point to having Domino and WebSphere on different nodes.

Associated Patterns

Four patterns are combined to create the WebSphere loaded on a Domino Server hybrid Runtime pattern:

• Self-Service (aka User-to-Business): The whole hybrid Runtime pattern represents a pattern where users are interacting with a Web-based business system.
• Collaboration (aka User-to-User): The collaborative functions of the Domino server are used for user-to-user interaction.
• Application integration: We can see Application integration between Domino and WebSphere to provide integration between the two servers. In this hybrid Runtime pattern, 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 is considered access integration because the HTTP task is responsible for the presentation of both servers (Domino and WebSphere).

As stated earlier, Domino/WebSphere integration with this hybrid Runtime pattern will usually be achieved by taking advantage of shared resources, for example, calling a JavaBean directly from application logic inside a Domino Database. Conversely, a JavaBean could directly manipulate the contents of a Domino database in the Domino server without the need to write CORBA code and enable communications over IIOP. However, you may want to use remote (CORBA) calls anyway to avoid future code changes in case you have to split Domino and WebSphere over two or more machines. Furthermore, using remote calls in the Domino API may actually give better performance. If using local calls, there is the overhead of creating and tearing down Notes threads for every invocation of every method that calls a Domino object.

Guidelines for use

This hybrid Runtime pattern is appropriate in situations where the transactional requirements are not enormous. Examples of such sites might include:

• Applications including use of servlets. The servlet engine in WebSphere V3.5 is more configurable, more robust, and more scalable than the one supplied with Domino R5. Note, however, that the next major release of the Domino server, known as Rnext, will have a very improved servlet engine. Applications that require Domino and WebSphere integration today because of servlet execution requirements may be able to run solely on a Domino Rnext server.
• 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, but without extensive requirements for transaction processing.
• Sites where the main focus is user collaboration, either with staff or with other users. WebSphere may be used for (say) controlling 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. This hybrid Runtime pattern is also well suited to test environments and makes a good starting point for sites. Going forward, it leaves the way open to split the servers when it becomes necessary. The next step would normally be to separate WebSphere onto a separate server and connect to it via OSE Remote.

Benefits

The key benefits of this hybrid Runtime pattern are that it is simple to configure and maintain, and that it is low cost.

Limitations

Since there is no separation between Domino and WebSphere, this hybrid Runtime pattern won't scale well as it stands. It does provide a good starting point for implementations, and leaves open the option of splitting the Domino and WebSphere servers at a later stage when necessary.

In an environment with both Domino and WebSphere, when switching to the other server, users would normally be prompted to log in. Implementing a single sign-on between WebSphere and Domino remedies that situation. It is accomplished by issuing a session token to the browser that is valid for both WebSphere and Domino. This hybrid Runtime pattern does not illustrate which of the two servers is actually the main source of the client interface. In fact, it could be both of them.

Associated Patterns

Four patterns are combined to create this hybrid Runtime pattern:

• Self-Service (aka User-to-Business): The user's interaction with either the WebSphere or the Domino server represents the user-to-business pattern. In this hybrid Runtime pattern, both servers may be serving the client directly, or indirectly via the other server.
• Collaboration (aka User-to-User): The collaborative functions of the Domino server are used for user-to-user interaction.
• Access integration: When single sign-on is implemented between WebSphere and Domino, it is dependent on the client's Web browser maintaining a token which is shared among the Domino and WebSphere servers. The browser is effectively performing the access integration, not through any integration between Domino and WebSphere.
• Application integration: In an environment like this, we could have Domino accessing WebSphere resources and presenting the result to the user, or we could have WebSphere accessing Domino resources and presenting the results to the client. Within the one application, some parts may be presented by Domino, while other parts are presented by WebSphere. We have included this pattern here, not because it is essential in this hybrid Runtime pattern, but because it is a possibility.

Guidelines for use

In a typical implementation of this hybrid Runtime pattern, both the Domino server and the WebSphere server will reside within the DMZ. This is because users need to be able to access both servers. Some other points that should be considered are:

• Either Domino or WebSphere could authenticate the user. The user would then be authenticated across both servers.
• The model can be easily extended to incorporate many Domino and WebSphere servers all sharing the same single sign-on token.
• Domino must be at 5.0.5 or higher, WebSphere Application Server at 3.5.3 or higher.

Benefits

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

Limitations

The limitations of this hybrid Runtime pattern are:

• It is not as secure as other hybrid Runtime patterns since both servers are in the DMZ.
• Servers must be at the specified revision levels for single sign-on to work.
• It is not extensible to servers other than Domino and WebSphere. Note, however, that other IBM products may be enabled to use the same SSO token in the future, so this may change.

An alternative to depending on the Domino/WebSphere single sign-on is to use an authentication manager between the user and the servers. Tivoli Policy Director is one possible example of an authentication manager. It has the advantage of being expandable to manage authentication to multiple systems at once. In more complex environments, Policy Director will enable authentication to other systems such as Netscape, or Microsoft's Internet Information Server. The name of the Policy Director component that provides this Web single sign-on functionality is WebSEAL.

As depicted in the figure above, Policy Director WebSEAL will be implemented within the DMZ, and the WebSphere and Domino servers reside inside the corporate network (or within a secondary DMZ). Policy Director can be configured to:

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

The connection between Policy Director and WebSphere/Domino is via pre-defined connections (junctions) which define the servers and their properties. As far as WebSphere or Domino is concerned, Policy Director is just another client with an appropriate ID and password. No alterations to the applications are needed to insert Policy Director into an existing hybrid Runtime pattern. Policy Director is able to act as a reverse proxy for both the WebSphere and Domino servers simultaneously. Policy Director actually adds a level of trust for the backend application servers because all the connections coming from Policy Director WebSEAL have already been properly authenticated.

Associated Patterns

Four patterns are combined to create this hybrid Runtime pattern:

• Self-Service (aka User-to-Business): One of the user's interactions with the environment is logically with WebSphere applications. That interaction represents the user-to-business pattern.
• Collaboration (aka User-to-User): One of the user's interactions is logically with Domino collaborative applications. That interaction represents the User-to-User pattern.
• Access integration: When Policy Director 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 Domino and WebSphere is an example of the Access integration pattern.
• Application integration: In an environment like this, we could have Domino accessing WebSphere resources and presenting the result via Policy Director to the user, or we could have WebSphere accessing Domino resources and presenting the results via Policy Director to the client. We have included this pattern here, not because it is essential in this hybrid Runtime pattern, but because it is a possibility.

Guidelines for use

In a typical deployment of this hybrid Runtime pattern, Policy Director would reside in the DMZ, with both Domino and WebSphere behind the firewall in the internal network. Note that in testing we found that in order for Policy Director V3.6 to properly implement Web single sign-on, the single sign-on configuration (between Domino and WebSphere) must be disabled. However, with Policy Director V3.8 this restriction will be removed.

Benefits

The benefits of implementing this hybrid Runtime pattern include:

• No requirements for specific versions of either WebSphere Application Server or Domino versions (unless you want to apply a second level of authentication)
• Extensible to other non-IBM/Lotus application servers
• Able to better protect the Domino and WebSphere servers in the internal network
• Another layer of security that can have it's own rules and guidelines associated to give a slightly more granular security model

Limitations

The only real limitation that this environment imposes is greater capital outlay to install, configure, and buy the extra software and hardware to implement the hybrid Runtime pattern, as well as some additional administration cost.

In looking at User-to-User 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 be over a number of protocols, all of which represent the Collaboration (aka User-to-User) business pattern:

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

Associated Patterns

The only pattern at work here is the User-to-User business pattern. It is User-to-User rather than User-to-Business because the primary purpose of all interactions mentioned in the previous section is to communicate with other users.

Guidelines for use

For external users, this hybrid Runtime pattern represent a fairly standard Domino installation with Domino typically residing in the DMZ. Internal users would normally have their own internal Domino server that they use. This internal Domino server would replicate with the DMZ Domino server.

Benefits

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

Limitations

It is difficult with this basic hybrid Runtime pattern to move the Domino server to the internal network and still permit external users to interact with the server. The server, therefore, needs to reside within the DMZ and is more at risk located there.

While the previous hybrid Runtime pattern dealt with asynchronous User-to-User interaction, inserting Sametime introduces the idea of synchronous User-to-User interaction.

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

Note that when we talk about single sign-on between Sametime, Domino, and WebSphere, we look at accessing the Sametime server from a Web browser for functions like accessing the meeting center. The version of the Sametime Connect client we used could not be configured for single sign-on together with WebSphere.

Associated Patterns

The only pattern at work here is the Collaboration (aka User-to-User) pattern. It is User-to-User rather than User-to-Business 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.

Guidelines for use

For external users, this hybrid Runtime pattern represent a fairly standard Sametime installation with the Sametime server typically residing in the DMZ. Internal users would normally have their own internal Sametime server that they use. This internal server would communicate with the DMZ Sametime server.

Benefits

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

Limitations

It is difficult with this basic hybrid Runtime pattern to move the Sametime server to the internal network and still permit external users to interact with the server. The server, therefore, needs to reside within the DMZ and is more at risk located there.

A Sametime server implemented using a standard install cannot support single sign-on with any other Domino or WebSphere servers. It is therefore more difficult to fully integrate with other Domino, or WebSphere-based applications.

When Sametime is installed on a pre-existing Domino server, Sametime uses the core of the Domino server as it's basis. This means that if the user has authenticated with the Domino server already, they are automatically authenticated with the Sametime server as well.

Connections to the Sametime server from the various client types (Sametime Connect, Sametime Meeting client, Broadcast client) will be 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, IMAP, or NNTP clients.

Associated Patterns

The three patterns at work in this hybrid Runtime pattern are:

• Collaboration (aka User-to-User): This type of Runtime pattern would usually be used in environments where you want to incorporate instant messaging with existing Domino environments and security. Since the primary mission for the server will be user-to-user interaction, the user-to-user pattern is involved here. Although it is not recommended, it is possible to use the Domino server directly for duties that normal Domino servers are used for, such as e-mail, Web applications, and so on. Potentially, we could also be using the asynchronous user-to-user pattern described in 3.1.7, Domino user-to-user Runtime patterns. The server could also be used for user-to-business patterns. We have not added that to the diagram for the sake of clarity and because it is not recommended to use a Sametime server in that manner.
• Access integration:In a combined Domino/Sametime application, the use of the single sign-on will prevent 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 might be 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 hybrid Runtime pattern would normally reside within the DMZ. In order to have internal users interact with the external users, an internal Sametime server would normally be installed. In order for the Sametime server to share it's single sign-on token with other Domino or WebSphere servers, Sametime must be installed over the top of a Domino 5.0.5 (or later) server. Servers implemented in this fashion should only be used for Sametime. They should not attempt to perform normal Domino server tasks. As such, when configuring the Domino server in this environment, you should remove unnecessary tasks from the servertasks line in the NOTES.INI file.

Benefits

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 be prompted once for their ID and password.

Limitations

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.

Like the previous hybrid Runtime pattern, our primary interest in this design is in providing the infrastructure for user-to-user interactions. In this hybrid Runtime pattern, those interactions could be either synchronous via the Sametime server or asynchronous via the Domino server.

In this hybrid Runtime pattern, the Sametime server may be installed as an overlay of a Domino server, as described earlier. Sametime (2.0) server is based on the core of Domino 5.03; it does not contain the single sign-on enhancements that were added to Domino with R5.0.5. By installing Sametime over an existing Domino 5.0.5 or higher server, Sametime can then take advantage of the single sign-on features. Without this type of installation, users would be prompted for their ID and password when switching between Domino and Sametime services.

This hybrid Runtime pattern will enable you to create applications with user awareness built in. Applications with awareness are discussed in the Redbooks B2B Collaborative Commerce with Sametime, QuickPlace and WebSphere Commerce Suite and Lotus Sametime Application Development Guide.

Associated Patterns

The patterns involved in this hybrid Runtime pattern depend to an extent on how Sametime is installed (that is, if it is installed over an existing Domino server).

• Access integration: Access integration in this hybrid Runtime pattern only exists if Sametime is installed over a Domino server to take advantage of the single sign-on feature with this type of installation. If this is done, this hybrid Runtime pattern is an example of access integration when the user accepts the single sign-on token, then uses it to integrate the two interfaces of the Sametime and Domino applications without requiring the user to enter their ID and password again.
• Application integration: This hybrid Runtime pattern is an example of application integration when the application on the Domino server exhibits "who is here" or "who is online" features.
• Collaboration (aka User-to-User): The user-to-user pattern is involved here because the main aim of the environment is to enable users to interact with other users.

Guidelines for use

For external users, Sametime and Domino 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 and Domino servers would normally be installed.

In order for the Sametime server to share it's single sign-on token with the Domino server, Sametime must be installed over the top of a Domino 5.0.5 (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 user is and that they are entitled to use Sametime.

Benefits

One of the benefits to 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 needing to key in their ID and password again.

Limitations

This hybrid Runtime pattern has some limitations. They include:

• Both servers must 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 both servers live in the DMZ puts them at more risk that internal servers.
• In order to support single sign-on, users must support cookies because the authentication token is stored on the client inside a cookie.
• This pattern is not extensible to non-IBM/Lotus application servers.

By inserting Policy Director between the users and the servers, we can take advantage of Policy Director's ability to provide Web single sign-on across multiple disparate systems.

In this hybrid Runtime pattern, because Policy Director is managing the authentication back to the Sametime and Domino servers, we could use the standard (non-overlay) install of Sametime and still avoid the user having to authenticate with both servers individually. This Runtime pattern also enables us to move our Sametime and Domino servers from the DMZ. Depending on requirements, they could be placed on the internal network or in a secondary DMZ.

Exactly the same application integration that occurred in the previous hybrid Runtime pattern will apply with this design as well. The only difference with this hybrid Runtime pattern is how the Access Integration is implemented.

Associated Patterns

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

• Access integration: Access integration in this hybrid Runtime pattern makes use of Policy Director's Web single 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 Policy Director and Sametime and Domino.
• Application integration: This hybrid Runtime pattern is an example of application integration when the application on the Domino server exhibits "who is here" or "who is online" features.
• Collaboration (aka User-to-User): The user-to-user 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 hybrid Runtime pattern, Policy Director would reside in the DMZ, with both Domino and Sametime behind the firewall in the internal network.

Our Sametime server can now be a standard non-overlay install of Sametime because Policy Director will maintain the authenticated session with Sametime on behalf of the user.

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

The benefits of implementing this Runtime pattern are:

• There are no requirements for specific versions of either WebSphere Application Server or Domino.
• It is extensible to other non-IBM/Lotus application servers.
• You are able to better protect the Domino and WebSphere servers in the internal network.
• Another layer of security that can have it's own rules and guidelines associated yields a slightly more granular security model.

Limitations

The only real limitation that this environment imposes is greater capital outlay to install, configure, and buy the extra software and hardware to implement the hybrid Runtime pattern.

When we combine WebSphere with Domino and Sametime in a hybrid Runtime pattern we find that we are extending previous designs, namely 3.1.5, Single sign-on between Domino and WebSphere, and 3.1.10, Combined Sametime and Domino (separate machines). This hybrid Runtime pattern, like the two previous designs, is dependent on implementing the single sign-on between all three servers. As mentioned earlier, in order to implement this feature, the Domino, Sametime, and WebSphere servers must be at certain minimum revision levels. Domino servers must be at least R5.0.5, Sametime must be loaded over an existing Domino R5.0.5 server, and WebSphere must be at least version 3.5 with fix pack 2 (3.5.3) with eFix PQ45555. Note also, that we achieve single sign-on for the Sametime functions we access on the server via a Web browser. The version of the Sametime Connect client we used still requires a separate login.

We are starting to get into quite complex hybrid Runtime patterns which can be used to implement powerful Web environments with many uses. While WebSphere can be used for user-to-user interaction, in this design, the better tools for the job are the Domino and Sametime servers.

This hybrid Runtime pattern would typically require the Sametime server and either the Domino server or WebSphere to be in the DMZ.

Associated Patterns

The patterns at work in this hybrid Runtime pattern are:

• Collaboration (aka User-to-User): With Sametime and Domino providing synchronous and asynchronous user-to-user interaction, these two servers with the users form the core of the user-to-user pattern in this design.
• Self-Service (aka User-to-business): By adding WebSphere into this hybrid Runtime pattern, we have implied more than just user-to-user interaction. The reason for inserting the WebSphere server into the Runtime pattern is to add some level of user-to-business 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 user-to-user interaction.
  While it is possible to implement "bots" that automatically respond to a user's questions, most Sametime implementations are aimed at user-to-user 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 user-to-business pattern.
• Access integration: Provided the implementation prerequisites have been met, access integration is occurring on the user's machine with all three servers. The user 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 hybrid Runtime pattern could be between Domino, Sametime, and WebSphere. Examples of this can be seen in the Redbooks B2B Collaborative Commerce with Sametime, QuickPlace and WebSphere Commerce Suite and Lotus Sametime Application Development Guide.

Guidelines for use

To implement this hybrid Runtime pattern 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 Sametime cannot be used to serve the site, 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 over the top of a Domino 5.0.5 (or later) server. Users would then be able to authenticate with Domino, for example, and then begin using Sametime with the Sametime server knowing who the user is and that they are entitled to use Sametime.

Benefits

One of the benefits to 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 need to key in their ID and password again.

Limitations

The Runtime pattern has some limitations. They are:

• The Sametime server and at least one of the other two servers must 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 reside 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.
• This pattern is not extensible to non-IBM/Lotus application servers.

This hybrid 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 Policy Director 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.

Associated Patterns

The patterns associated with this hybrid Runtime pattern are:

• Collaboration (aka User-to-user): With Sametime and Domino providing synchronous and asynchronous user-to-user interaction, these two servers are enabling all of the user-to-user interaction.
• Self-Service (aka User-to-business): With WebSphere in this Runtime pattern, we have implied more than just user-to-user interaction. A common reason for inserting WebSphere into the Runtime pattern is to add some level of user-to-business 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 is occurring in this Runtime pattern between the servers and Policy Director. The user is no longer involved in the access integration since Policy Director 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 Runtime pattern could be between Domino, Sametime, and WebSphere. Examples of this can be seen in the Redbooks B2B Collaborative Commerce with Sametime, QuickPlace and WebSphere Commerce Suite and Lotus Sametime Application Development Guide.

Guidelines for use

In a typical deployment of this hybrid Runtime pattern, Policy Director would reside in the DMZ, with Domino, Sametime, and WebSphere behind the firewall in the internal network.

Note that in testing we found that in order for Policy Director V3.6 to properly implement Web single sign-on, the single sign-on configuration (between Domino, Sametime, and WebSphere) must be disabled. This is not the case for Policy Director V3.8.

Our Sametime server can now be a standard non-overlay install of Sametime because Policy Director will maintain the authenticated session with Sametime on behalf of the user.

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

The benefits of implementing this hybrid Runtime pattern are:

• There are no requirements for specific versions of either WebSphere Application Server or Domino.
• It is extensible to other non-IBM/Lotus application servers.
• You are able to better protect the Domino and WebSphere servers in the internal network.
• Adding another layer of security that can have it's own rules and guidelines associated yields a slightly more granular security model.

Limitations

The only real limitation that this environment imposes is greater capital outlay to install, configure, and buy the extra software and hardware to implement the Runtime pattern, as well as some additional administration cost.

It is possible to use Domino as a central hub in an environment where a number of disparate systems need to be coordinated and where user interaction is also needed. IBM MQSeries and MQSeries Integrator provide an effective way to connect heterogeneous systems asynchronously. Where Domino becomes an appropriate choice in this type of environment is when the core applications are collaborative applications.

Typically, MQSeries Integrator (MQSI) would be used to integrate multiple systems such as in this Runtime pattern. The user interface is to be provided by WebSphere. For more details see the redbook User-to-Business Patterns Using WebSphere Advanced and MQSI: Patterns for e-business Series. Sections 3.1, "Runtime topology A", and 3.2, "Topology A variation 1" of this redbook describe MQSI and WebSphere integration topologies.

In environments that require less transactional processing and more collaboration, user communication, and workflow, Domino is a more suitable solution for the user interaction.

The one point that distiguishes this Runtime pattern from a typical MQSI Runtime pattern is the integration of users with user interactions that Domino servers are better suited to. This integration might include areas of strength for Domino such as workflow or document management. While it would be possible to develop this functionality for WebSphere servers, it would take a considerable amount of development effort to match that which comes standard with Domino, let alone the rapid build environment that Domino provides for those types of applications.

Associated Patterns

The following patterns are in use in this complex hybrid Runtime pattern:

• Self-Service (aka User-to-business): One of the user's interactions with the environment is logically with WebSphere or MQSI applications. That interaction represents the user-to-business pattern.
• Extended Enterprise (aka Business-to-business): Business-to-business patterns may be involved here since the use of MQSI provides an excellent method for integrating with other companies for supply chain management, forward order control, returns processing, and other business applications that require connections to a company's trading partners.
• Application integration: Application integration is occurring in this Runtime pattern between Domino and WebSphere when Domino passes various tasks to WebSphere for it to complete, and between Domino and MQSI where existing systems require asynchronous connections and interactions. We also have application integration being demonstrated with Domino accessing various other data sources such as ERP systems, relational databases, and so on. Lotus, at present, provides LotusScript eXtensions (LSX) for MQ Series, DB2, ODBC, File systems, and ERP systems. Lotus Connector eXtensions (LCX) are also available for a wide range of ERP systems, relational databases, and file systems.

Guidelines for use

Since the Domino server is interacting directly with the users, the Domino server should be located within the DMZ while all of the other servers (WebSphere and MQSI) could potentially reside on the internal network at less risk. We have a number of options with communications to both the WebSphere server and the MQSI server. For WebSphere, these options are:

• OSE Remote
• Servlet redirector
• IIOP
• SOAP

For the interaction with MQSI, the options are:

• Java Message System (JMS) interface to MQ
• MQ Series Java Classes
• MQ LSX directly from Domino

Benefits

The benefits of this Runtime pattern include:

• Ease of integration with Domino workflows.
• Rapid development environment of Domino enables solutions to be quickly developed and modified as business demands and conditions change.
• Flexible environment that can change as quickly as the business process changes.
• Integration of Domino-based information with other systems and other companies.

Limitations

Provided this Runtime pattern is positioned in a process-oriented environment, there are no significant limitations. Scaling can be achieved by using both horizontal and vertical scaling techniques. This Runtime pattern should not be used for transactional systems, but is well suited to people and process systems.

In this section we discuss the benefits of combining caching proxy serving as a reverse proxy and the load balancer (Network dispatcher) to improve your organization's security and scalability. The above figure shows a highly available and secure topology.

In this topology, we have two sets of load balancers (Network Dispatchers), one within the DMZ between the company firewall and the internal domain firewall and another in the internal network of the enterprise. The primary and backup network dispatchers inside the firewall provide a more available and scalable front end for the Web users. The Backup Network Dispatcher never comes into play unless the Primary Network Dispatcher is down, and in that case, it automatically takes over the control. They both serve redundant Caching Proxy servers inside the firewall.

The internal domain firewall is set to allow traffic only to and from caching proxy servers. The caching proxy servers in turn request and retrieve data from Domino and/or WebSphere domains. The internal primary and backup network dispatchers intercept the caching proxy requests and perform necessary load balancing for the Domino clusters and WebSphere clones.

This ensures that there is no single point of failure for most parts of the network, making this very suitable for serving mission-critical information. Also, since the Web users can never see the internal network and therefore its servers, this is highly secure in addition to being robust and scalable.

Domino usage notes

You have to take care with the specification of paths to be mapped to different servers because Domino generates references relative to root ("/"). By default, references to icons are generated as, for example: <IMG SRC="/icons/vwicn137.gif">
Other references are generated as, for example: <A HREF="/dwa/dwa2.nsf/5b7..f7f9!Navigate&To=Prev">

If you use WTE as a reverse proxy in front of several Domino servers, you will probably also need to include a proxy statement in the configuration file mapping server_root ("/") to a specific server on which you will at least have a centralized repository for icon files.

Tivoli Policy Director can also be made to work as a basic load balancer for Domino, WebSphere, or any back-end Web application server that is a part of the namespace. The figure above illustrates how Policy Director could handle multiple clustered servers.

Policy Director can also be combined with one or more IBM Edge Server Load Balancers to prevent single points of failure. The figure below is a sample topology of how Policy Director and IBM Edge Server Load Balancer could be combined.

Domino usage notes

Tivoli Policy Director can provide protected access to WebSphere servers and Domino servers using LDAP authorization via a shared LDAP directory. LDAP servers supported for this purpose include IBM LDAP, Netscape LDAP, and (new to 3.8) the MS Active Directory. In such a configuration Domino could be configured to use the IBM LDAP server (for example), but Domino itself is not supported as an LDAP server.

Based upon the issues we have we covered in the discussion of these designs, we offer the following recommendations for using Domino together (or perhaps not together) with the WebSphere Edge Server.

• If you have Multiple identical Domino Servers then
  • Edge Server should normally be used for HTTP load balancing. If authentication is required you should always use the Multi-Server (SSO) option.
• If you have Multiple non-identical Domino servers then
  • If the Domino servers host different sets of databases, you can use Edge Server's content-based routing to route requests for particular databases to the appropriate servers.
• If you have Concerns about performance and caching then
  • Select a tracing tool and test all major browsers with whatever cache settings you think users may have used. Preferably also test via major ISPs (AOL, and others depending on your geography) to assess the impact of the ISPs' proxy caches.

Even though not directly related to our topic, we include here some information on tools and techniques we find useful when working with Domino and WebSphere e-business solutions.

HTTP tracing tools

In order to understand the commands issued by browsers and HTTP servers, and in particular the commands which affect caching, you need a tool which can display all the headers sent in each direction. Among them are:

• HttpTracer from Superior Software Tools ($25 Shareware)
• Pluxy (Beta-4)
• Microsoft's Web Application Stress Tool (WAS): This tool is currently downloadable without charge. This is primarily a stress test tool which can record all commands and headers sent by the browser and then replay sessions. It does not allow you to analyze the contents of the HTTP headers sent by the server.

Sample DSAPI code for HTTP headers

A good write-up of the Domino caching situation and downloadable DSAPI sample code can be found on the Original Business Systems site. We have not evaluated the sample code in the course of writing up this information.