Introduction to Calendar Server 7

Sun Java System Calendar Server has been completely rewritten in version 7 to support CalDAV, the calendar access protocol standard. For a description of features and functionality, see What's New in Calendar Server 7. (Link not yet public.) For an overview of the differences between Calendar Server 6 and Calendar Server 7, see Calendar Server 6 and Calendar Server 7 Comparison and Coexistence.

Topics:

Calendar Server Software Architecture

The following figure represents the software architecture of Calendar Server 7.

Calendar Server Software Architecture

Components of a Calendar Server Deployment

Clients and Servers

The Calendar Server deployment provides the repository for calendar and address book data, and also acts as a file storage. The main interface with the repository is the CalDAV protocol, which is based on HTTP. DAV clients can be running on end-user computers or on mobile devices, including:

• Thunderbird + Lightning extension (CalDAV)
• Apple iCal (CalDAV)
• Windows Explorer or Apple Finder (WebDAV)

The server also partially supports the legacy HTTP-based WCAP protocol for use by Convergence, Connector for Outlook, and Desktop Sync clients.

Note WCAP support, to enable support for clients such as Convergence and Connector for Outlook, is being planned for a future update.

The following figure shows the Calendar Server clients and components.

Calendar Server Components

Calendar Server supports only a subset of the legacy WCAP protocol, with no guarantee of backward compatibility. Additionally, Calendar Server supports the server-to-server iSchedule protocol, which means that it can also act as a client. Additional HTTP-based services exposed by the server include:

• Simple free/busy service
• Administrative browse UI

Finally, Calendar Server offers a JMX based interface to query and alter the repository. This interface is primarily used by the davadmin command-line utility but can also be used by standard clients, such as Jconsole, and by custom JMX clients, either locally or remotely.

User Repository

Data is organized within each Calendar Server repository by subject or by entity, that is, by LDAP user, resource, or group. Because the data can then further be organized by type of data, different data models can result, including the single repository model and the one repository per data-type model.

Single Repository Model

In the single repository model, each subject has one home collection (similar to UNIX home directory), which is the parent of all service-specific collections for that subject, including:

• Calendar collections
• Address book collections
• Generic file storage collections

For example, the following URLs represent a single repository for smith:

http://davserver.example.com/dav/home/smith/
http://davserver.example.com/dav/home/smith/MyDefaultCalendar/
http://davserver.example.com/dav/home/smith/SomeOtherCalendar/
http://davserver.example.com/dav/home/smith/MyDefaultAddressBook/
http://davserver.example.com/dav/home/smith/mypic.jpg

One Repository Per Data-Type Model

In the one repository per data-type model, each subject has one home collection per data type, for example:

• Calendar home collection
• Address book home collection
• Other collection

In that latter case, the different repositories can be distinguished by servers, for example:

http://calendar.example.com/dav/home/smith/
http://calendar.example.com/dav/home/smith/MyDefaultCalendar/
http://calendar.example.com/dav/home/smith/SomeOtherCalendar/

http://address.example.com/dav/home/smith/
http://address.example.com/dav/home/smith/MyDefaultAddressBook/

http://files.example.com/dav/home/smith/
http://files.example.com/dav/home/smith/mypic.jpg

Alternatively, the different repositories can be distinguished by name spaces, for example:

http://davserver.example.com/dav/calendar/smith/
http://davserver.example.com/dav/calendar/smith/MyDefaultCalendar/
http://davserver.example.com/dav/calendar/smith/SomeOtherCalendar/
http://davserver.example.com/dav/address/smith/
http://davserver.example.com/dav/address/smith/MyDefaultAddressBook/

Calendar Server 7 Front-End and Back-End Servers

In its default configuration, the Calendar Server 7 actually consists of two different components:

• Stateless J2EE based front end
• MySQL back end

You can locate both components on the same host or separate the components onto multiple hosts.

In a multiple-host deployment, a many-to-many relationship exists between front-end instances and back-end instances. Each front end has access to all the MySQL back ends. As a consequence, each front-end host has access to all users' data.

Multiple front ends can be grouped together, either by using a simple load balancer or by using the GlassFish Cluster functionality.

Note For session-based protocols (for example, WCAP), sessions are not synchronized among front-end hosts. The load balancer is responsible for ensuring that a particular session "sticks" to a particular front-end host.

What Is CalDAV and Why Use It?

CalDAV, also called Calendaring Extensions to WebDAV, is an Internet standard that enables client access to scheduling information on a remote calendar server. WebDAV, also called Web-based Distributed Authoring and Versioning, is a set of extensions to the Hypertext Transfer Protocol (HTTP) that enables users to collaboratively store, edit, and manage files on remote World Wide Web servers. The WebDAV protocol makes the web a readable and writable medium that enables users to create, change, and move documents on a remote server. This is useful for authoring the documents that a web server serves, but it can also be used for storing files on the web so that the files can be accessed from anywhere.

Until recently, the calendaring world has lacked any highly adopted standards. Different vendors have used their own proprietary protocols to coordinate their clients and servers. For example, previous versions of Sun Java System Calendar Server used the proprietary WCAP protocol.

CalDAV, described in RFC 4791, was approved as an IETF standard in March 2007. RFC 4791 and its extensions provide interoperable exchange of calendaring and scheduling information between all servers and clients conforming to these standards. The CalConnect group maintains a list of supported CalDAV clients.

By supporting CalDAV, calendaring solutions enable a wide spectrum of client choices as well as more flexibility for calendar synchronization solutions, including those offered by Notify and Synchronica.

Note CalDAV is supported in Calendar Server Version 7. CardDAV and WebDAV support might be provided in future releases.