Sun logo      Previous      Contents      Index      Next     

Sun ONE Instant Messaging 6.1 Deployment Guide

Chapter 2
Deployment Examples

This chapter contains descriptions of Instant Messaging deployment examples. Depending on the features you want to implement in your deployment, you will need to install different sets of servers. For example, to support email notification, you need to install an SMTP server, if you do not want to support email notification, you don’t need the SMTP server. This section describes some deployment options based on feature sets. For information on supported software and versions, see the Sun ONE Instant Messaging Release Notes.

Note

For this release, all deployment options are available on Solaris, and a subset of the options are available on Linux and Windows operating systems.

For more detailed information about servers that interoperate with Instant Messaging, see "Components Related to Instant Messaging". The examples are discussed in the following sections:

Basic Instant Messaging Deployment

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

Figure 2-1 shows what this basic deployment looks like.

Figure 2-1  Basic Instant Messaging Deployment

Illustrates the relationship between components in a basic Instant Messaging deployment

In this example:

Authentication in a Basic Deployment

Figure 2-2 illustrates the interaction of the software components in the authentication process of a basic deployment of Instant Messaging. The focus is on the flow of authentication requests, where the protocols used for requests are indicated above the arrows. The Instant Messaging protocol is a proprietary protocol. An explanation of the steps in this process follow the figure.

Figure 2-2  Flow of Authentication Requests in a Basic Deployment

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

The authentication process in a basic deployment works as follows:

  1. End user accesses the Sun ONE 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 Plug-in.
  3. Java Web Start or the Java plug-in downloads the necessary Sun ONE Instant Messenger resource files and starts Instant Messenger.
  4. The log-in window appears and the end user enters the log-in name and password. The log-in 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.

Instant Messaging With Email Notification

This option provides the same functionality as Basic Instant Messaging Deployment and also supports email notification to offline users. To provide this functionality, you need to include the servers listed in Basic Instant Messaging Deployment and also install an SMTP server such as Sun ONE Messaging Server in your deployment. To enable this feature, 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 2-3 shows Instant Messaging with email notification enabled on the network.

Authentication flow in this deployment is the same as in a basic deployment. For information on authentication flow, see Authentication in a Basic Deployment.

Figure 2-3  Instant Messaging Deployment with Email Notification

Illustrates the relationship between components in an Instant Messaging deployment with email notification enabled

In this example:

Instant Messaging with Calendar Alerts

This option provides the same functionality as Basic Instant Messaging Deployment and also supports Instant Messaging based notification of calendar events to users. To provide this functionality, you need to include the servers listed in Basic Instant Messaging Deployment and also install Sun ONE Calendar Server in your deployment. To enable this feature, you are prompted to identify the Calendar server to use with Instant Messaging during installation. If you do not have a Calendar server installed, you must install one before installing the Instant Messaging software. Figure 2-4 shows Instant Messaging with calendar notification enabled on the network.

See the Sun ONE Calendar Server documentation for more information about that product.

Authentication flow in this deployment is the same as in a basic deployment. For information on authentication flow, see Authentication in a Basic Deployment.

Figure 2-4  Instant Messaging with Calendar Alerts

Illustrates the relationship between components in an Instant Messaging deployment with Calendar event notification enabled

In this example:

Instant Messaging With Identity-based Server Policy Management or Single Sign On

(Solaris only) This option provides the same functionality as Basic Instant Messaging Deployment and also allows you to access and use Sun ONE Identity Server policy features and single sign on. To provide this functionality, you need to include the servers listed in Basic Instant Messaging Deployment and also install Sun ONE Identity Server in your deployment. In addition, you need to install Sun ONE Identity Server SDK on the Instant Messaging server’s host.

In this case, Instant Messaging uses the directory to search for users but not to authenticate or authorize them. Instead, the Sun ONE Identity Server is responsible for authenticating and authorizing users.

Figure 2-5 shows the Identity-based deployment option.

Figure 2-5  Instant Messaging With Identity-based Server Policy Management or Single Sign On

Illustrates the relationship between components in an Instant Messaging deployment with Identity Server

