test

Sun Java System Communications Services 6 2005Q4 Deployment Planning Guide

Part IV Deploying Instant Messaging

This part contains the following chapters:

Chapter 21 Introduction to Instant Messaging Software

Instant Messaging enables secure, real-time communication and collaboration, combining presence awareness with instant messaging capabilities such as chat, conferences, alerts, news, polls, and file transfers to create a rich collaborative environment. These features enable one-to-one as well as group collaboration through either short-lived communications or persistent venues such as conference rooms or news channels.

Instant Messaging ensures the integrity of communications through its multiple authentication mechanisms and Secure Sockets Layer (SSL) connections. Integration with Portal Server and Access Manager brings additional security features, services-based provisioning access policy, user management, and secure remote access.

This chapter contains the following sections:

What Is an Instant Messaging Service?

At a simplistic level, an instant messaging service:

In addition, an instant messaging service can provide real-time conferencing, news and calendar alerts, and for offline users, email message forwarding.

Of crucial importance to a good instant messaging service is that the service provides for scalability, high availability, reliability, and good performance.

Instant Messaging Core Product Components

Instant Messaging contains the following core components:

Components Related to Instant Messaging

The software components discussed in this section work with Instant Messaging server, but are installed separately. Chapter 23, Developing an Instant Messaging Architecture provides more detailed information that illustrates how these servers interact with Instant Messaging.

Web Server

(Required) For any deployment, you need to install a web server, such as Sun Java System Web Server or Sun Java System Application Server. You can also use any open standard web server (for example, Apache). In all cases, the Instant Messenger resources must reside on the web server host.

Instant Messaging requires a web server to serve the Instant Messenger resources. The Instant Messenger resource files include:

You must install Instant Messenger resources on the same host where the web server is installed. In an Access Manager deployment, you can install these resources on the Access Manager server’s host or on a different web server host. In most cases, the resources will be installed on the same host where you installed the Instant Messaging server software. It is possible to locate the Instant Messenger resources on a host other than the Instant Messaging server or multiplexor.

Note –

Install the web server before configuring Instant Messaging.

LDAP Server

(Required) Instant Messaging uses an LDAP server, such as Directory Server, for end user authentication and search. In a deployment with Portal Server, Instant Messaging uses the same LDAP server used by Portal Server. If you do not have an LDAP directory already installed, you must install one.

The Instant Messaging server does not store the Instant Messenger end-user authentication information. This information is stored in the LDAP server.

By default, the Instant Messaging server relies on the common end-user attributes cn and uid to search for end-user and group information. If you want, you can configure the server to use another attribute for search. In addition, Instant Messaging properties (such as contact lists and subscriptions) can be stored in files on the Instant Messaging server or in the LDAP server.

For instructions on configuring the server to use a non-default attribute for user search, see the Sun Java System Instant Messaging 7 2005Q1 Administration Guide.

Note –

Because a proper Directory Server implementation is instrumental to a successful Instant Messaging deployment, read the Sun Java System Directory Server 5 2005Q1 Deployment Plannning Guide in addition to this guide.

SMTP Server

(Optional) An SMTP messaging server, such as Messaging Server, is used to forward instant messages, in the form of email, to end users who are offline. The SMTP server does not have to reside on the same host as the Instant Messaging server.

Calendar Server

(Optional) Calendar Server is used to notify users of calendar-based events.

Access Manager and Access Manager SDK

(Optional) Access Manager and Access Manager SDK provide end user and service management, authentication and single sign-on services. In addition, Access Manager and Access Manager SDK are required in deployments that include Portal Server. In both deployments, the SDK must be installed on the Instant Messaging server’s host.

Portal Server

(Optional) Portal Server supports message archiving, and enables 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. The following two Portal Server components provide additional functionality:

Portal Server Desktop

Instant Messenger installed in the Portal Server environment can be launched from the Instant Messaging channel available to end users on Portal Server Desktop.

Secure Remote Access

Secure Remote Access enables remote end users to securely access their organization’s network and its services over the Internet. The end user can access Secure Remote Access by logging into the web-based Portal Server Desktop through the portal gateway. The authentication module configured for Portal Server authenticates the end user. The end-user session is established with Portal Server and the access is enabled to the end user’s Portal Server Desktop.

