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

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.

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.

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.

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.