Figure 19–1 shows the Instant Messaging software architecture.
The web server (or an application server with a web service embedded), downloads the Instant Messenger 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 through Instant Messaging Server (by enabling new-user registration feature) 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).
Typical Instant Messaging deployments are not installed on a single machine. They also have additional features like multiplexing and high availability enabled. See Chapter 21, Developing an Instant Messaging Architecture for more information.
The following sections outline the three primary components of Instant Messaging in further detail:
The Instant Messaging server handles tasks such as maintaining presence information for each user, 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.
The Instant Messaging server routes, transfers, and delivers instant messages for the Instant Messaging product.
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 Directory Server documentation for further information.
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.
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.
Although you can configure Instant Messaging without a multiplexor, production deployments should be configured to use the multiplexor. You can install multiple multiplexors based on your deployment requirements. For more information, Chapter 21, Developing an Instant Messaging Architecture.
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.2 Administration Guide.
Chat. Instant Messenger’s version of Instant Messaging conferences is called chat. Chat is a real-time conversation capability that enables end users to complete projects, answer customer queries, and complete other time-critical assignments. Chat sessions (two or more participants) are held in chat rooms created on a need basis.
Alerts. Alerts enable information delivery and response to end users through the Instant Messenger interface. Alerts can deliver time-critical information to the end user. The sender of the alert message is notified when the message is delivered and read by the recipient. You can also configure Instant Messaging to forward alerts to an email address.
Poll. The polling function enables you to ask end users for their response to a question. You can send a question and possible answers to poll recipients, and the recipients can respond with their selected answer.
News. News channels are forums for posting and sharing information. End users can subscribe to news channels of interest to see updates using the URL of the news channels or view the news channel updates through static messages. Administrators control news channel access by assigning end users to the channels they need, and deciding who can see or post information to the channels.
For more information on configuring the proxy settings manually, see the Sun Java System Instant Messaging 7.2 Administration Guide.