In the Portal Server environment, you can configure Instant Messenger in either secure or non-secure mode. In secure mode, communication is encrypted through the Portal Server Netlet. When access Instant Messenger in secure mode, a lock icon appears in the Status area of the Instant Messenger application. In non-secure mode, the Instant Messenger session is not encrypted. For more information on Netlet, see the Sun Java System Portal Server 6 Secure Remote Access Administration Guide 2004Q2.

Instant Messaging Supported Standards

Instant Messaging is built on native Internet technology, so you can maintain a single architecture inside and outside your organization, even when collaborating with your customers and partners. Additionally, you aren’t locked into a proprietary system. All key components of Instant Messaging are based on proven, open Internet standards such as:

Instant Message Structure Format

XMPP protocol is used to format the instant messages. The message bodies themselves may be wrapped in HTML.

Access Protocol

In Instant Messaging, user information and preferences are retrieved from an LDAP directory. This directory can either be dedicated for use by Instant Messaging, or be shared by other components such as Access Manager or Portal Server. User data is typically retrieved using LDAP search functions. Instant Messaging deployments that make use of Access Manager and Portal Server make use of the same LDAP server.

Communication and Message Transfer Protocols

Instant Messaging server-to-server and client-to-server communications occur over TCP/IP.

Instant Messaging uses SMTP to send messages to offline users.

Browsers use HTTP to retrieve Instant Messenger resource files from the Web server. Once retrieved, the browser reads the HTML and displays the contents of the files.

Instant Messaging 7 is an XMPP/Jabber client/server solution, able to communicate with XMPP-compliant servers, clients, and gateways. Gateways are available in the open-source community to enable communication between Jabber and AOL, Yahoo, and other instant messaging systems.

Instant Messaging Software Architecture

Figure 21–1 shows the Instant Messaging software architecture.

Figure 21–1 Instant Messaging Software Architecture

This diagram the relationship between components in Instant Messaging.

The web server (or an application server with a web service embedded), downloads the Instant Messaging resources from a browser to the clients. The resource files make up the client. Clients send messages to one another through a multiplexor, which forwards the messages to the Instant Messaging server.

The directory server stores and retrieves local user and group delivery information such as preferences, location, and to which multiplexor to route messages for this user. When the Instant Messaging server receives a message, it uses this information to determine where and how the message should be delivered. In addition, the directory server can contain user information such as contact lists and subscriptions.

In this basic configuration, Instant Messaging directly accesses Directory Server to verify user login name and passwords for mail clients that use Instant Messaging.

Outgoing instant messages from clients go directly to the multiplexor. The multiplexor sends the message to the appropriate Instant Messaging server, which in turn forwards the message to another Instant Messaging server, or if the message is local, to the multiplexor with which the recipient is associated. (See Instant Messaging Physical Deployment Examples for illustrations of this process.)

New users are created by adding user entries to the directory. Entries in the directory can be created or changed by using the tools provided with the directory server.

Instant Messaging components are administered through a set of command-line interfaces and text-based configuration files. Any machine connected to the Instant Messaging host can perform administrative tasks (assuming, of course, the administrator has the required privileges).

Note –

Typical Instant Messaging deployments are not installed on a single machine. They also have additional features like multiplexing and high availability enabled. See Chapter 23, Developing an Instant Messaging Architecture for more information.

The following sections outline the three primary components of Instant Messaging in further detail:

Instant Messaging Server

The Instant Messaging server handles tasks such as controlling Instant Messenger privileges and security, enabling Instant Messenger clients to communicate with each other by sending alerts, initiating chat conversations, and posting messages to the available news channels. The Instant Messaging server also handles archiving, calendar alerts, and offline email notifications

The Instant Messaging server supports the connection of a multiplexor that consolidates connections over one socket. For more information on the multiplexor, see Instant Messaging Multiplexor.

Access control files and Access Manager policies are used for administration of end users, news channels, and conference rooms.

The Instant Messaging server routes, transfers, and delivers instant messages for the Instant Messaging product.

Direct LDAP Lookup

The server can look up directory information directly from the LDAP server. The results of the LDAP queries are cached in the process, with configurable aging and expiration, so settings are tunable. Refer to the Sun Java System Directory Server 5 2005Q1 Administration Guide for further information.

Message Delivery

After the message is processed, the server sends the message to the next stop along the message’s delivery path. This can be the intended recipient’s multiplexor or another server. Once received by a multiplexor, the message is routed directly to the intended recipient. See Basic Instant Messaging Architecture for an illustration of this process.

