This chapter discusses the differences between Oracle Communications Calendar Server and Sun Calendar Server (also known as Sun Java System Calendar Server 6), as well as the issues for a coexistent deployment.
Oracle Communications Calendar Server is Oracle's next-generation Calendar Server, which supports the new standard for calendar access called Calendaring Extensions to WebDAV (CalDAV).
Oracle Communications Calendar Server is a newly designed server and replaces Calendar Server 6. Oracle Communications Calendar Server 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. Oracle Communications Calendar Server supports the standard CalDAV access protocol, which makes it usable with Apple iCal, iPhone, Thunderbird Lightning, and any other CalDAV client.
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
Oracle Communications Calendar Server is a servlet that you deploy into a web container (Oracle GlassFish Server). Thus, Oracle Communications Calendar Server does not contain its own start and stop programs, unlike Calendar Server 6. You start and stop Oracle Communications Calendar Server through the GlassFish Server asadmin command. The administrative commands have been completely rewritten as well for Oracle Communications Calendar Server. The Oracle Communications Calendar Server commands do not have one-to-one mapping to the Calendar Server 6 commands.
For more information about administering Oracle Communications Calendar Server 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 Oracle Communications Calendar Server uses a separate SQL 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.
You can install Calendar Server 6 and Oracle Communications Calendar Server 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).
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 |
Installing and configuring Calendar Server 6 consists of the following high-level steps:
|
|
Oracle Communications Calendar Server |
Installing and configuring Oracle Communications Calendar Server consists of the following high-level steps:
|
For more information, see Calendar Server Installation and Configuration Guide.
See the topic on migrating from Sun Java System Calendar Server 6 to Oracle Communications Calendar Server in Calendar Server Installation and Configuration Guide.
Calendar Server 6 special accounts include the following:
Calendar Server Administrator (calmaster) Account
Superuser (root)
Non-root User (icsuser, icsgroup)
Oracle Communications Calendar Server 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
In Calendar Server 6, 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 Oracle Communications Calendar Server. That is, you cannot disable administrative access to calendar users.
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). Oracle Communications Calendar Server requires Delegated Administrator 7. Calendar Server 6 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.
Oracle Communications Calendar Server requires the davEntity object class to set up multiple back-end hosts for horizontal scalability. Oracle Communications Calendar Server does not support the Database Wire Protocol (DWP), which was used for distributing calendar data across multiple back-end hosts in Calendar Server 6.
The Calendar Server 6 data format is modeled after RFC 5545, Internet Calendaring and Scheduling Core Object Specification (iCalendar).
Calendar Server 6 supports Web Calendar Access Protocol (WCAP) 3.0.
The main interface used by Oracle Communications Calendar Server 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 Oracle Communications Calendar Server. Oracle Communications Calendar Server supports a newer version of the WCAP protocol, with no guarantee of backward compatibility.
Additionally, Oracle Communications Calendar Server 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, Oracle Communications Calendar Server offers a Java Management Extensions (JMX) 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.
Calendar Server 6 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).
Oracle Communications Calendar Server 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 also supports access control settings at domain levels control inter-domain access in a multi-domain setup.
Oracle Communications Calendar Server supports similar functionality but the ACL format is slightly different and the LDAP attribute used is different from that used by Calendar Server 6. See the topic on managing domain access controls in Calendar Server Security Guide for more information.
For Calendar Server 6, 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 Oracle Communications Calendar Server, see Calendar Server WCAP Developer's Guide.
When properly configured, the Calendar Server 6 csstored service creates automatic backups of the calendar database. You can configure Calendar Server 6 for automatic backups either during initial configuration or at a later time.
In Oracle Communications Calendar Server, 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. You can write cron jobs for Oracle Communications Calendar Server 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.
Calendar Server 6 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.
Oracle Communications Calendar Server 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.
You change the Calendar Server 6 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 Oracle Communications Calendar Server configuration by using the davadmin config modify command.
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 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.Oracle Communications Calendar Server 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, Oracle Communications Calendar Server provides a subscriber program, which you can configure, that consumes the JMS notifications and sends email for database changes and email alarms.
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.