Sun Java System Instant Messaging 6 2004Q2 Deployment Planning Guide |
Chapter 2
Deployment ExamplesThis 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 JavaTM System 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 DeploymentThis 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
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
The authentication process in a basic deployment works as follows:
- End user accesses the Sun JavaTM System Instant Messenger applet URL from a browser and chooses a method to invoke the client.
- The browser invokes Java Web Start or the Java Plug-in.
- Java Web Start or the Java plug-in downloads the necessary Sun JavaTM System Instant Messenger resource files and starts Instant Messenger.
- 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.
- 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 NotificationThis 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 Java System 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
In this example:
- The LDAP server provides user entries for authentication and lookup.
- The Instant Messaging server forwards messages intended for offline users to the SMTP server. The SMTP server then sends the message as an email to the user’s mailbox.
- The clients download the Instant Messaging resources from a Web server (or Application server).
- Clients always connect to the Instant Messaging server through a multiplexor.
Instant Messaging with Calendar AlertsThis 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 Java System 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 Java System 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
In this example:
- The LDAP server provides user entries for authentication and lookup.
- The Event Notification Server (ENS) sends notifications of calendar events to the Instant Messaging server which then forwards the notification on to the appropriate end user.
- The clients download the Instant Messaging resources from a Web server (or Application server).
- Clients always connect to the Instant Messaging server through a multiplexor.
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 Java System 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 Java System Identity Server in your deployment. In addition, you need to install Sun Java System 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 Java System 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
In this example:
- LDAP Server provides user entries.
- The Web Server (can also be an Application Server, which includes a Web Server) downloads the Instant Messaging resources via a browser to the clients. The Resources are basically the client.
- Clients are always connect through a multiplexor.
- Instant Messaging related services provided by the Identity server include the presence service and the Instant Messaging service.
- The Web server can be used to access the Identity server administration interface which manages the identity based services for the Instant Messaging deployment. The web server for Identity server can be the same as the one that serves the Instant Messaging resources. See the Sun Java System Identity Server documentation for more details.
- Identity Server SDK provides the API used by the Instant Messaging server to interact with the Identity server.
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 Java System Portal Server and Sun Java System 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
The authentication process of the Instant Messaging server in this deployment within a single sign-on environment works as follows:
- The end user logs in to the Sun Java System Identity Server by entering the URL in a web browser.
- The Sun Java System Identity Server 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.
- End user accesses the Sun JavaTM System Instant Messenger applet URL from a browser and chooses a method to invoke the client.
- The browser invokes Java Web Start or the Java Plug-in as appropriate.
- Java Web Start or the Java plug-in downloads the necessary Sun JavaTM System Instant Messenger resource files and starts Instant Messenger.
- Instant Messenger requests authentication to the Instant Messaging server using the session token.
- The Instant Messaging server asks Sun Java System 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.
- 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 Java System Portal Server and Sun Java System 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 Java System 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
In this example:
- LDAP Server provides user entries.
- The Web Server (can also be an Application Server, which includes a Web Server) downloads the IM resources via a browser to the clients. The Resources are basically the client.
- Clients are always connect through a multiplexor.
- The Web Server (can also be an Application Server, which includes a Web Server) downloads the Instant Messaging resources via a browser to the clients. The Resources are basically the client.
- Clients are always connect through a multiplexor.
- Instant Messaging related services provided by the Identity server include the presence service and the Instant Messaging service.
- The Web server can be used to access the Identity server administration interface which manages the identity-based services for the Instant Messaging deployment. The web server for both Identity and Portal servers can be the same as the one that serves the Instant Messaging resources. See the Sun Java System Identity Server and Sun Java System Portal Server documentation for more details.
- Identity Server SDK provides the API used by the Instant Messaging server to interact with the Identity server.
- The Instant Messaging Channel is supported by the Portal server and allows users to access Instant Messenger from Portal Desktop.
- Portal Server provides archive functionality that allows you to save instant messages sent through the deployment.
Authentication in a Deployment With Portal Server
Figure 2-8 illustrates authentication process used by the Instant Messaging software in collaboration with the Sun Java System Portal Server and Sun Java System 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.
The authentication process of the Instant Messaging server in this deployment within a single sign-on environment works as follows:
- The end user logs in to the Sun Java System Portal Server by entering the URL in a web browser.
- The Sun Java System Identity Server software authenticates the end user and returns a session token and the Sun Java System Portal Server downloads the Desktop for the end user. The Sun Java System Portal Server Desktop is displayed in the end user’s browser. See Step 6 for an explanation of the session token.
- The end user clicks the Sun JavaTM System Instant Messenger URL link from the Instant Messaging channel on the Desktop.
- The browser invokes Java Web Start or the Java Plug-in.
- Java Web Start or the Java plug-in downloads the necessary Sun JavaTM System Instant Messenger resource files and starts the Instant Messenger.
- 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.
- The Instant Messaging server asks Sun Java System 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.
- 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 EnabledYou can install Instant Messaging and enable all the features listed in this section. In order to do so, you must use the Sun JavaTM System Messaging, Web, and Directory servers. In addition:
- You will need to install the following servers before you install Instant Messaging:
- You need to install Instant Messaging resources on the web server’s host.
- You need to install Sun Java System Identity Server SDK on the Instant Messaging server’s host.
- You need to install the Identity Server Instant Messaging Service on the Identity Server’s host.
Physical Deployment ExamplesConsider 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.
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.
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.