Instant Messaging Multiplexor

The Instant Messaging multiplexor component connects multiple instant messenger connections into one TCP (Transmission Control Protocol) connection, which is then connected to the Instant Messaging server. The multiplexor reads data from Instant Messenger and writes it to the server. Conversely, when the server sends data to Instant Messenger, the multiplexor reads the data and writes it to the appropriate connection. The multiplexor does not perform any end user authentication or parse the client-server protocol (IM protocol). Each multiplexor is connected to one and only one Instant Messaging server.

You do not need to install the Instant Messaging multiplexor, that is, you can configure Instant Messaging without a multiplexor. However, production deployments should be configured to use the multiplexor.

You can install multiple multiplexors based on your deployment requirements. For more information, see Chapter 23, Developing an Instant Messaging Architecture.

Instant Messenger Client

Instant Messenger is Instant Messaging’s client that can be configured to be a browser-based applet using Java plugin, or a standalone Java application using JavaTM Web Start.

To run Instant Messenger client on Solaris or Linux, you must use Java Web Start. On Microsoft Windows you can run Instant Messenger as an applet or a Java Web Start application. In most cases, run Instant Messenger as a Java Web Start application.

For more information on customizing Instant Messenger, see the Sun Java System Instant Messaging 7 2005Q1 Administration Guide.

Instant Messenger provides the following modes of communication:

Note –

Instant messages can contain embedded URLs. If you are using proxy servers, you might need to have clients using Java Web Start modify their proxy configuration for resolving such URLs.

For more information on configuring the proxy settings manually, see the Sun Java System Instant Messaging 7 2005Q1 Administration Guide.

Designing Your Instant Messaging Deployment

The deployment process consists of the following general phases, referred to as the Solution Life Cycle:

The deployment phases are not rigid: the deployment process is iterative in nature.

For detailed information on the deployment process for Instant Messaging, and other Java Enterprise System components, see the Sun Java Enterprise System 2005Q4 Deployment Planning Guide.

Chapter 22 Planning an Instant Messaging Sizing Strategy

This chapter introduces the concepts, context, and rationale of sizing your Instant Messaging deployment.

This chapter contains the following sections:

Instant Messaging Sizing Strategy Overview

When you design your deployment, you must decide how to configure your Instant Messaging server to provide optimum performance, scalability, and reliability.

Sizing is an important part of the design effort. The sizing process enables you to identify what hardware and software resources are needed so that you can deliver your desired level of service or response time according to the estimated workload that your Instant Messaging server users generate. Sizing is an iterative effort.

Because each deployment has its own set of unique features, this chapter will not provide detailed Instant Messaging sizing information for your specific site. Also, this chapter will not provide sizing information for servers with which Instant Messaging interoperates, such as LDAP, SMTP, and so on. Rather, this chapter explains what you need to consider when you architect your sizing plan. In addition, you’ll find general guidelines for Instant Messaging components you can modify to suit your site’s needs. Work with your Sun technical representative for your deployment hardware and software needs.

Collecting Instant Messaging Sizing Data

Use this section to identify the data you need to size your Instant Messaging deployment. The following topics are covered in this section:

Determining Peak Volume of Unique Instant Messaging Logins

Your peak volume is the largest concentrated numbers of unique logins to your Instant Messaging system within a given period in a day. The volume can vary from site to site as well as across different classes of users. For example, peak volume among groups might occur during corporate-held core hours which differ between time zones.

Analyzing peak volume involves three basic operations:

  1. Determining when and for how long the peaks occur

  2. Sizing your deployment against peak volume load assumptions

    Once patterns are analyzed, choices can be made to help the system handle the load and provide the services that users demand.

  3. Making sure that your Instant Messaging deployment can support the peak volume that you have determined

Creating Your Instant Messaging Usage Profile

Measuring your load is important for accurate sizing. Your usage profile determines the factors that programs and processes place on your Instant Messaging servers and multiplexors.

This section helps you create your usage profile to measure the amount of load that is placed on your deployment.

