2 Calendar Server 6 and 7 Comparison and Coexistence

This chapter discusses the differences between Oracle Communications Sun Calendar Server (formerly Sun Java System Calendar Server 6) and Oracle Communications Calendar Server (also referred to as Calendar Server 7), as well as the issues for a coexistent deployment.

Overview of Calendar Server 7 and Calendar Server 6

Calendar Server 7 is Oracle's next-generation Calendar Server, which supports the new standard for calendar access called Calendaring Extensions to WebDAV (CalDAV).

Calendar Server 7 is a newly designed server and replaces the existing Calendar Server 6. Calendar Server 7 operates in a very different manner from Calendar Server 6. Though both servers use the standard iCal format for data, Calendar Server 6 supports only Web Calendar Access Protocol (WCAP) for data access, making it usable only with Oracle-supplied clients and connectors. Calendar Server 7 supports the standard CalDAV access protocol, which makes it usable with Apple iCal, iPhone, Thunderbird Lightning, and any other CalDAV client.

Calendar Server Architecture and Services

Calendar Server 6 was designed as a stand-alone application that consisted of multiple processes, including:

csadmin: Manages alarm notifications and group scheduling requests
cshttpd: Listens for HTTP commands from Calendar Server end users, receives the user commands, and returns calendar data
csstored: Creates automatic backups of the calendar database
csnotifyd: Sends notifications of events and to-do's (tasks)
csdwpd: Manages calendar databases spread across multiple back-end servers within the same Calendar Server configuration

Calendar Server 7 is a servlet that you deploy into a web container (GlassFish Server). Thus, Calendar Server 7 does not contain its own start and stop programs, unlike Calendar Server 6. (You start and stop Calendar Server 7 through the GlassFish Server asadmin command.) The administrative commands have been completely rewritten as well for Calendar Server 7. The Calendar Server 7 commands do not have one-to-one mapping to the Calendar Server 6 commands.

For more information about administering Calendar Server 7 by using the davadmin command, see the command-line utilities topic in Calendar Server System Administrator's Guide.

Calendar Server 6 used an embedded Berkeley DB database while Calendar Server 7 uses a separate database, which can be either MySQL Server or Oracle Database. Though you must install and maintain this database outside of Calendar Server, maintenance is eased by using the database-specific tools.

Coexistence Between Calendar Server 6 and Calendar Server 7

You can install Calendar Server 6 and Calendar Server 7 on the same host. Each server does not use the other's data. You can ensure communication of free-busy information and iCalendar Message-Based Interoperability Protocol (iMIP) scheduling between the two servers by using the setup described in Calendar Server Installation and Configuration Guide. Also, this setup requires that you install the latest Calendar Server 6 patch (patch-ID 121659).

Installation and Configuration

Table 2-1 shows the installation and configuration information relating to the different Calendar Server versions.

Table 2-1 Calendar Server Installation and Configuration Differences by Version

Version	Description
Calendar Server 6.3	Installing and configuring Calendar Server 6.3 consists of the following high-level steps: Installing the software by using the Communication Suite 6 Installer. Running the Communications Suite 6 Directory Server Setup script, comm_dssetup.pl, to configure Directory Server. Running the Calendar Server configuration program (csconfigurator.sh) to initially configure your site's specific requirements and to create a new ics.conf configuration file. Customizing your system by editing parameters in the ics.conf file.
Calendar Server 7	Installing and configuring Calendar Server 7 consists of the following high-level steps: Installing and configuring the GlassFish Server as the web container. Installing either MySQL Server or Oracle Database software and setting up the database. Running the Communications Suite Directory Server setup script, comm_dssetup.pl, to configure Directory Server. Installing the Calendar Server 7 software by using the Communications Suite installer. Running the Calendar Server 7 configuration script (init-config) to initially configure your site's specific requirements.

Version

Description

Calendar Server 6.3

Installing and configuring Calendar Server 6.3 consists of the following high-level steps:

Installing the software by using the Communication Suite 6 Installer.
Running the Communications Suite 6 Directory Server Setup script, comm_dssetup.pl, to configure Directory Server.
Running the Calendar Server configuration program (csconfigurator.sh) to initially configure your site's specific requirements and to create a new ics.conf configuration file.
Customizing your system by editing parameters in the ics.conf file.

Calendar Server 7

Installing and configuring Calendar Server 7 consists of the following high-level steps:

Installing and configuring the GlassFish Server as the web container.
Installing either MySQL Server or Oracle Database software and setting up the database.
Running the Communications Suite Directory Server setup script, comm_dssetup.pl, to configure Directory Server.
Installing the Calendar Server 7 software by using the Communications Suite installer.
Running the Calendar Server 7 configuration script (init-config) to initially configure your site's specific requirements.

For more information, see Calendar Server Installation and Configuration Guide.

Data Migration

See the topic on migrating from Sun Java System Calendar Server 6 to Calendar Server 7 in Calendar Server Installation and Configuration Guide.

Special User Accounts

Calendar Server 6.3 special accounts include the following:

Calendar Server Administrator (calmaster) Account
Superuser (root)
Non-root User (icsuser, icsgroup)

Calendar Server 7 special accounts include the following:

Calendar Server Administrator (calmaster) Account
Calendar Server User and Group Accounts
Superuser (root)
mysql user and group
GlassFish Server Administrator Account

Proxy Administrative Accounts

In Calendar Server 6.3, to enable administrators to administer user calendars, the default value for the following parameter in the ics.conf file is set as shown:

service.http.allowadminproxy="yes"

