Sun Java System Communications Services 6 2005Q4 Deployment Planning Guide

Chapter 17 Developing a Calendar Server Architecture

This chapter describes three basic Calendar Server deployment architectures, which can vary depending on your site’s specific requirements.

This chapter contains the following sections:

Single-Server Calendar Server Architecture

Figure 17–1 shows a single-server architecture. In this deployment, all Calendar Server services (processes) run on the same server, either in the same CPU (processor) or across multiple CPUs. The Directory Server and Access Manager processes can run on the same server or on different servers.

Figure 17–1 Single-Server Calendar Server Architecture

This diagram shows a minimal, single-server Calendar Server deployment.

A Calendar Server instance on a single server includes the following services:

Administration service (csadmind process) provides support for administration functions such as commands to start or stop Calendar Server, create or delete calendar users or resources, or fetch and store calendars.
HTTP service (cshttpd process) handles incoming SHTML and WCAP requests.
Event Notification Service (enpd) acts as the broker for event and alarm notifications.
Backup service (csstored) implements automatic backups, both archival backups and hot backups.

For a description of Calendar Server services, see the Sun Java System Calendar Server 6 2005Q4 Administration Guide.

The Database Wire Protocol (DWP) service (csdwpd process), which provides networking capability when the calendar database is on another server, is not required for a minimal configuration because the database is on the same server.

Calendar Server requires a directory server to authenticate users and to store user preferences. Usually, the directory server is an LDAP directory server, such as Sun Java System Directory Server. However, if you prefer, you can use the Calendar Server API (CSAPI) to write a plugin to use a non-LDAP directory server. This API is described in the Sun Java System Calendar Server 6 2005Q4 Developer’s Guide.

The directory server can run on the same server where Calendar Server is running or on a remote server.

Sun Java System Access Manager (release 2003Q4 (6.1) or later) provides the following functionality:

Communications Services Delegated Administrator utility. Use the CLI utility (commadmin) to provision and manage hosted (virtual) domains, users, groups, organizations, resources, and roles for Sun Java System communications servers, including Calendar Server.

For information about the Communications Services Delegated Administrator utility, see the Sun Java System Communications Services 6 2005Q4 Delegated Administrator Guide.
Single Sign-on (SSO). You can implement SSO for Sun Java Enterprise System servers, including Calendar Server and Messaging Server, using Access Manager, or through trusted circle technology. Access Manager serves as the SSO gateway for Java Enterprise System servers. Users log in to Access Manager and then can access other the servers, as long as all servers are configured properly for SSO.
Sun Java System LDAP Schema 2. Access Manager (release 2003Q4 or later) is required if you want to use this version of the schema.

For more information on these topics, see the Sun Java System Calendar Server 6 2005Q4 Administration Guide.

Access Manager can run on the same server where Calendar Server is running or on a remote server.

End users connect to Calendar Server from client machines by using one of two Web user interfaces (UIs), either Sun Java System Calendar Express, or Sun Java System Communications Express. For information using these interfaces, see the respective interface’s online Help.

Two-tiered Calendar Server Architecture

Calendar Server supports scalability by distributing a configuration over multiple front-end and back-end servers. On each server, Calendar Server services can also be distributed across multiple CPUs.

In a two-tiered architecture, sometimes referred to as network front-end/database back-end configuration (shown in the following figure), users log in to a front-end server and connect to a back-end server using the Database Wire Protocol (DWP) service (csdwpd process). The calendar database is connected only to the back-end servers.

Figure 17–2 Two-tiered Calendar Server Architecture

This diagram shows a scalable Calendar Server deployment.

Calendar Server processes run on both the front-end and back-end servers as follows:

Users are directed by load balancers to a front-end server, where they log in. Each front-end server requires these services:
- Administration Service (csadmind process)
- HTTP Service (cshttpd process)
Each back-end server is connected to a calendar database, so each back-end server requires these services:
- Administration Service (csadmind process)
- Backup service (csstored)
- Event Notification Service (enpd and csnotifyd processes)
- Database Wire Protocol (DWP) Service (csdwpd process) to provide networking capability to the front-end servers for the calendar database

In this configuration, users do not log in to the back-end servers, so the HTTP service (cshttpd process) is not required.

For a description of Calendar Server services, see the Sun Java System Calendar Server 6 2005Q4 Administration Guide.

A scalable Calendar Server configuration requires a directory server to authenticate users and to store user preferences.

You can use Access Manager (release 6.1 (release 6 2003Q4) or later) to implement Single Sign-on (SSO), to use Sun Java Enterprise System LDAP Schema 2, or to provision and manage hosted (virtual) domains, users, groups, organizations, resources, and roles.

Two-tiered, Multiple Server Calendar Server Architecture

In a two-tiered Calendar Server architecture with multiple front-end and back-end servers (shown in Figure 17–3), users log in to a specific server, and each server is connected to a calendar database. This configuration enables calendars to be geographically distributed, with each calendar residing on the server where its owner logs in to Calendar Server.

Figure 17–3 Two-tiered, Multiple Server Calendar Server Architecture

This diagram shows a Calendar Server configuration for multiple
front-end and back-end servers.

In this architecture, each server functions as both a front end and back end, and requires all Calendar Server services: Administration Service (csadmind process), HTTP Service (cshttpd process), Event Notification Service (enpd and csnotifyd processes), and Database Wire Protocol (DWP) Service (csdwpd process).

For a description of Calendar Server services, see the Sun Java System Calendar Server 6 2005Q4 Administration Guide.

Note –

In this architecture, you could also separate the front end services from the back end services onto separate machines, and use the LDAP Calendar Lookup Database (CLD) to determine which back end a front end needs to get data from. For more information, see the Sun Java System Calendar Server 6 2005Q4 Administration Guide.

A multiple front-end/back-end server deployment requires a directory server to authenticate users and to store user preferences.