Creating a usage profile involves answering the following questions:

  1. What is the total number of users on your system?

    When counting the number of users on your system, account for not only the users who have accounts and can log into the system, but also the users with accounts who are currently not logged into the system. The following table describes the types of users that make up the total.

    Connection  

    Description  

    Inactive User 

    A user with an Instant Messaging account who currently is not logged into the system. Non-connected users consume disk space but no CPU or memory. 

    Connected/Inactive 

    These users are logged in, but are not currently sending or receiving instant messages. 

    Connected/Active 

    Logged into the system and actively sending messages, updating user information such as contact lists, and attending conferences throughout the day. 

    Characterize your configured users using these three general profiles. The total of these users should give you an idea of the total number of concurrent connections you need to support.

    If you have a small deployment, the defaults might be sufficient to meet your site’s needs. So, if you have a very small deployment (for example, less than 300 users), you might not need to go through this process of planning a sizing strategy. Work with your Sun Client Services representative to determine your individual needs.

  2. How many connections are on your system during your peak volume?

    Correctly formulating the maximum number of concurrent users that has to be sustained by the system is key to planning your resource requirements. Although a deployment usually has maximum number of configured users, it is important to plan for the maximum number of concurrent users (connected and more or less active). A conservative estimate for the number of concurrent users can then be determined based on a 1:10 ratio. Thus, for a deployment of 50,000 configured users, the concurrent users would be 5,000.

    Specifically, note the number of concurrent connections, idle, and busy connections.

    Connection  

    Description  

    Concurrent Connection 

    Number of unique TCP connections or sessions that are established on your system at any given time. 

    Idle Connection 

    Connection where no information is being sent between the client and multiplexor or server and multiplexor. 

    Busy Connection 

    A connection that is in progress. An established connection where information is being sent between the client and multiplexor or multiplexor and server. 

    To determine the number of concurrent connections in your deployment, you can count the number of established TCP connections by using the netstat command on Solaris platforms.

    To determine the number of concurrent connections you can support, you need to obtain two values from parameters within the iim.conf file that are used for tuning multiplexor performance:

    1. iim_mux.numinstances - Specifies the number of multiplexor instances.

    2. iim_mux.maxsessions - Specifies the maximum number of clients that one mutliplexor process can handle. The default is 1000.

    Once you have obtained these values, multiply the numinstances number by the maxsessions number. This gives the total number of concurrent connections supported by your deployment. For information on the iim.conf file, see the Sun Java System Instant Messaging 7 2005Q1 Administration Guide.

  3. If you have a large deployment, how will you organize your users?

    For example, consider placing active users on one server and inactive users on another.

  4. What is the amount of storage used for each user?

    If you are not storing your end user data, such as contact lists, in LDAP, you need to plan for the space required to store this data. If you configure the server to store this data outside LDAP, the server stores it in a flat file. See the Sun Java System Instant Messaging 7 2005Q1 Administration Guide for more information.

  5. How many messages enter your Instant Messaging system from the Internet?

    The number of messages should be measured in messages per second during your peak volume.

  6. How many messages are sent by your users to:

    • End users on your system?

    • The Internet?

    This number of messages is also measured in messages per second during the peak volume.

  7. Will you be using SSL? If yes, what percentage of users and what type of users?

    For example, in a particular organization, 20% of connections during peak hours will enable SSL.

Answering these questions provides a preliminary usage profile for your deployment. You can refine your usage profile as your Instant Messaging needs change.

Additional Questions

While the following questions are not applicable to creating your usage profile, they are important to developing your sizing strategy. How you answer these questions might require you to consider additional hardware.

  1. How much redundancy do you want in your deployment?

    For example, do you need to consider high availability.

  2. What backup and restore strategy do you have in place (such as disaster recovery and site failover)? What are the expected times to accomplish recovery tasks?

    Typically you need to back up the server configuration files, database, and any resource files you have customized.

Defining Your Instant Messaging User Base or Site Profile

Once you establish a usage profile, compare it to sample pre-defined user bases that are described in this section. A user base is made up of the types of Instant Messaging operations that your users will perform. Instant Messaging users fall into one of these user bases:

The sample user bases described in this section broadly generalize user behavior. Your particular usage profile might not exactly match the user bases; you will be able to adjust these differences when you run your load simulator (as described in Using an Instant Messaging Load Simulator).

Casual Users

A lightweight user base typically consists of users with simple Instant Messaging requirements. These users rarely initiate chat sessions and rarely receive invitations. They might only use Instant Messaging as a presence tool.

Heavy Users

A heavy user uses significantly more system resources than a casual user. Typical usage for a this type of user may be something like the following:

Using an Instant Messaging Load Simulator

To measure the performance of your Instant Messaging architecture, use your user bases (described in Defining Your Instant Messaging User Base or Site Profile) and your usage profile (described in Creating Your Instant Messaging Usage Profile) as inputs into a load simulator.