In this example:

Authentication in a Deployment With Identity Server Only

Figure 2-8 illustrates authentication process used by the Instant Messaging software in collaboration with the Sun ONE Portal Server and Sun ONE Identity Server components in a Single Sign-On environment. As with Figure 2-2, this figure focuses on the flow of authentication requests. An explanation of the steps in this process follows the figure.

Figure 2-6  Flow of Authentication Requests in an Identity Server Configuration

Graphic 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 Sun ONE Identity Server by entering the URL in a web browser.
  2. The Sun ONE Identity Server software authenticates the end user and returns a session token.

    3. 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 Sun ONE 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 Plug-in as appropriate.
  5. Java Web Start or the Java plug-in downloads the necessary Sun ONE 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 Sun ONE Identity Server 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 With Portal-based Secure Mode or Archiving and Identity Server

(Solaris only) This option provides the same functionality as Basic Instant Messaging Deployment and also supports message archiving, and allows you to run Instant Messaging in secure mode. In addition, the Instant Messenger client is made available to end users through the Portal Server desktop. To provide this functionality, you need to include the servers listed in Basic Instant Messaging Deployment and also install the Sun ONE Portal Server and Sun ONE Identity Server in your deployment.

In this deployment, use the directory and web servers used by the Identity Server. You do not need to install additional instances of those servers. In addition, because this deployment requires the Sun ONE Identity Server, all the features described in Instant Messaging With Identity-based Server Policy Management or Single Sign On are also available.

Figure 2-7 shows the Portal-based deployment option.

Figure 2-7  Instant Messaging With Portal-based Secure Mode or Archiving

Graphic shows instant messaging when deployed with Portal Server.

In this example:

Authentication in a Deployment With Portal Server

Figure 2-8 illustrates authentication process used by the Instant Messaging software in collaboration with the Sun ONE Portal Server and Sun ONE Identity Server components in a Single Sign-On environment. As with Figure 2-2, this figure focuses on the flow of authentication requests. An explanation of the steps in this process follows the figure.

Figure 2-8  Flow of Authentication Requests in a Portal Server and Identity Server Configuration.

Graphic 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 Sun ONE Portal Server by entering the URL in a web browser.
  2. The Sun ONE Identity Server software authenticates the end user and returns a session token and the Sun ONE Portal Server downloads Portal Server 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 Sun ONE Instant Messenger URL link from the Instant Messaging channel on the Portal Server Desktop.
  4. The browser invokes Java Web Start or the Java Plug-in.
  5. Java Web Start or the Java plug-in downloads the necessary Sun ONE Instant Messenger resource files and starts the Instant Messenger.
  6. Instant Messenger requests authentication to the Instant Messaging server using the session token.

    7. 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 Sun ONE Identity Server 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 With All Features Enabled

You can install Instant Messaging and enable all the features listed in this section. In order to do so, you must use the Sun ONE Messaging, Web, and Directory servers. In addition:

Physical Deployment Examples

Consider the following variations to the basic deployment scenario described earlier. 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 deployment scenarios described in this chapter. You may choose to include them based on your deployment requirements.

Instant Messaging Server and Web Server on Separate Hosts

Figure 2-9 shows a configuration where the Instant Messaging server and multiplexor are installed on the same host, and 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 2-9  The Web Server and Instant Messaging Installed on Separate Hosts.

The web server and the Instant Messenger installed on a separate host

Multiple Multiplexors on Separate Hosts

Figure 2-10 shows a configuration of two multiplexors installed on separate hosts, and the Instant Messaging server 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.

Windows supports only one multiplexor instance per host.

Figure 2-10  Instant Messaging Multiplexors Installed on Separate Hosts.

This figure displays several servers, including two multiplexors installed on separate hosts and an Instant Messaging server installed on yet a different host.

Federation of Multiple Instant Messaging Deployments

Figure 2-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 2-11  Multiple Instant Messaging Server Hosts.

This figure shows a site with two administrative domains.



Previous      Contents      Index      Next     

Copyright 2004 Sun Microsystems, Inc. All rights reserved.