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:
At a simplistic level, an instant messaging service:
Accepts instant messages from external sites
Determines the user to which the message should be delivered, and routes it accordingly
Accepts instant messages from internal hosts
Determines the destination system to which the message should be delivered, and routes it accordingly
Provides presence updates for users who are online, offline, away, and so on
Of crucial importance to a good instant messaging service is that the service provides for scalability, high availability, reliability, and good performance.
Instant Messaging contains the following core components:
Instant Messenger Resources (client). A set of files that makes up the client program for end users to initiate, compose, and reply to messages. Typically users also use the client to participate in conferences. The client is also called Sun Java System Instant Messenger.
Instant Messaging Server. An electronic message delivery system that supports instant message delivery from one system to another system. The server serves the presence information to Instant Messenger clients, enables end users to establish sessions, and enforces policies.
Instant Messaging Multiplexor. A scalability component that consolidates messenger connections. To support large deployments, with thousands of concurrent connections, Instant Messaging uses a connection multiplexor to improve server scalability. This component opens a single connection to the Instant Messaging server. In addition to scalability, you can install the multiplexor outside the firewall while leaving the server inside the firewall to protect it from unauthorized external access. The Instant Messaging multiplexor is also referred to as the multiplexor.
Access, Communication, and Transfer Protocols. These protocols, such as LDAP, HTTP, TCP/IP, and SMTP, can be found in Instant Messaging Supported Standards.
Access Manager Instant Messaging Service Definition. Instant Messaging provides a service definition to Access Manager using the Access Manager SDK, to provide support for Access Manager managed policies and SSO capabilities.
The software components discussed in this section work with the Instant Messaging server, but are installed separately. Chapter 21, Developing an Instant Messaging Architecture provides more detailed information that illustrates how these servers interact with Instant Messaging.
(Required) For any deployment, you need to install a web container, 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 container host.
The Instant Messenger Online Help
You must install Instant Messenger resources on the same host where the web container is installed. In an Access Manager deployment, you can install these resources on the Access Manager server’s host or on a different web container 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.
Install the web container before configuring Instant Messaging.
(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.2 Administration Guide.
Because a proper Directory Server implementation is instrumental to a successful Instant Messaging deployment, also see the Directory Server documentation:
(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 can also be used to archive instant messaging communications. This is in lieu of or in addition to the archive capability provided by Portal Server. The SMTP server does not have to reside on the same host as the Instant Messaging server.
(Optional) Access Manager and Access Manager SDK provide end user, service, and policy 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.
(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:
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 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 you 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 Portal Server documentation:
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:
LDAP. Provides access to enterprise directory information, enabling an accurate, secure instant messaging system.
HTML. Formatting language for providing web browser access to the client.
HTTP. HypterText Transport Protocol for providing web browser access to the client.
SMTP. Simple Mail Transfer Protocol for reliable delivery of instant messages over Internet mail messages.
TCP/IP. Proven, worldwide networking protocol.
XMPP. Extensible Messaging and Presence Protocol for interoperating with public networks through open source gateways.
XMPP protocol is used to format the instant messages. The message bodies themselves may be wrapped in HTML.
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.
Instant Messaging server-to-server and client-to-server communications occur over TCP/IP. You can secure these communications by using TLS encryption.
Instant Messaging uses SMTP to send messages to offline users and for email archiving.
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. Client-to-server communication can take place over HTTP/HTTPS/SOCKS proxy. Also, HTTPBIND is a server component (that uses the HTTP protocol) through which browser-based XMPP clients can communicate with the Instant Messaging server.
Instant Messaging 7.2 is an XMPP 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 Instant Messaging server and AOL, Yahoo, and other instant messaging systems.
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.
The deployment process consists of the following general phases, referred to as the Solution Life Cycle:
Analyzing business requirements
Analyzing technical requirements
Designing the logical architecture
Designing the deployment architecture
Implementing the deployment
Operating the deployment
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 Deployment Planning Guide.