A load simulator creates a peak volume environment and calibrates the amount of load placed on your servers. You can determine if you need to alter your hardware, throughput, or deployment architecture to meet your expected response time, without overloading your system. Using a load simulator involves five basic steps:

  1. Defining the user base that you want to test (for example, casual users)

    If necessary, adjust individual parameters to best match your usage profile.

  2. Defining the hardware that will be tested

  3. Running the load simulator and measuring the maximum number of concurrent connections on the tested hardware with the user base

  4. Publishing your results and comparing those results with production deployments

  5. Repeating this process using different user bases and hardware until you get the response time that is within an acceptable range for your organization under peak load conditions

Note –

Contact Sun Client Services for recommended load simulators and support.

Understanding Instant Messaging System Performance Guidelines

Once you evaluate your hardware and user base with a load simulator, you need to assess your system performance. The topics in this section address methods by which you can improve your overall system performance.

Instant Messaging Memory Utilization

Make sure you have an adequate amount of physical memory on each machine in your deployment. Additional physical memory improves performance and enables the Instant Messaging server to operate at peak volume. With sufficient memory, Instant Messaging can operate efficiently without excessive swapping.

For most deployments, you need at least 256 MB of RAM. The amount of RAM needed depends on the number of concurrent client connections, and whether the server and multiplexor are deployed on the same host. For information about concurrent connections, see Creating Your Instant Messaging Usage Profile. For information on hosting the server and multiplexor on the same host, see Developing Instant Messaging Architectural Strategies.

On Solaris systems, you can set the amount of memory allocated to the server by modifying the iim.jvm.maxmemorysize parameter in the iim.conf file. This parameter specifies the maximum number of megabytes of memory that the Java Virtual Machine (JVM) running the server is allowed to use. The default setting is 256 MB, and the maximum setting is 500 MB. For instructions on modifying this parameter, see the Sun Java System Instant Messaging 7 2005Q1 Administration Guide.

You cannot currently change this value on Windows NT systems.

Instant Messaging Disk Throughput

Disk throughput is the amount of data that your system can transfer from memory to disk and from disk to memory. The rate at which this data can be transferred is critical to the performance of Instant Messaging. To improve efficiency in your system’s disk throughput:

Instant Messaging Disk Capacity

When planning Instant Messaging server system disk space, be sure to include space for operating environment software, Instant Messaging software, and for any servers not currently in your network that need to be installed to support Instant Messaging (such as LDAP). Be sure to use an external disk array. In addition, user disk space needs to be allocated. Typically, this space is determined by your site’s policy. Typical installations will require:

Use Table 22–1 to determine server and multiplexor disk space sizing numbers whether archiving is enabled or disabled. The figures listed in the table were generated using a 400MHz Ultra SPARC II Processor.

Table 22–1 Instant Messaging Server and Multiplexor Memory Disk Space Sizing for Concurrent Users

 

Server Memory Consumption for Connected/Inactive Users  

Server Memory Consumption for Connected/Active Users  

Multiplexor Memory Consumption for Connected/Inactive Users  

Multiplexor Memory Consumption for Connected/Active Users  

Archive Disabled 

8 MB +20 K per User 

120 MB + 20 K per User 

8 MB + 20 K per User 

8MB + 28K per User 

SSO/Portal/Archive enabled 

100MB +25K per User 

120MB +30K per User 

8M+35K per user 

8 MB +40K per user 

Instant Messaging Network Throughput

Network throughput is the amount of data at a given time that can travel through your network between your client application and server. When a networked server is unable to respond to a client request, the client typically retransmits the request a number of times. Each retransmission introduces additional system overhead and generates more network traffic.

Improving data integrity, system performance, and network congestion reduces the number of retransmissions. Steps to do this involve:

Instant Messaging CPU Resources

Enable enough CPU for your servers and multiplexing services. In addition, enable enough CPU for any RAID systems that you plan to use. If you intend to use archiving in your deployment, you need to take those space requirements into consideration as well.

Use Table 22–2 to help determine the number of CPUs your installation requires for optimum performance whether archive is enabled or disabled. The figures listed in the table were generated using a 400MHz Ultra SPARC II Processor.

Table 22–2 Instant Messaging CPU Utilization Numbers

 

Server CPU Utilization for Connected/Inactive Users  

