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.
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:
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.
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.