Sun Java Communications Suite 5 Deployment Planning Guide

Chapter 21 Developing an Instant Messaging Architecture

This chapter describes a variety of Instant Messaging architectures. Depending on your deployment, you will need to install different components. For example, to support email notification, you need to install an SMTP server. If you do not want to support email notification, do not install an SMTP server.

For more detailed information about components that interoperate with Instant Messaging, see Components Related to Instant Messaging.

This chapter contains the following sections:


Note –

Currently, all deployment options are available on Solaris OS. A subset of the deployment options is available on the Linux operating system.


Basic Instant Messaging Architecture

Figure 21–1 shows the basic Instant Messaging architecture.

Figure 21–1 Basic Instant Messaging Architecture

This diagram shows the relationship between components
in a basic Instant Messaging deployment.

The basic Instant Messaging architecture provides such functionality as chat, news alerts, and conferences. To provide this basic functionality, you need to install the following components:

In this example:

Authentication in a Basic Architecture

Figure 21–2 shows the interaction of the software components in the authentication process of a basic architecture of Instant Messaging. The focus is on the flow of authentication requests. An explanation of the steps in this process follows the figure.

Figure 21–2 Flow of Authentication Requests in a Basic Instant Messaging Architecture

This diagram shows the flow of authentication requests
during the authenication process of an LDAP-only  Instant Messaging server
configuration.

The authentication process in a basic architecture works as follows:

  1. End user accesses the Instant Messenger applet URL from a browser and chooses a method to invoke the client.

  2. The browser invokes Java Web Start or the Java plugin.

  3. Java Web Start or the Java plugin downloads the necessary Instant Messenger resource files and starts Instant Messenger.

  4. The login window appears and the end user enters the login name and password. The login data is sent to the Instant Messaging server through the multiplexor.

  5. The Instant Messaging server communicates with the LDAP server to authenticate the end user and to request end-user information, such as contact lists or subscriptions.

When the end-user authentication is complete, the Instant Messaging main window appears, displaying the contact list for the end user. The end user can now start and participate in Instant Messaging sessions with the other end users.

Instant Messaging Email Notification (Calendar Alert) Architecture

You can deploy Instant Messaging to support email notification to offline users, as well as Instant Messaging based notification of calendar events to users.

An Instant Messaging architecture that supports email notification and calendar alerts provides the same functionality as Basic Instant Messaging Architecture. To provide this functionality, you need to include the components listed in Basic Instant Messaging Architecture. To support email alerts, you also install an SMTP server such as Sun Java System Messaging Server. To support calendar alerts, you also install Sun Java System Calendar Server.

To enable email notification, you are prompted to identify the SMTP server to use with Instant Messaging during installation. If you do not have an SMTP server installed, you must install one before installing the Instant Messaging software. Figure 21–3 shows Instant Messaging with email notification enabled on the network.

If you do not have Calendar Server installed, you must install it before installing the Instant Messaging software. Figure 21–4 shows Instant Messaging with calendar notification enabled on the network.

Authentication flow in this architecture is the same as in a basic deployment. See Authentication in a Basic Architecture for more information.

Figure 21–3 Instant Messaging Architecture with Email Notification

This diagram shows the relationship between components
in an Instant Messaging deployment with email notification enabled.

In this example:

Figure 21–4 Instant Messaging Architecture with Calendar Alerts

This diagram shows the relationship between components
in an Instant Messaging deployment with Calendar event notification enabled.

In this example:

Instant Messaging Access Manager or SSO Architecture

You can deploy Instant Messaging to use Access Manager policy features and single sign-on (SSO). An Instant Messaging architecture that uses Access Manager provides the same functionality as Basic Instant Messaging Architecture. To provide this functionality, you need to install the components listed in Basic Instant Messaging Architecture and also install Access Manager. In addition, you need to install the Access Manager SDK on the Instant Messaging server host.

In this architecture, Instant Messaging uses the directory to search for users but not to authenticate or authorize them. Instead, Access Manager is responsible for authenticating and authorizing users.

Figure 21–5 shows the Instant Messaging Access Manager architecture.

Figure 21–5 Instant Messaging Architecture With Access Manager-based Server Policy Management or Single Sign On

This diagram shows the relationship between components
in an Instant Messaging deployment with Access Manager.

In this example:

Authentication in an Access Manager Only Architecture

Figure 21–6 illustrates the authentication process used by the Instant Messaging software in collaboration with Portal Server and Access Manager components in a single sign-on environment. As with Figure 21–2, this figure focuses on the flow of authentication requests. An explanation of the steps in this process follows the figure.

Figure 21–6 Flow of Authentication Requests in an Access Manager Configuration

This diagram shows Instant Messaging archive components
and data flow.