Server CPU Utilization for Connected/Active Users  

Multiplexor CPU Utilization for Connected/Inactive Users  

Multiplexor CPU Utilization for Connected/Active Users  

Archive Disabled 

Several hundred thousand users per CPU 

30 K users per CPU 

50 K users per CPU 

5 K users per CPU 

Instant Messaging Multiplexor Configuration Best Practices

Consider the following suggestions and generalizations when planning your multiplexor deployment. The parameters discussed in this section are located in the iim.conf file.

See the Sun Java System Instant Messaging 7 2005Q1 Administration Guide for more detailed information about these parameters.

Developing Instant Messaging Architectural Strategies

Once you have identified your system performance needs, the next step in sizing your Instant Messaging deployment is to size specific components based on your architectural decisions.

The topics in this section point out sizing considerations when you deploy two-tiered and one-tiered architectures. Using load balancers with Instant Messaging is also discussed.

Two-tiered Instant Messaging Architecture

A two-tiered architecture splits the Instant Messaging server deployment into two layers: an access layer and a data layer. In a simplified two-tiered deployment, you might add one or more multiplexors and servers to the access layer. The multiplexor acts as a proxy for users, and the relays messages to the Instant Messaging server. The data layer holds the Instant Messaging server database and Directory servers. Figure 22–1 shows a simplified two-tiered Instant Messaging architecture.

Figure 22–1 Simplified Two-tiered Instant Messaging Architecture

This diagram shows a simplified two-tiered Instant Messaging architecture.

Two-tiered architectures have advantages over one-tiered architectures that can impact your sizing decisions. Two-tiered architectures:

Sizing Your Multiplexing Services

When you size your multiplexor, the calculation is based on your system load, particularly the number of concurrent connections the multiplexor needs to handle.

In addition, you must:

  1. Add CPU or a hardware accelerator for SSL if appropriate.

  2. Add memory to the machine if the multiplexor is being configured on it.

  3. Account for denial of service.

  4. Add capacity for load balancing and redundancy, if appropriate.

One or more of each type of machine should still handle peak load without a substantial impact to throughput or response time when you plan for redundancy in your deployment.

One-tiered Instant Messaging Architecture

In a one-tiered architecture, there is no separation between access and data layers. The Instant Messaging server, multiplexor, and sometimes the Directory server are installed in one layer. The following figure illustrates the idea.

Figure 22–2 Simplified One-tiered Instant Messaging Architecture

This diagram shows a simplified one-tiered deployment for Instant Messaging server, a Directory Server, a multiplexor, and end users.

One-tiered architectures have lower up-front hardware costs than two-tiered architectures. However, if you choose a one-tiered architecture, you need to allow for significant maintenance windows.

To size a one-tiered architecture:

  1. Add CPU for SSL, if necessary.

  2. Account for denial of service attacks.

  3. Add more disks for the increased number of client connections.

  4. Add more disks for each multiplexor.

For specific instructions on sizing Instant Messaging components in one-tiered or two-tiered architectures, contact your Sun Client Services representative.

Using Load Balancers With Instant Messaging

Instant Messaging supports the use of load balancers located in front of the Instant Messaging multiplexors. However, you cannot currently use load balancers between the Instant Messaging multiplexors and the Instant Messaging server.

When deploying Instant Messaging as part of a Portal Server/Secure Remote Access deployment, you can locate load balancers between the Secure Remote Access gateway and the Instant Messaging multiplexors.

Note –

If you just need security for the client connection, and not HTTP tunneling, consider using SSL instead of Secure Remote Access. You can configure a secure Instant Messaging client connection by enabling SSL on the multiplexors and locating them outside the firewall.

Example Instant Messaging Resource Requirements

This section provides example resource distributions and recommended sizing information for the following two Instant Messaging deployment types:

Small Deployment Sample Resource Requirements Numbers

For a small Instant Messaging deployment with the server and multiplexor on a single server having 10,000 users with the following profile:

The memory requirements are: one or two CPUs with 300-500 MB RAM each.

Large Deployment Sample Resource Requirements Numbers

For a large Instant Messaging deployment having 1,000,000 users with the following profile:

The server memory requirements are 4 GB RAM on two CPUs. The multiplexor requirement is 4 GB RAM on 16 CPUs.

Chapter 23 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 the Solaris platform. A subset of the deployment options is available on Linux and Windows operating systems.

Basic Instant Messaging Architecture

