| Oracle® Calendar Administrator's Guide 10g Release 1 (10.1.2) Part Number B25485-05 |
|
|
View PDF |
| Oracle® Calendar Administrator's Guide 10g Release 1 (10.1.2) Part Number B25485-05 |
|
|
View PDF |
This chapter examines the overall structure of Oracle Calendar server. An introduction to the concepts and terminology involved is followed by an illustration of the basic internal operations and processes involved in client connections, and an examination of the function of the calendar server daemons/services. This chapter contains the following sections:
This section is a quick introduction to the concepts and terminology at the heart of the calendar server design. This information is intended as a introduction to the architectural and structural information later in this chapter. More details on these subjects are presented in following chapters.
Oracle Calendar is scalable calendaring software, based on open standards, for efficiently scheduling people, resources, and events. Among other features, it offers real-time lookups and free-time searches; multiple time zone support, and UTF-8 encoding to support international deployments; e-mail and wireless alerts; multiplatform support and an extensible authentication, compression, and encryption (ACE) framework for enhanced security.
The Oracle Calendar server is the back end to an integrated suite of calendaring and scheduling products. Networked users can use a desktop client (Windows, Mac OS, Linux), Microsoft Outlook, Web client or Oracle Workspaces to manage their calendars. Mobile users can synchronize their agendas with a variety of PDAs or, with the addition of Oracle wireless technology, can send and receive calendar entries using a mobile phone.
Oracle Calendar can be found on the host housing the Applications tier of Oracle Collaboration Suite. Most files relating to the Oracle Calendar server can be found in the subdirectories within $ORACLE_HOME/ocal.
A host is the computer running an installation of the Oracle Calendar server. It is possible to have more than one installation of the calendar server on the same host, except on Windows where only one installation of the server may be present on any one host. When more than one calendar server is installed on the same computer, the two are differentiated by the port number used to access them. This is reflected by the <hostname:portnumber> combination used to access a server using a utility. For example:
uniping -host host1:5730
A node is a local database where the server stores information such as user records, meetings, and events. Each node has a specific, unique identification number called the Node-ID. Multiple nodes may exist for the same calendar server. Nodes may also be connected into a node network, enabling users on separate servers to schedule meetings and events transparently with one another. When the Calendar server is installed, a node is automatically configured.
A cluster is a node network in which one node is designated the master node. The master node coordinates network management, and provides support for finding user accounts on installations spanning multiple nodes and hosts. When master node is in use, Oracle Calendar clients will connect to the master node upon the first login. The Oracle Calendar server will then resolve the node on which the requesting user resides. The Oracle Calendar client will then cache the appropriate node for that user account locally, and connect directly to the appropriate node upon the subsequent login.
Use of a cluster type of network is optional. A cluster type of network, with the first configured node set as the master node is the default at installation when Oracle Calendar is deployed with Oracle Collaboration Suite.
When the Oracle Calendar server is installed, by default it is integrated with the Oracle Internet Directory server and other components of Oracle Collaboration Suite. However, the Oracle Calendar server can also be deployed as a standalone application.
In a standalone installation, the Oracle Calendar server can be configured to use either an external or an internal directory. With an external directory, all user information is stored in a third-party LDAP directory server. With an internal directory, all user information is stored in the calendar server's database.
This Administrator's Guide applies to Oracle Calendar standalone deployments and Oracle Collaboration Suite deployments. Exceptions are noted where there is a difference in behavior or supported functionality between a standalone Oracle Calendar deployment and that of an Oracle Collaboration Suite deployment.
When Oracle Collaboration Suite is installed, the default configuration uses Oracle Internet Directory to store user attributes. All nodes in a node network must use the same directory server. Figure 2-1 shows the Oracle Calendar server internal architecture.
Figure 2-1 Oracle Calendar Server Internal Architecture
For each client it accepts, the uniengd listener either forks a uniengd session process or creates a uniengd session thread. All subsequent requests from a client are processed by to that client's dedicated uniengd session. The connection that exists between a client and the Oracle Calendar server is a persistent TCP/IP network connection. The connection remains persistent until terminated by the client or the server. If the client's network connection is lost, a new client connection must be triggered to establish a connection with the Oracle Calendar server.
|
Note: Web clients do not adhere to this model. Instead, the Web client application running on the Web server establishes a pool of persistent connections to the calendar server at startup. The client divides these connections among the users actively making requests through their Web browsers. |
During a user session, calendar and user information may be viewed, created, modified, or deleted. These operations involve either reads from, or writes to, node databases. The client's uniengd session handles reads and writes on the local node (the node containing the user) differently from reads and writes on remote nodes.
Reads and Writes on the Local Node To perform reads or writes on the local node, the client's uniengd session requests access to the node database ($ORACLE_HOME/ocal/db/<node name>) from the unilckd. When the unilckd grants access, the uniengd session performs the read or write operation. It then relinquishes access to the node database, and if necessary, returns data to the client.
Reads from a Remote Node To read information from a remote node, the client's uniengd session requests a connection to the remote node from the unisncd. When the unisncd passes a connection to that node, the client's uniengd session sends the read request to the uniengd server at the other end of the connection (see "Connections to Nodes" later in this chapter). The remote uniengd server then requests access to its local node database from its unilckd. When the unilckd grants access, the uniengd server retrieves the information, relinquishes access to the node database, and sends the information to the requesting uniengd session. The requesting uniengd session receives the information, returns the connection to the unisncd, and then passes the information to the client.
Writes to a Remote Node Writes to a remote node arise when the user adds, modifies, or deletes calendar or user information. In this case, the uniengd session places a request in the queue of the local node (see "Node Request Queue" later in this chapter for a discussion of the node queue). Another uniengd session associated with this local node services these requests in the same manner as reads on a remote node.
The uninode utility reads information in the $ORACLE_HOME/ocal/misc/nodes.ini file to determine the number of connections to establish to each node, and propagates this information to every node in the node network.
unisncd establishes persistent connections to other nodes on startup, using information stored in the local node(s). It establishes a connection by sending a request to the uniengd daemon/service (the uniengd daemon/service on the local host for nodes on the local machine, and the uniengd daemons/services on remote hosts for nodes on remote hosts). That uniengd daemon/service creates a uniengd session process or thread to handle requests to the specified node. A uniengd session sits on the end of each connection to a remote node. Each of these sessions obtains access to their node database from unilckd.
Each node has a request queue associated with it. This request queue is maintained within the node database and used by all uniengd sessions associated with the node. These request queues contain requests for alerts and e-mail notification, and requests for replication of data (resulting from creation, modification, or deletion of calendar information).
unicwsd manages the request queue of each node on the local host. On startup, unicwsd sends a request to the uniengd daemon/service for a uniengd session for each node on the local machine. The uniengd daemon/service then creates one uniengd session process or thread per node to service each node's request queue. The diagram shows one of these uniengd sessions.
unicwsd examines each request in the request queue and determines how to handle it. If the request is for a mail notification, it hands the mail to the mail server. Similarly, it passes requests for wireless reminders and notifications to Oracle Mobile Collaboration. If the request is for a replication to a remote node, it hands the request to the uniengd session servicing the request queue of the node. unicwsd also deletes redundant requests in order to optimize performance.
On startup, unisncd reads the numconnect parameter from the [YOURHOSTNAME, unidas] section of the $ORACLE_HOME/ocal/misc/unison.ini file to determine the number of connections to establish to the LDAP directory server. It then sends a request to the unidasd daemon/service. The unidasd daemon/service spawns a unidasd server for each of the requested connections. When a uniengd session requires directory server access, it requests a connection to a unidasd server from unisncd. unisncd passes a connection to the requesting uniengd session, which retrieves the necessary information from unidasd and subsequently returns the connection to unisncd.
The calendar server can contain up to six UNIX daemons or multithreaded Windows processes. The calendar server daemons/services are discussed in the following sections:
The Engine (uniengd) accepts and services calendar requests. All communication with the calendar database is handled by the engine. At startup, a series of uniengd daemons/services are started automatically for each node.
The first uniengd process created is the uniengd Controller. It then creates multiple uniengd Listeners. A listener listens for incoming client connections and (depending on the operating system) either starts uniengd session processes or creates uniengd session threads for each client it accepts. At least one of the uniengd sessions belongs to the Synchronous Network Connection daemon (unisncd described later in this chapter).
Because many of the calendar requests can be received at the same time, the servicing engines rely on the Lock Manager to ensure orderly access to the database of the local node (see Oracle Calendar Lock Manager later in this chapter). Therefore, the Lock Manager must be running in order for the engine to function. The engine must be running in order to operate the calendar server.
The Lock Manager (unilckd) queues and processes the many requests for access to the calendar server's database. The Lock Manager must be running in order to operate the calendar server. Typically, one lock manager exists per node. However, on UNIX, it is possible to have more than one lock manager per calendar server when more than one node is configured for the same calendar server. This is controlled by the server parameter [LCK] maxnodesperlistener.
|
See Also: For more information about the[LCK] maxnodesperlistener parameter, see "Calendar Server Parameters" in Chapter 3 of Oracle Calendar Reference Manual. |
There is one Synchronous Network Connection daemon/service (unisncd) per server which services every node. It fulfills two roles in the server architecture. First, the unisncd is used to maintain open TCP/IP connections between nodes, and to grant those connections to clients that request access to another node. Each connection is unidirectional, from the current node to another node, but not vice versa. It is therefore important to ensure that node connections are set in both directions.
The Synchronous Network Connection daemon/service grants connections on a first in, first out basis. Requests that cannot be processed immediately are put in a queue. The number of connections between two nodes may be increased or decreased to minimize both the number of connections used and the traffic and connection time between two nodes. If a Synchronous Network Connection daemon/service loses a connection due to network problems, it will attempt to reconnect later.
In its second role, it is used in implementations with an external directory server, the unisncd acts as a broker, granting connections to the Directory Access Server (unidasd).
The configuration of the Synchronous Network Connections daemon/service is controlled by several server parameters, and the uninode utility. Unless otherwise indicated, the Synchronous Network Connections daemon/service must be restarted for configuration changes to take effect.
|
See Also: For more information about the[SNC] parameters used to configure the Synchronous Network Connections daemon/service, see"Calendar Server Parameters" in Chapter 3 of Oracle Calendar Reference Manual.
For more information about the |
The Directory Access Server (unidasd) is used to maintain open connections to an LDAP directory server. Connections to the Directory Access Server are granted by the Synchronous Network Connection (unisncd) daemon/service. The unidasd daemon/service is not used when there is no external directory. By default, more than one unidasd is started when the calendar server is started.
The number of unidasd connections to establish to the directory server is defined by the server parameter numconnect in [<YOURHOSTNAME>,unidas] section of the unison.ini file. If this parameter is set too low, the server may not be able to handle all requests made for directory server operations, in which case end users will get errors of the type "Unable to contact directory server".
|
See Also: For more information about the server[DAS] parameters used to configure the Directory Access Server daemon/service, see "Calendar Server Parameters" in Chapter 3 of Oracle Calendar Reference Manual. |
The Corporate-Wide Services (unicwsd) daemon/service replicates data between nodes and provides e-mail notification through an SMTP mail server and wireless notification through Oracle's wireless services. It also processes server-side reminders (SSR) and synchronizes the calendar database with the directory server when necessary.
unicwsd communicates with other nodes using TCP/IP sockets and named pipe connections. These links provide fast communication. The TCP/IP sockets and named pipe connections are provided and managed by the Synchronous Network Connection daemon/service (unisncd).
By default, two unicwsd daemons/services are created when the calendar is started, one for the replication of calendar data between nodes and one for all the other tasks (mail, reminders, and so on).
For each of the following activities one CWS (Corporate-Wide Services) job can be enabled:
ABSync: Synchronizing the Common Address Book with OiD
ConsistencyScan: Scanning the database for inconsistencies
DirProv: Performing notification based calendar account provisioning
DirSync: Synchronizing with a directory server
EventCalendar: Replicating Event Calendar events to all nodes
EventSync: Updating synchronization data for events recently modified
GALSync: Synchronizing the Global Address List
LogRotation: Rotating the Calendar server log files to the attic location
Messaging: Messaging requests for e-mail, wireless alerts, and RTC
Replication: Node to node data replication
Snooze: Handling snoozed requests
SSR: Server-side reminders
A CWS task is a process that handles one or more jobs.
The server can be configured to support one or many separate processes per job using server parameter [CWS]prioritizedjobs and the maximum number of nodes a Corporate-Wide Services task can service can be configured using [CWS] maxnodepertask. Unless otherwise indicated, the Corporate-Wide Services must be restarted in order for a configuration change to take effect.
|
See Also: For more information about the[CWS] parameters used to configure the Corporate Wide Services service/daemon, see"Calendar Server Parameter" in Chapter 3 of Oracle Calendar Reference Manual. |
Whenever a client performs an operation that requires a service from the Corporate-Wide Services daemon, a request is put in a local queue and the appropriate unicwsd will service it depending on the type of the request. A unicwsd daemon/service processes the requests by reading them from the queue.
When a remote node is temporarily shut down, replication requests destined for that node are accumulated in the queue and tagged as on hold until the node becomes available again. Similarly, if for any reason mail cannot be sent, mail notification requests accumulate in the queue. The utility unireqdump can be used to output the set of requests currently in the queue of the Corporate-Wide Services daemon/service.
|
See Also: For more information about theunireqdump utility, see "Calendar Server Utilities " of Oracle Calendar Reference Manual. |
The Calendar Server Manager or CSM (unicsmd) provides the capability for remote administration of the calendar server. The following administrative operations use the services provided by the CSM:
Starting a remote server
Stopping a remote server
Obtaining the status of a remote server
Stopping a node located on a remote server
Starting a node located on a remote server
Before you can start a server remotely, the server must be in stand-by mode. In this mode, all daemons/services are stopped except for unicsmd, which is left up and running and waiting for a remote calendar request. If a server is stopped completely (all daemons/services are stopped including unicsmd), it will not be possible to restart it remotely.
At installation, the CSM is configured with the parameters in the [CSM] section of the $ORACLE_HOME/ocal/misc/unison.ini file. The port parameter specifies the TCP port on which the unicsmd daemon/service listens. This port must be open (as is the port for uniengd) on any firewall for remote management of the server to be possible. To disable remote management of the server, set the enable parameter to FALSE.
In a standalone installation of the calendar server, the password parameter must be specified in the [CSM] section of the unison.ini file. This will be the password to access the local calendar server through unicsmd from a remote location. The password must be encrypted using the uniencrypt utility.
|
See Also: For more information about the server parameters mentioned above, see"Calendar Server Parameters" in Chapter 3 of Oracle Calendar Reference Manual. |
|
See Also: For more information about theuniencrypt utility, see "Calendar Server Utilities" of Oracle Calendar Reference Manual. |
When Calendar is deployed with Oracle Collaboration Suite, the SYSOP password is used. The ACE (authentication, compression and encryption) framework is not used when authenticating remotely using the CSM. For more information about ACE, see Appendix C, "Calendar Security".
|
Note: There is only one password for remote access. Two administrators who remotely manage the same server will use the same password, and there will be no way of determining who did what. |
The calendar utilities that use the services of the CSM are unistart, unistop, unistatus, and the Calendar Administrator. When accessing a remote server, you invoke the local utility with the host name and port number of the remote server's CSM, using the -csmhost option. The CSM password (for standalone installations) or SYSOP password of the remote server must be supplied. For example:
% unistart -n 120 -csmhost hercules:7688 Passwd:
The local utility communicates with the remote CSM, which invokes the remote version of the utility. Error codes and output produced by the remote utility are passed back and displayed by the local utility. However, any log output is only written to the log files on the remote host. Sign in to the remote host directly to access the log files.
|
See Also: For more information about theunistop, unistart and unistatus utilities, see "Calendar Server Utilities" of Oracle Calendar Reference Manual. |
You can also use the Calendar Administrator to manage a calendar server remotely. As with the utilities, you must enter the remote host name, CSM port, and password.
Note that the CSM is an optional part of the Oracle Calendar server. Whether unicsmd is up or down, it has no effect on the local calendar operations. Normal calendaring operations are not affected by CSM failure. Only the ability to manage the server remotely is affected.
The remote administration is cross-platform: a calendar server on a Windows system can be started remotely from a calendar server on a UNIX system and vice versa.