The authentication process of the Instant Messaging server in this deployment within a single sign-on environment works as follows:

  1. The end user logs in to the Access Manager server by entering the URL in a web browser.

  2. The Access Manager software authenticates the end user and returns a session token.

    The session token is what enables single sign-on to work. This token is provided as an applet parameter and is used throughout the authentication process. End users are not asked for their credentials again as long as the session token is present.

  3. End user accesses the Instant Messenger applet URL from a browser and chooses a method to invoke the client.

  4. The browser invokes Java Web Start or the Java plugin as appropriate.

  5. Java Web Start or the Java plugin downloads the necessary Instant Messenger resource files and starts Instant Messenger.

  6. Instant Messenger requests authentication to the Instant Messaging server using the session token.

  7. The Instant Messaging server asks Access Manager to validate the session token. If the session is valid, Instant Messenger displays the end user’s contact list and the end user can then use Instant Messenger services: chat, alerts, polls, etc.

  8. The Instant Messaging server must query LDAP directly to get or set end-user information, such as contact lists or subscriptions.

Instant Messaging Portal-based or Archiving Architecture

You can deploy Instant Messaging to support message archiving and to have basic Instant Messaging functionality through the Portal Desktop. An Instant Messaging architecture that provides for this functionality also provides the same functionality as Basic Instant Messaging Architecture. In addition, the Instant Messenger client is made available to end users through the Portal Server desktop. To provide this functionality, you need to install the components listed in Basic Instant Messaging Architecture and also install Portal Server and Access Manager.

This architecture uses the directory and Web servers accessed by the Access Manager. You do not need to install additional instances of those servers. In addition, because this architecture requires Access Manager, all the features described in Instant Messaging Access Manager or SSO Architecture are also available.

Figure 21–7 shows the Instant Messaging Portal-based architecture.

Figure 21–7 Instant Messaging Architecture With Portal-based Secure Mode or Archiving

This diagram shows the Instant Messaging archive components
and data flow.

In this example:

Authentication in a Portal Server Architecture

Figure 21–8 illustrates authentication process used by the Instant Messaging software in collaboration with Portal Server and Access Manager components in a single sign-on environment. As with Figure 21–2, this figure focuses on the flow of authentication requests. An explanation of the steps in this process follows the figure.

Figure 21–8 Flow of Authentication Requests in a Portal Server and Access Manager Configuration

This diagram shows Instant Messaging when deployed with
Portal Server.

The authentication process of the Instant Messaging server in this deployment within a single sign-on environment works as follows:

  1. The end user logs in to the Portal Server by entering the URL in a web browser.

  2. The Access Manager software authenticates the end user and returns a session token and the Portal Server downloads the Desktop for the end user. The Portal Server Desktop is displayed in the end user’s browser. See Step 6 for an explanation of the session token.

  3. The end user clicks the Instant Messenger URL link from the Instant Messaging channel on the Desktop.

  4. The browser invokes Java Web Start or the Java plugin.

  5. Java Web Start or the Java plugin downloads the necessary Instant Messenger resource files and starts the Instant Messenger.

  6. Instant Messenger requests authentication to the Instant Messaging server using the session token.

    The session token is what enables single sign-on to work. This token is provided as an applet parameter and is used throughout the authentication process. End users are not asked for their credentials again as long as the session token is present.

  7. The Instant Messaging server asks Access Manager to validate the session token. If the session is valid, Instant Messenger displays the end user’s contact list and the end user can then use Instant Messenger services: chat, alerts, polls, and so forth.

  8. The Instant Messaging server must query LDAP directly to get or set end-user information, such as contact lists or subscriptions.

Instant Messaging With All Features Enabled

You can deploy Instant Messaging and enable all the features listed in this section by installing:

You also need to configure the Access Manager Instant Messaging Service on the Access Manager host.

Instant Messaging Physical Deployment Examples

This section explains variations to the deployment scenario described in Basic Instant Messaging Architecture. For example, you can install the various required servers and components in the following physical configurations:

These variations can be applied in any of the architectures described in this chapter. You might choose to include them based on your deployment requirements.

Instant Messaging Physical Deployment Example: Web Server on Separate Host

Figure 21–9 shows a configuration consisting of the Instant Messaging server and multiplexor installed on the same host. The web server is installed on a separate host. The Instant Messaging resources are also present on the web server host. Use this configuration when there is an existing instance of a web server and an LDAP server, and you do not want to install other applications on these hosts.

Figure 21–9 Separate Web Server and Instant Messaging Hosts

This diagram shows the web server and the Instant Messenger
installed on a separate host.

Instant Messaging Physical Deployment Example: Multiplexors on Separate Hosts

Figure 21–10 shows a configuration consisting of two multiplexors installed on two separate hosts. The Instant Messaging server is installed on a different host. This configuration enables you to place a multiplexor outside your company’s firewall. Installing multiplexors on multiple hosts distributes the load of the Instant Messaging server across multiple systems.


Note –

The multiplexor can be resource-intensive, so putting it on a separate host can improve the overall performance of the system.


Figure 21–10 Instant Messaging Multiplexors Installed on Separate Hosts

This diagram displays several servers: two multiplexors
on separate hosts and an Instant Messaging server on yet a different host.

Instant Messaging Physical Deployment Example: Multiple Instant Messaging Hosts

Figure 21–11 shows a configuration consisting of two Instant Messaging servers. This configuration is used when the site contains multiple administrative domains. The server configuration on each Instant Messaging server host has to be set up so that end users on one Instant Messaging server can communicate with end users on other Instant Messaging servers.

Figure 21–11 Multiple Instant Messaging Server Hosts

This diagram shows a site with two administrative domains.