Figure 23–1 shows the basic Instant Messaging architecture.

Figure 23–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 23–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 23–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 23–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 23–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 23–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 23–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 inBasic 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.

If you are planning on using SSO with Access Manager, you must configure Access Manager and Instant Messaging to use the same web container.

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

Figure 23–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 23–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 23–2, this figure focuses on the flow of authentication requests. An explanation of the steps in this process follows the figure.

Figure 23–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 run Instant Messaging in secure mode. 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 23–7 shows the Instant Messaging Portal-based architecture.

Figure 23–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 23–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 23–2, this figure focuses on the flow of authentication requests. An explanation of the steps in this process follows the figure.

Figure 23–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 23–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 23–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 23–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.

Windows supports only one multiplexor instance per host.

Figure 23–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 23–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 23–11 Multiple Instant Messaging Server Hosts

This diagram shows a site with two administrative domains.

Chapter 24 Understanding Instant Messaging Pre-Installation Considerations

This chapter describes considerations you need to think about before installing Instant Messaging. See the Sun Java Enterprise System 2005Q4 Installation Guide for UNIX for instructions on running the Java Enterprise System installer.

This chapter contains the following sections:

Installing Instant Messaging Overview

To install Instant Messaging on a Solaris system, you use the Java Enterprise System installer. On Linux and Windows systems, you use the setup program included in the Linux and Windows Media Kit CD. Optionally, you can download the software from the following site:

http://www.sun.com/software/download

The Java Enterprise System and Instant Messaging documentation provide procedures and tools for completing and upgrading your installation, for configuring your servers, setting up clients, and so on. For more information on these additional installation and configuration steps, see the following:

Sun Java Enterprise System 2005Q4 Installation Guide for UNIX

Sun Java Enterprise System 2005Q4 Upgrade Guide

Sun Java System Instant Messaging 7 2005Q1 Administration Guide

Before you begin an installation, see Chapter 3, Sun Java System Instant Messaging 7 2005Q4 Release Notes, in Sun Java System Communications Services 2005Q4 Release Notes for hardware and software requirements and supported versions:

Prior to installing Instant Messaging, you need to install a directory server, web server, and optionally a messaging server. On Solaris systems, you might also need to install Access Manager and Portal Server if you intend to use functionality provided by those servers with Instant Messaging. Interoperating with other servers is described in Components Related to Instant Messaging. In addition, Chapter 23, Developing an Instant Messaging Architecture provides some architectures that you can follow to enable various Instant Messaging features.

Instant Messaging Worksheets

During installation and upgrade, you will be prompted for basic configuration information. You should gather this information before you begin. You will be prompted for some or all of the information depending on the components you decide to install.

Print out Table 24–1 and write the values for your deployment in the space provided. You can reuse this installation worksheet for multiple installations, uninstallation, or for upgrades. This table contains passwords and other sensitive information, so you should store this information in a safe place.

Table 24–1 Instant Messaging Installation Parameters

Parameter  

Description  

Your Answers  

Installation Directory

instant-messaging-install-dir or installation directory.

Directory in which Instant Messaging is installed. 

Defaults: 

Solaris system: /opt/SUNWiim

Linux system: /opt/sun/im

Windows system: C:\Program Files\Sun\Instant Messaging

 

Instant Messaging Server Host and Domain Name

Host name on which Instant Messaging is installed and the domain name associated with the host. For example: 

Host Name: instantmessaging.siroe.com

Domain Name: siroe.com

 

Instant Messaging Server Port Number

The port number on which the Instant Messaging server listens for incoming requests other than those sent by Instant Messenger clients. 

Default: 49999 

 

Multiplexor Port Number (Multiplexor Configuration Only)

The port number on which the Instant Messaging server listens for incoming requests from Instant Messenger clients. 

Default: 49909 

 

Disable Server

Select this option if the instance you installed will act as a multiplexor and not a server. If you select this option, you must provide a value for Remote Instant Messaging Server Host Name (Multiplexor Configuration Only) 

 

Remote Instant Messaging Server Host Name (Multiplexor Configuration Only)

The host name of the Instant Messaging server for which this multiplexor routes messages. Do not enter a value for this parameter if the installed instance you are configuring is an Instant Messaging server and not a multiplexor. 

Dependencies: The Disable Server parameter must be selected, that is, server functionality is disabled. 

 

Assign Instant Messaging Services to existing users (Optional)

