|
| |
| Sun Java System Communications Services 6 2004Q2 Enterprise Deployment Planning Guide | |
Chapter 6
Communications Services Software FeaturesThis chapter provides an overview of specific features of Sun Java System components that affect your deployment planning.
This chapter contains the following sections:
Communications Services Component FeaturesCommunications Services consist of three core components:
Communications Services components have dependencies on three additional components:
This section provides an architectural overview of the core components.
Messaging Server Software Overview
In general, a messaging service is an open standards-based client-server solution that meets the email needs of enterprises and messaging hosts of all sizes. A messaging service provides superior directory services, administration, scalability, performance, encryption, and remote connectivity.
In particular, a messaging service quickly delivers email with embedded sound, graphics, video files, HTML forms, Java applets, and desktop applications, while providing for future upgrade and scalability.
At a simplistic level, a messaging service:
In addition, a messaging service might provide Guaranteed Mail Delivery (GMD), anti-virus solutions, as well as spam control.
Of crucial importance to a good messaging service is a messaging server that follows the SHARP (scalability, high availability, reliability, and good performance) standard.
A messaging server is an electronic mail delivery system that supports email storage and delivery from one system to another system. In general, messaging servers, including Sun Java System Messaging Server, contain the following components:
- Mail User Agent. A client email program for end users to store, compose, and reply to messages.
- Message Access/Transfer Protocols. POP3, IMAP4, HTTP, and SMTP protocols. These protocols are further described in the sections on Message Access Protocols and Message Transfer Protocols.
- Message Store. A data store that holds mail until it is retrieved or deleted by an access server.
- Message Transfer Agent (MTA). Forwards messages from one mail server to another mail server. In addition, the MTA transfers messages to its own Message Store.
- LDAP server. A “lightweight” version of the Directory Access Protocol (DAP). While typically not a messaging server component, the LDAP server is integral for user maintenance and management. It usually serves the needs of a wide variety of applications in an organization.
Messaging Server Architectural Overview
Sun Java System Messaging Server includes the Message Store, the MTA, and the server-side software that implements the Message Transfer and Message Access protocols. It also contains the HTTP message access client, Messenger Express. In addition, it is fully configurable with Directory Server software.
Figure 6-1 shows the basic out-of-the-box Messaging Server architecture.
Figure 6-1 Messaging Server Basic Architecture
In the preceding figure, incoming messages from the Internet or local clients are received by the MTA via SMTP. If the address is within the Messaging Server domain, the MTA delivers the message to the Message Store. If the message is addressed to a domain outside of Messaging Server control, the MTA relays the message to another MTA on the Internet.
Although it is possible to deliver mail to an old UNIX /var/mail file system, local messages are typically delivered to a more optimized Messaging Server Message Store. These messages are then retrieved by any IMAP4 or POP3 client, or via the included Messenger Express interface.
The Directory Server stores and retrieves local user and group delivery information such as addresses, alternate mail addresses, and mail host information. When the MTA receives a message, it uses this address information to determine where and how the message should be delivered.
In addition to storing messages, the Message Store uses the Directory Server to verify user login name and passwords for mail clients that access mail. The Directory also stores information about quota limits, default message store type, and so on.
Outgoing messages from mail clients go directly to the MTA, which sends the message to the appropriate server on the Internet or, if the address is local, sends it to the Message Store.
New users and groups are created by adding user and group entries to the directory. Entries can be created or modified by using the Delegated Administrator, or by modifying the directory using LDAP.
Messaging Server components are administered by the Messaging Server Administration Console (not pictured in Figure 6-1). In addition, a set of command-line interfaces and text-based configuration files are provided. Any machine connected to the Messaging Server host can perform administrative tasks (assuming, of course, the administrator knows the password). Some of the more common administrative tasks are adding, modifying, and removing users and groups from the mail system. In addition, an administrator might configure the operation of the MTA and Message Store.
Web-based Mail Client Service (HTTP) Through Messenger Express
The Messaging Express Multiplexor (MEM) provides a middle-tier for the Sun Java System Messenger Express mail client. This client enables users to access their mailbox data and to compose email messages through a web browser (WUA). The benefit of the MEM is that end users connect only to the MEM to access their email regardless of which back-end server is storing their mail. The MEM manages the HTTP session information and profiles the user via the users’s LDAP information stored in Directory Server. The second benefit is that static files and LDAP authentication states are located on the Messaging Server front-end server. This benefit helps to offload the disk requirements on the Messaging Server store back end.
Where to Go For More Information on Messaging Server
See the following documentation for more information on Messaging Server:
Calendar Server Software Overview
Sun Java System Calendar Server is built from the ground up on standards. Its data store is based on iCalendar technology. It supports iMIP Publish, Request, Reply, and Cancel messages for events and tasks. Native support for iCalendar standards enables users to schedule events in a format that is easily shared across the Internet. Calendar Server ships with a full- featured Web client, Sun Java System Calendar Express, which is based on XML and eXtensible Stylesheet Language Transformations (XSLT) templates, and can be customized for a particular enterprise or ISP. Calendar Server also provides connectors to other popular calendar clients, thereby enabling a variety of clients and devices to communicate with Calendar Server.
In addition, Calendar Server provides an open protocol, known as the Web Calendar Access Protocol (WCAP), for developing clients that communicate with Calendar Server. WCAP is extremely useful in cases where calendar information must be provided to nonbrowser interfaces such as phones, PDAs, or other devices.
For information about WCAP commands, see the Sun Java System Calendar Server Developer’s Guide:
Built with flexibility in mind, Calendar Server is capable of running in LDAP-based or identity-based environments. The LDAP-based environment uses the LDAP directory for authentication and Calendar Server administration tools for provisioning. The identity- based deployment uses Identity Server for authentication and Identity Server administration tools for provisioning.
Calendar Server Architectural Overview
Figure 6-2 illustrates the Calendar Server internal architecture.
Figure 6-2 Calendar Server Internal Subsystems Logical Flow
Calendar Server is built, in part, on proven components from Messaging Server and Directory Server. The design is highly modular. Calendar Server is implemented by way of a collection of shared libraries that fall into three main components:
- Protocol Subsystem. Commands and requests enter through the HTTP protocol layer. This is a minimal HTTP server implementation, streamlined to support calendar requests. Clients use SHTML or Web Calendar Access Protocol (WCAP) commands to submit requests.
- Core Subsystem. The Core subsystem includes the access control subsystem, user interface (UI) generator subsystem (either SHTML using XML and XSLT or WCAP using data translators), calendar database subsystem, and any CSAPI plugins. The Core subsystem processes calendar requests and generates the desired UI output. The Core subsystem also handles user authentication, including Calendar Server API (CSAPI) and Proxy Authentication SDK (authSDK).
- Database Subsystem. The Database subsystem uses the Berkeley DB from Sleepycat Software (the database API is not public). The Database subsystem stores and retrieves calendar data to and from the database, including events, todos (tasks), and alarms. Calendar data is based on iCalendar format, and the schema used for Calendar Server data is a superset of the iCalendar standard. The Database subsystem returns data in a low-level format, and the Core UI generator (either SHTML or WCAP) then translate the low-level data into the desired output.
The shared libraries of the protocol, core, and database subsystems are bound in various combinations to produce the executable daemons cshttpd, csdwpd, csadmind, and csnotifyd. In addition, the daemon enpd provides an event notification service that is shipped with Calendar Server.
Commands or requests enter the server through the Protocol subsystem and are passed to the Core subsystem for processing. Database accesses go through the Database subsystem.
Where to Go For More Information on Calendar Server
See the following documentation for more information on Calendar Server:
Instant Messaging Software Overview
An instant messaging service is an open standards-based client-server solution that meets the instant messaging needs of enterprises and hosts of all sizes. It provides superior administration, scalability, performance, security, and connectivity throughout the enterprise and across the Internet.
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 follows the SHARP (scalability, high availability, reliability, and good performance) standard.
Instant Messaging contains the following core components:
- Instant Messenger resources (client). A set of files that make 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 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, allows end users to establish sessions, and enforces policies.
- Instant Messaging multiplexor. A scalability component that consolidates messenger connections. In order to support large deployments, for example 40,000 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 in order to protect from unauthorized external access. The Instant Messaging multiplexor is also referred to as the multiplexor.
- Access, Communication, and Transfer Protocols. LDAP, HTTP, TCP/IP, and SMTP protocols.
- Identity Server Instant Messaging Service Definition. A service used by Identity Server and the Identity Server SDK to provide policy management and single sign-on capabilities for Instant Messaging.
- Instant Messaging API. Enables you to create custom Instant Messaging clients.
- LDAP server. A “lightweight” version of the Directory Access Protocol (DAP). While typically not an instant messaging server component, the LDAP server is integral for user maintenance and management. It usually serves the needs of a wide variety of applications in an organization.
Instant Messaging Architectural Overview
Figure 6-3 shows the basic out-of-the-box Instant Messaging architecture.
Figure 6-3 Instant Messaging Basic Architecture
Web Server (or an application server with a Web service embedded) downloads the Instant Messaging resources via a browser to the clients. The resource files make up the client. Clients sends messages to one another through a multiplexor which forwards the messages on to the Instant Messaging server.
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, 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.
New users are created by adding user entries to the directory. Entries can be created or modified by modifying the directory using the tools provided with the Directory server.
Instant Messaging components are administered using 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).
Where to Go For More Information on Instant Messaging
See the following documentation for more information on Instant Messaging:
Infrastructure Component FeaturesThis section describes the Directory Server, Identity Server, and DNS infrastructure components upon which Communications Services components depend.
Directory Server Software Overview
A directory service is the collection of software and processes that store information about your enterprise, subscribers, or both. In the context of this documentation, a directory service consists of at least one Directory Server and one or more directory client programs. Client programs can access names, phone numbers, addresses, and other data stored in the directory, depending on the permissions that have been set.
Directory Server includes the directory itself, the server-side software that implements the LDAP protocol, and a graphical user interface that allows users to search and change entries in the directory. Other LDAP clients are also available, including the directory managers in the Server Console. In addition, you can purchase other LDAP client programs or write your own using the LDAP client SDK included with the Directory Server product.
Without adding other client programs, Directory Server can provide the foundation for an intranet or extranet. Every Sun Java System component server uses the directory as a central repository for shared server information, such as employee, customer, supplier, and partner data.
You can use Directory Server to manage extranet user-authentication, create access control, set up user preferences, and centralize user management. In hosted environments, partners, customers, and suppliers can manage their own areas of the directory, reducing administrative costs.
Directory Server consists of the following components:
- An LDAP server with a plug-in interface
- Administration Server
- Server Console to manage the servers
- Command-line tools for starting and stopping the server, importing and exporting data in the database, database reindexing, account inactivation and deactivation, LDIF merges, kernel tuning, and replication management
- An SNMP agent
- The Directory Services Markup Language (DSML)
Directory Server Architectural Overview
The Directory Server basic architecture consists of the following:
- Server Front Ends Responsible for Network Communications. The server front ends of Directory Server manage communications with directory client programs. The Directory Server functions as a daemon. Multiple client programs can communicate with the server using LDAP over TCP/IP or DSML over HTTP. The connection can be protected using Secure Socket Layer over Transport Layer Security (SSL/TLS), depending on whether the client negotiates the use of TLS for the connection.
- Plugins for Server Functions. Directory Server relies on plugins for such aspects as access control and replication. A plugin is a way to add functionality to the core server. For example, the Uid Uniqueness plugin can be used to ensure that values given to the user id (uid) attribute are unique in the suffix configured when installing the directory.
- Basic Directory Tree Containing Server-related Data. The directory tree, also known as a directory information tree or DIT, mirrors the tree model used by most file systems, with the tree’s root, or first entry, appearing at the top of the hierarchy.
Where to Go For More Information on Directory Server
See the following documentation for more information on Directory Server.
Identity Server Software Overview
Identity Server is an identity management solution designed to meet the needs of rapidly expanding enterprises. Identity Server enables you to get identities for your employees, your partners and suppliers into one online directory. Then it provides a means for establishing policies and permissions regarding who has access to which information in your enterprise. Identity Server is the key to all your data, your services, and who has access to what.
When an enterprise user or an external application tries to access content stored on a company’s web server, the policy agent intercepts the request and directs it to Identity Server. Identity Server asks the user to present credentials such as a username and password. If the credentials match those stored in the central Directory Server, Identity Server verifies the user’s identity. Next, Identity Server evaluates the policies associated with the user’s identity, and then determines whether the user is allowed to view the requested information. Finally, Identity Server either grants or denies the user access to the information.
Identity Server consolidates four major features into a single product that can be viewed in a single administration console:
Identity Server Architectural Overview
Identity Server uses a Java technology-based architecture for scalability, performance, and ease of development. It leverages industry standards including the following:
Where to Go For More Information on Identity Server
See the following documentation for more information on Identity Server:
DNS Overview
A high quality caching Domain Name System (DNS) server on the local network is a requirement for a production deployment of Communications Services.
DNS is an application-layer protocol that is part of the standard TCP/IP protocol suite. This protocol implements the DNS name service, which is the name service used on the Internet.
Though it supports the complex, world-wide hierarchy of computers on the Internet, the basic function of DNS is actually very simple: providing name-to-address resolution for TCP/IP-based networks. Name-to-address resolution, also referred to as “mapping,” is the process of finding the IP address of a computer in a database by using its host name as an index.
DNS provides two principal services. It performs name to address mapping (and also maps addresses to host names). It also helps mail delivery agents, such as sendmail and POP, deliver mail along the Internet.
To deliver mail across the Internet, DNS uses mail exchange records (MX records). Many organizations do not allow direct delivery of mail that comes across the Internet for hosts within the organization. Instead, they use a central mail host (or a set of mail hosts) to intercept incoming mail messages and route them to their recipients.
The mail exchange record identifies the mail host that services each machine in a domain. Therefore, a mail exchange record lists the DNS domain names of remote organizations and either the IP address or the host name of its corresponding mail host. Consider the following table.
DNS Domain
Mail Host
International.com
129.44.1.1
sales.example.com
SalesExampleMailer
eng.example.com
EngExampleMailer
siroe.com
SiroeMailer
When the mail agent receives a request to send mail to another domain, it parses the address of the recipient from right to left and looks for a match in the table.
If it receives a request to send mail to neverhome.sales.example.com, it first extracts the topmost label, com. It examines the mail exchange record to see if there is an entry for com. Since there is none, it continues parsing. It extracts the next label and looks for an entry for example.com. Because there is none, it continues looking. The next entry it looks for is sales.example.com. As you can see in the preceding table, the mail host for that domain is SalesExampleMailer. Because that is a host name, the mail agent asks DNS to resolve it. When DNS provides that mail host’s IP address, the mail agent sends the message.
If, instead of the mail host name, the mail exchange record had specified an IP address, the mail agent would have sent the message directly to that address, since it would have needed no name resolution from DNS.