There is no equivalent in Calendar Server 7. That is, you cannot disable administrative access to calendar users.

End-User Administration

Administrators with the proper permissions can add, delete, or modify user LDAP entries or resource LDAP entries by using the Delegated Administrator Utility (command line) or Console (GUI). Calendar Server 7 requires Delegated Administrator 7. Calendar Server 6.3 uses Delegated Administrator 6.4.

Additionally, when necessary, you can use ldapmodify to modify LDAP entries directly.

Both servers support Schema 1 and Schema 2. For more information, see Communications Suite Schema Reference.

Calendar Server 7 requires the davEntity object class to set up multiple back-end hosts for horizontal scalability. Calendar Server 7 does not support the Database Wire Protocol (DWP), which was used for distributing calendar data across multiple back-end hosts in Calendar Server 6.3.

Data Formats, Protocols, and Standards

The Calendar Server 6.3 data format is modeled after RFC 5545, Internet Calendaring and Scheduling Core Object Specification (iCalendar).

Calendar Server 6.3 supports Web Calendar Access Protocol (WCAP) 3.0.

The main interface used by Calendar Server 7 to interact with the data repository is the CalDAV protocol, which is based on HTTP. Thus, any client that supports CalDAV, such as Apple iCal and Thunderbird/Lightning, can access Calendar Server 7. Calendar Server 7 supports a newer version of the WCAP protocol, with no guarantee of backward compatibility.

Additionally, Calendar Server 7 supports the server-to-server iSchedule protocol, which means that it can also act as a client. The server also exposes the following HTTP-based services:

Simple free-busy service
Administrative browse UI

Finally, Calendar Server 7 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.

Access Control

Calendar Server 6.3 uses Access Control Lists (ACLs) to determine the access control for calendars, calendar properties, and calendar components such as events and to-do's (tasks).

Calendar Server 7 supports a similar but more user friendly, rich access control mechanism. See the topic on administering Calendar Server access in Calendar Server System Administrator's Guide for more information.

Calendar Server 6.3 also supports access control settings at domain levels control inter-domain access in a multi-domain setup.

Calendar Server 7 supports similar functionality but the ACL format is slightly different and the LDAP attribute used is different from that used by Calendar Server 6.3. See the topic on managing domain access controls in Calendar Server Security Guide for more information.

Public APIs

For Calendar Server 6.3, see the following:

WCAP 3.0: See Sun Java System Calendar Server 6.3 WCAP Developer's Guide.
ENS: See Communications Suite Event Notification Service Guide.

For Calendar Server 7, see Calendar Server WCAP Developer's Guide.

Backup and Restore

When properly configured, the Calendar Server 6.3 csstored service creates automatic backups of the calendar database. You can configure Calendar Server 6.3 for automatic backups either during initial configuration or at a later time.

In Calendar Server 7, you use the davadmin db command to back up and restore the back-end database. There is no automatic database function as there is in Calendar Server 6.3. You can write cron jobs for Calendar Server 7 deployments to perform incremental backups by using the davadmin db backup command.

For more information, see the topic on best practices for backing up and restoring databases in Calendar Server System Administrator's Guide.

Log Files

Calendar Server 6.3 maintains the following log files:

admin
dwp
http
httpd access
notify
store

The default log location is /var/opt/SUNWics5/logs, which you can modify.

Calendar Server 7 maintains the following log files:

commands
errors
scheduling
telemetry
scan

Each log file has its own configuration attribute that controls the log file location, maximum size, and log level. The default log file location is the logs directory, under the data directory that you enter during initial configuration. You can set the logging level for Calendar Server logs either by using the davadmin command or in the GlassFish Server logs by using the GlassFish Server Administration Console.

For more information, see the topic on administering logging in Calendar Server System Administrator's Guide.

Maintaining Configuration Files

You change the Calendar Server 6.3 configuration by adding parameters to or modifying existing parameters in the ics.conf file. The ics.conf file is located in the following directory:

Oracle Solaris: /etc/opt/SUNWics5/cal/config
Red Hat Linux: /etc/opt/sun/calendar/config

You change the Calendar Server 7 configuration by using the davadmin config modify command.

Notifications and Reminders

Calendar Server 6 can be configured to use an external generic service called the Event Notification Service (ENS), which accepts reports of server-level events that can be categorized into specific areas of interest. This service also notifies other servers that have registered interest in certain categories of events. Calendar Server 6 uses ENS to send and receive alarm notifications that include the creation, deletion, or modification of calendar events and tasks, as well as general operational warning and error messages.

Note:

The Calendar Server 6.3 software also contains support for Java Message Queue for notification, but csnotifyd does not subscribe to it. Thus, it is not part of the default alarms and notification system. For more information, refer to the Sun Java System Java Message Queue documentation.

Calendar Server 7 provides Java Message Service (JMS) notifications and email notifications for database changes and event or task email alarms. You can configure the server to produce JMS notifications for every database change and every alarm. If you choose, you can write your own subscribers to these notifications. In addition, Calendar Server 7 provides a subscriber program, which you can configure, that consumes the JMS notifications and sends email for database changes and email alarms.

How Free/Busy is Calculated for All Day Events

All events are considered to calculate busy time unless explicitly marked as transparent. The time blocked corresponds to the event timings in the event's time zone. For floating events (events with no associated time zone) and all day events, the busy time is calculated in the calendar's time zone. For example if there is a floating event from 12 pm to 1 pm, for lunch, in a calendar whose time zone is America/Los_Angeles, for free/busy calculation purposes, the event would be considered as a 12 pm to 1 pm event in the America/Los_Angeles time zone.