If selected, this option enables Instant Messaging for existing Access Manager users. 

Dependencies: Portal Server and Access Manager. 

 

Secure Mode (Optional)

When selected, enables integration with Portal Server Secure Remote Access. 

Secure Remote Access provides secure access to remote users in an intranet. Users can access Secure Remote Access by logging in to the web-based Portal Server Desktop through the portal gateway.

Dependencies: 

Requires Portal Server and Access Manager. 

You can run Instant Messaging in secure mode only if Secure Remote Access is configured. See the Sun Java System Instant Messaging 7 2005Q1 Administration Guide and the Sun Java System Portal Server 6 Secure Remote Access Administration Guide 2004Q2 for instructions.

If you enable this feature, you must provide values for the following parameters: 

  • Netlet Instant Messaging Port Number (Optional)

  • Messenger Secure Download Port (Optional)

 

Netlet Instant Messaging Port Number (Optional)

If you enabled Secure Mode (Optional), this is the port number on which Netlet listens for incoming requests. 

Default: 49917 

Dependencies: Secure Mode (Optional) enabled, Portal Server, and Access Manager. 

 

Messenger Secure Download Port (Optional)  

If you enabled Secure Mode (Optional), this is the port number from which Instant Messenger resources will be downloaded through Netlet. 

Default: 49916 

Dependencies: Secure Mode (Optional) enabled, Portal Server, and Access Manager. 

 

Enable Instant Messaging Archive (Optional)  

If selected, enables Portal Server search-based archiving for Instant Messaging. 

Dependencies: Portal Server and Access Manager. 

 

LDAP Host Name  

The host name of the LDAP server that contains user and group information for Instant Messaging. For example, directory.siroe.com.

Dependencies: LDAP server such as Directory Server. 

 

LDAP Port Number  

The port number on which the directory server listens for incoming requests. For example, 389.

Dependencies: LDAP server such as Directory Server. 

 

Base DN  

The base distinguished name in the directory tree that contains user and group information for Instant Messaging. For example, o=siroe.com.

Dependencies: LDAP server such as Directory Server. 

 

Bind DN  

During installation, you must use the Directory Manager Bind DN and password. The information is used to update the directory schema with the Instant Messaging and presence service templates and attributes only. This requires Directory Manager access. The Directory Manager Bind DN and password are not saved or used beyond installation and initial configuration. 

For server configuration, Instant Messaging uses this Bind DN to search users and groups in the directory. Leave this blank if the directory can be searched anonymously. 

Dependencies: LDAP server such as Directory Server. 

 

Bind Password  

The Bind DN password. 

 

SMTP Server Host Name (Optional)  

The host name of the SMTP server used to send email notification of messages to offline users. For example, mail.siroe.com. If the SMTP server does not use port 25, specify the port along with the host name. For example, if the SMTP server uses port 1025:

mail.siroe.com:1025

Dependencies: SMTP server such as Messaging Server. 

 

Database, Logs, and Runtime File Pathname  

The location where the runtime files, database, and logs are stored. 

Defaults: 

Solaris system: /var/opt/SUNWiim/default

Linux system: /var/opt/sun/im

Windows system: C:\Program Files\Sun\Instant Messaging

 

Resources and Help Files Pathname  

instant-messaging-resource-directory or resource directory

The directory in which the resource and online help files are installed. 

Defaults: 

Solaris system: /opt/SUNWiim/html

Linux system: /opt/sun/im/html

Windows system: C:\Program Files\Sun\Instant Messaging\html

 

Code Base  

The URL from which Instant Messenger downloads resources.

You install the resources into the web server’s doc root. For example, assume that the web server www.example.com listens on port 89, the doc root for this web server is /opt/web/, and you choose to install the messenger resources in /opt/web/im, then the messenger resources codebase is as follows:

http://www.example.com:89/im/

If you do not provide the correct codebase during installation, you need to update the messenger launch pages codebase/lang/im[ssl].html and codebase/lang/im[ssl].jnlp with the correct URL.

On UNIX, it is possible to install the resources in a directory and use a symbolic link to make the resources visible to the web server. 

For instance, if in the above example you installed the resources in /opt/SUNWiim/html, the messenger resources can be made visible to the web server by creating the following symbolic link.

ln -s /opt/SUNWiim/html /opt/web/im

See the Sun Java System Instant Messaging 7 2005Q1 Administration Guide, and your web server documentation for more information.