Understanding Oracle Communications Unified Communications Suite Product Requirements and Considerations
This information describes requirements and considerations that impact the design of your Communications Suite deployment. You need to understand these requirements and considerations to accurately determine your Communications Suite architecture.
When designing your Communications Suite deployment architecture, take into account the requirements of the various component products of your deployment. For example, if you have a technical requirement to integrate Communications Suite with other Java System products, you need to choose your schema accordingly. Inter-product dependencies, for example, how Communications Suite accesses and places load on Directory Server, present deployment choices as well.
Understanding the individual components of each product enables you to plan for the type of architecture to best suit your requirements. Depending on your deployment, you need to potentially understand and plan for the following components:
- LDAP Directory Information Tree
- Directory Server (Access Manager)
- Convergence (available starting in Communications Suite 6) and Application Server
- Messaging Server
- Message Transfer Agent (MTA)
- Message Store
- Messaging Multiplexor (MMP)
- Calendar Server
- Front End
- Calendar Store
- Instant Messaging
- Instant Messaging Proxy
- Instant Messaging Back End
- Portal Server
- Connector for Microsoft Outlook
- Communications Express
When planning a Communications Suite deployment for multiple component products or services, you need to understand the composition of each component product (or service) itself.
The following figure illustrates how you can separate each service into components that can be deployed on separate hosts, and the particular tier each component occupies. In the preceding figure, the client components consist of the Outlook Connector plugin, thick clients such as Evolution, browsers, and standard email applications. These components reside on end users' client computers. The access layer components consist of front-end services from Messaging Server (MMP and MTA); Calendar Server; Communications Express and Webmail Server; Instant Messaging (Instant Messaging Proxy); Application Server (as the web container for Convergence); Portal Server (SRA and Core); Access Manager for authentication; and a corporate directory, which provides address book lookup. The data layer components consist of back-end services from Directory Server (which, in itself, can consist of front-end and back-end components); Messaging Server (Message Store); Calendar Server (Calendar Store); and Instant Messaging. A Storage Area Network (SAN) "cloud" represents the physical data storage.
Starting in Communications Suite 6, Convergence is deployed in a GlassFish Server (formerly Application Server) web container in the Access tier.
Communications Suite Components
Though you can deploy all components on a single host, or deploy a particular service's components on the same host, consider moving to a tiered architecture. A tiered architecture, whether it be single-tiered, or two-tiered, provides a number of benefits. See Developing a Communications Suite Logical Architecture for more information.
The corporate directory shown in this figure is not a component product in itself. It represents a "copy" of the corporate directory that enterprises typically deploy in the access layer for clients to perform address-book type lookups.
The following sections explain these various components in more detail.
The Directory Information Tree (DIT) is a way to organize directory entries in a tree structure, or schema, with nodes representing domains, subdomains, users, and groups. Starting with Communications Suite 5, Sun Java Enterprise System introduces a fundamental change to how the directory is structured by implementing a one-tree structure.
Messaging Server and Calendar Server have introduced a one-tree structure, where there is no Domain Component (DC) Tree. All domain information is held in domain nodes in the Organization Tree. Aliasing is handled entirely differently in the new one-DIT structure.
The bottom half of the following figure illustrates a one-tree LDAP structure.
Two-Tree LDAP Structure Compared With One-Tree Structure
The main advantages to using the one-tree structure Schema 2 native mode are:
- The structure is integrated with Access Manager.
- The structure is more closely aligned with industry standards.
- The structure is significantly less complex than the two-tree structure.
As illustrated in the following figure, in the two-tree structure, some nodes point directly to a node in the Organization Tree (using the attribute inetDomainBaseDN). Other nodes are aliased nodes, which instead of pointing directly to an Organization Tree node, point to another DC Tree node, using the aliasedObjectName attribute.
Two-Tree Aliasing With aliasedDomainName and inetDomainBaseDN
In the previous figure, sesta.com in the DC Tree points to siroe.com in the DC Tree using aliasedObjectName, and siroe.com points to the like named node in the Organization Tree, using inetDomainBaseDN.
Furthermore, as shown in the followin figure, there could be one or more nodes in the DC Tree using inetDomainBaseDN to point directly to the same node in the Organization Tree. In this case, a "tie-breaker" attribute, inetCanonicalDomainName, is necessary on one of the DC Tree nodes to designate which is the "real" domain name (the domain where the mail actually resides and where the mail is routed).
Two-Tree Aliasing With inetCanonicalDomainName
By contrast, a one-tree structure contains only an Organization Tree, as shown in the following figure.
One-Tree Aliasing With associatedDomain
In the one-tree structure, domain nodes in the Organization Tree contain all the domain attributes formerly found on the DC Tree. Each domain node is identified by the sunManagedOrganization object class and sunPreferredDomain attribute, which contains the DNS domain name. A domain node can also have one or more associatedDomain attributes, which list the alias names this domain is known by. Contrary to the two-tree structure, there are no duplicate nodes for the alias names.
A one-tree DIT structure is beneficial in how you partition data for organization-specific access control. That is, each organization can have a separate subtree in the DIT where user and group entries are located. Access to that data can be limited to users in that part of the subtree. This allows localized applications to operate securely.
In addition, for new deployments of Calendar Server or Messaging Server, a one-tree structure maps better to existing single-DIT LDAP applications.
Before you install any of the Communications Suite products, you need to understand which schema you will use. The schema is the set of definitions describing what types of information can be stored as entries in the directory. Two schema choices, Oracle LDAP Schema 1 and Oracle LDAP Schema 2, are available and supported with Communications Suite. Your choice of schema depends on the following criteria:
Use Schema 2 if you:
- Want to use Access Manager 6 (formerly Identity Server), either for user provisioning or single sign-on (SSO)
- Are installing Communications Suite components for the first time
- Are integrating Communications Suite with other Java Enterprise System products, such as Portal Server
You do not have to use Access Manager 6 to provide SSO. If you choose, you can still use the trusted circle type of SSO, which does not rely on Access Manager 6.
Use Schema 1 if you:
- Have an existing version of any of the Communications Suite components, for example, if you are upgrading from Messaging Server 5.2
- Do not need to provision users through Access Manager (unless Access Manager SSO is also a requirement)
- Want to use Sun ONE Delegated Administrator (formerly called iPlanet Delegated Administrator) to do your user provisioning
See Understanding Schema and Provisioning Options for more information on schema choices.
Directory Server provides flexible, multi-tiered data storage for intranet, network, and extranet information. Directory Server integrates with existing systems and acts as a centralized repository for the consolidation of employee, customer, supplier, and partner information. You can extend Directory Server to manage user profiles and preferences, as well as extranet user authentication.
All custom LDAP schemas, such as those from Portal Server, Access Manager, Messaging Server, Calendar Server, and Instant Messaging, install into a single Directory.
There are many ways to architect your data environment and many factors to consider that depend on your business objective and expected usage patterns. Your directory design should address the following areas:
- Directory schema and object class definitions
- The Directory Information Tree (DIT)
- Groups and membership definitions
- A strategy for Access Control Lists (ACLs) including static and dynamic groups
- Directory architecture for high availability and performance, including failover, replication, and referrals
- Management of the directory
See the Directory Server documentation for a complete description of these factors and suggestions about how to architect your data environment.
In moving from a single-tiered architecture to a multiple-tiered architecture, Directory Server should be the first component that you "split out" onto its own machine. At a certain point of load, Directory Server and Messaging Server on the same host have inherent performance impacts. This is due to the way Messaging Server is architected to work with Directory Server. Separating Directory Server onto its own machine is the first step to improve performance for a deployment.
See Developing a Communications Suite Logical Architecture for more information on tiered architectures.
You can install Directory Server in such a way to have a clear separation between the directory user management and the software application configuration. Should you want to remove the software application configuration piece, this separation provides a cleaner way of removing that information from Directory Server.
Though it is feasible to build a deployment around an instance of Directory Server installed on a single machine, the other Communications Suite components depend upon the directory as a core service to function. Thus, beyond trivial deployments, you should plan to deploy Directory Server in a redundant or highly availability configuration.
The first step toward making Directory Server more available is to establish a pair of master directory servers. Next, multimaster replication can be used to improve the LDAP write throughput and availability. If Oracle Solaris Cluster is used for a high-availability deployment, then the two LDAP masters are clustered together. See Directory Server and High Availability for more information.
While there are no hard and fast rules for Directory Server capacity planning, actively monitoring the directory is essential to ensure that performance metrics are met. When the system is not meeting these metrics, then it is time to add an additional directory consumer. Typically, you will want to monitor:
- Hit load
- Cache load
- Requests per second
Evaluate the above metrics against a target response time of 10 Milliseconds. The IOWAIT should not exceed 10 Milliseconds, and the sum of the CPU utilization in this tier should not exceed 70 percent.
Calendar Server performs multiple writes to user entries stored in Directory Server. The bulk of these writes occur when the user logs into Calendar Server for the first time and when the user performs certain actions. These actions include creating a calendar, subscribing to a calendar, changing a preference, and so on. If you do not take these actions into consideration, the Directory Master Server can experience heavy loads.
If you use Directory replication, the LDAP Master Server is replicating entries to the LDAP Replica servers. As Calendar users perform one of these actions, Calendar Server will only be able to write changes to the Master Directory Server. This is because the Replicas are read-only.
A second interaction consideration exists in these replicated Directory structures. As users make preference changes, their changes might not be rendered successful until the change is successfully replicated from the Master Directory Server to the Directory Replica, which is in use by the Calendar Server. A workaround is available, in which you configure Calendar Express (cshttpd) attempts to cache the change locally to avoid this latency delay. See Planning for the Calendar Server LDAP Data Cache for more information.
The deprecated Messenger Express Client supported the concept of a Personal Address Book (PAB). This enabled users to store personal contacts (for example, business contacts, friends, and family) in the Directory Server. Each time a new personal contact was added to the user's PAB, a write was made on the Directory Server. Because of this behaviour, if you did not take these actions into consideration, the LDAP Master Server could face heavy loads (regardless of the Directory replication strategy).
One method to avoid performance issues on the User and Group Directory Server was to place the PAB information on a separate Directory Server. This enabled PAB interactions to avoid placing a load on the LDAP Master Server.
If you are running both the current Communications Express client and also the deprecated Messenger Express Web mail interface, the address books used by these two clients do not share information. If end users switch between the two client interfaces, the two address books will contain different entries.
In developing your Communications Suite architecture, you need to evaluate the performance aspects of the following Messaging Server components:
- Message Store
- Message Transfer Agent (MTA)
- Mail Message Proxy (MMP)
For a complete discussion of the performance aspects of these components, and potential hardware solutions, see Performance Considerations for a Messaging Server Architecture.
Calendar Server consists of five major services:
- HTTP Service (cshttpd) listens for HTTP requests. It receives user requests and returns data to the caller.
- Administration Service (csadmind) is required for each instance of Calendar Server. It provides a single point of authentication and administration for the Calendar Servers and provides most of the administration tools.
- Notification Service (csnotify) sends notifications of events and to-dos using either email or the Event Notification Service.
- Event Notification Service (enpd) acts as the broker for event and alarm notifications.
- Distributed Database Service (csdwpd) links multiple database servers together within the same Calendar Server system to form a distributed calendar store.
- Backup Service (csstored) implements automatic backups, both archival backups and hot backups. The first backup is a snapshot with log files, the second is a snapshot with log files applied. This service is automatically started when you run the start-cal command. However, it is not enabled at installation time, so you must configure it to function. If left unconfigured, Backup Service sends out a message to the administrator every 24 hours, with the notification that the service is not configured.
In a scalable Calendar Server deployment, you would deploy front-end systems in conjunction with a back-end server. The front-end systems would contain one instance of the cshttpd daemon per processor and a single Administration Service. A back-end server would contain an instance of Notification Service, Event Notification Service, Distributed Database Service and Administration Service.
Authentication and XML / XSLT transformation are two Calendar Service activities that generate heavy load. Additional CPUs can be added to meet quality of service requirements. In a scalable environment, these heavy load activities take place on the front-end system(s), permitting more CPUs to be added to individual front-end systems, or more front-end systems to be added, to meet quality of service requirements.
The preceding paragraph is not applicable if the Communications Express Calendar client is used for calendar access. Communications Express uses the WCAP protocol to access Calendar Server data and therefore the Calendar Server infrastructure is not doing the XML/XSLT translations. See Developing a Communications Express Architecture.
Calendar back-end services usually require half the number of CPUs sized for the Calendar front-end services. To support quality of service by the Calendar front-end system, the Calendar back-end system should use around two-thirds of the front-end CPUs.
Consider early on in your deployment planning to separate the Calendar Service into front-end and back-end services.
The Calendar Server HTTP process that is typically a component of the front-end services is a dominant user of CPU time. Thus, account for peak calendar usage and choose sufficient front-end processing power to accommodate the expected peak HTTP sessions. Typically, you would make the Calendar Server front end more available through redundancy, that is, by deploying multiple front-end hosts. As the front-end systems do not maintain any persistent calendar data, they are not good candidates for HA solutions like Oracle Solaris Cluster or Veritas. Moreover, the additional hardware and administrative overhead of such solutions make deploying HA for Calendar Server front ends both expensive and time-consuming.
The only configuration for Calendar front ends that might warrant a true HA solution is where you have deployed the Calendar front end on the same host that contains a Messaging Server MTA router. Even in this configuration, however, the overhead of such a solution should be carefully weighed against the slight benefit.
A good choice of hardware for the Calendar Server front ends is a single or dual processor server. You would deploy one instance of the Calendar Server cshttpd process per processor. Such a deployment affords a cost-effective solution, enabling you to start with some level of initial client concurrency capability and add client session capacity as you discover peak usage levels on your existing configuration.
When you deploy multiple front ends, a load balancer (with sticky/persistent connections) is necessary to distribute the load across the front-end services.
Communications Express does not scale beyond two processors. The same hardware choices explained previously for Calendar Server apply to Communications Express deployments.
The Calendar Server back-end services are well balanced in resource consumption and show no evidence of bottleneck formation either in CPU or I/O (disk or network). Thus, a good choice of hardware for the back end would be a SPARC server with a single striped volume. Such a machine presents considerable capacity for large-peak calendar loads.
If your requirements include high availability, it makes sense to deploy the Calendar Server back end with Oracle Solaris Cluster, as the back end does contain persistent data.
In a configuration with both front-end and back-end Calendar Server hosts, all hosts must be running:
As with other Communications Suite components, you can create an architecture in which you separate Instant Messaging into front-end (Instant Messaging multiplexor) and back-end components (server and store). See Planning an Instant Messaging Sizing Strategy for more information.
This section contains the following sub-sections:
- Planning for Various Components
- Schema Considerations with Convergence
- Authentication Considerations with Convergence
- Directory Server Considerations with Convergence
- Application Server Considerations with Convergence
- Access Manager Considerations with Convergence
- Messaging Server Considerations with Convergence
- Calendar Server Considerations with Convergence
- Instant Messaging Considerations with Convergence
When designing your Convergence deployment architecture, you take into account the same kind of requirements you would for a Communications Suite deployment for the various component products of your deployment. Because Convergence, like other Communications Suite components, depends on other products, you need to think about the following components in your deployment:
- Authentication Mechanism
- Directory Server
- Messaging Server
- Calendar Server
- Instant Messaging
- Application Server
- Access Manager (if your Identity Management plan calls for it)
Though you can deploy all components on a single host, or deploy a particular service's components on the same host, consider moving to a tiered architecture. A tiered architecture provides for more flexibility in tuning, upgrading, and expanding your deployment.
Convergence requires specific versions of dependent component products. For specific component product versions necessary to support Convergence, see the current Release Notes.
Convergence supports both Schema 1 and 2. Compatibility mode is not supported.
For more information about general Schema requirements for Communications Suite components, see Schema Requirements.
Convergence supports the following Single Sign-on mechanisms out-of-the-box:
- Access Manager SSO
- Messaging SSO (also referred to as Trusted Circle SSO)
- OpenSSO Enterprise 8.0 starting with the Convergence 1 Update 2 release
As you plan your Convergence deployment, decide which style of SSO you need. Internally, Convergence uses a proxy-auth mechanism to perform SSO with Communications Suite back-end servers (Messaging Server, Calendar Server, and Instant Messaging).
Convergence also provides an SSO plug-in to enable you to write your own authentication mechanism.
For more information, see Convergence SSO.
Convergence requires Directory Server for LDAP information storage. Convergence is compatible with Directory Server 5.x and 6.x. The comm_dssetup.pl script installs the necessary LDAP schema modifications for the Communications Suite products.
For more information about general Directory Server requirements for Communication Suite components, see Directory Server Considerations.
Convergence requires a web container to run in. Currently, you must install Application Server 9.1 Update 2 as the Convergence web container.
If you choose to use Access Manager style Single Sign-on for Convergence (as opposed to Messaging SSO or OpenSSO), you must install Access Manager.
- You must upgrade the message store to at least Communications Suite 5 (Messaging Server 6.3).
- You must run the new Convergence 1 server with a Messaging Server 7.0 Webmail Server (mshttpd daemon) on your messaging front-end access hosts. The Webmail Server (mshttpd daemon) interoperates with both Messaging Server 6.3 and 7.0. A "compatability mode" exists for Messaging Server 6.3 mshttpd but is not recommended for production systems.
Convergence requires at least Calendar Server 6.3, issued with Communications Suite 6. Note that a fresh install of Calendar Server 6.3 through the Communications Suite 6 installer installs the proper patched version of Calendar Server 6.3. If you have a previous version of Calendar Server, you can apply the appropriate patch to reach the Calendar Server 6.3 version that ships with Communications Suite 6.
Convergence requires at least Instant Messaging 7.3, issued as part of Communications Suite 6.
You can install Communications Suite products with Portal Server to provide an "umbrella" front end to access messaging, calendar, and instant messaging applications. The integration of Portal Server includes single sign-on capabilities between Portal Server, Calendar Express web client, Messaging Express web client and Communications Express client. In addition, the Messaging Express, Calendar Express, and Instant Messaging clients are made available to users through the Portal Server desktop.
See the Sun Java System Portal Server 7.1 Deployment Planning Guide and the Sun Java System Access Manager 7.1 Deployment Planning Guide for more information.
This section describes some deployment issues you will encounter deploying Connector for Microsoft Outlook. For complete information, see the Connector for Microsoft Outlook Index.
Connector for Microsoft Outlook enables Outlook to be used as a desktop client with Sun Java Enterprise System. Connector for Microsoft Outlook is an Outlook plug-in that must be installed on the end-user's desktop. Connector for Microsoft Outlook queries Messaging Server for folder hierarchies and email messages. It converts the information into Messaging API (MAPI) properties that Outlook can display. Similarly, it uses the WCAP protocol to query Calendar Server for events and tasks which are then converted into MAPI properties. With this model, Connector for Microsoft Outlook builds an end-user Outlook view from two separate information sources: mail from Messaging Server and calendar information from Calendar Server.
When users create and modify items through Outlook, Connector for Microsoft Outlook passes the new message along to the appropriate server depending on its message type. It sends new outgoing email to an SMTP mail server for delivery, and sends modified email messages back to the user's IMAP folder for storage. New calendar events and tasks are converted into a standard format to be stored in the Calendar Server database.
To use Connector for Microsoft Outlook, both Messaging Server and Calendar Server are required in the same deployment. See those products' release notes for information on supported versions.
For Connector for Microsoft Outlook to function correctly, the following LDAP attributes in the Directory Server should be indexed for at least presence and equality to improve the overall performance:
See Common Release Information for Communications Suite Component Products in the Communications Suite Release Notes for a complete list of product dependencies.
If you are using a version of Calendar Server prior to Sun ONE Calendar Server 6.0, you need to engage Oracle Client Services to convert and migrate the data to the new format. This Calendar Server data migration is required for the use of Outlook, and is necessary because of the underlying changes in the storage and management of recurring events. No migration service is required for new customers of Calendar Server.
Communications Express provides an integrated web-based communications and collaboration client. Communications Express is a common part of Messaging Server and Calendar Server, providing end users with a web interface to their calendar information and mail, as well as an address book.
Communications Express consists of three client modules: Calendar, Address Book, and Mail. The Calendar and Address Book client modules are deployed as a single application on a web container. Prior to Messaging Server 7.0, Messenger Express was the standalone web-based mail application that used the HTTP service of the Messaging Server. You deployed Messenger Express on the same system as Communications Express. Beginning with Messaging Server 7.0, the Messenger Express webmail interface was removed from Communications Suite.
Communications Express depends upon the following component products:
- Directory Server
- Access Manager (If you are using Oracle LDAP Schema Version 2)
- Calendar Server
- Messaging Server
- Web Server/Application Server (for web container)
Communications Express Mail includes the security advantages of the Secure/Multipurpose Internet Mail Extension (S/MIME). Convergence and Communications Express Mail users who are set up to use S/MIME can exchange signed or encrypted messages with other Communications Express Mail users, and with users of the Microsoft Outlook mail system.
See Administering SMIME in Communications Express Mail and Administering SMIME in Convergence for more information.