|Oracle Calendar Server Administrator's Guide
Part Number B10093-01
This chapter examines the overall structure of the calendar server. An introduction to the concepts and terminology involved is followed by an examination of the function of the calendar server daemons/services, and an illustration of the basic internal operations and processes involved in client connections.
Note that the Oracle Calendar server included with Oracle Collaboration Suite requires the use of Oracle Internet Directory. Therefore, for any areas of the Oracle Calendar server documentation that describe differences between "internal-directory" and "external-directory" installations, the "external-directory" information can be assumed to apply to your installation.
This section is a quick introduction to the concepts and terminology at the heart of the calendar server design. More detail on these subjects are presented in following chapters. This information is intended as a preliminary to the architectural and structural information below.
A host is the physical machine running an installation of the calendar server. Only one installation of the server may be present on any one host, but that server may contain multiple nodes.
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 on the same server. Nodes may also be connected into a node network, allowing users on separate servers to schedule meetings and events transparently with one another.
A cluster is a node network in which one node is designated the "master node". The master node coordinates network management, finding user accounts on installations spanning multiple nodes and hosts. Use of a cluster type of network is optional.
The calendar server contains four UNIX daemons/multi-threaded Windows NT services, with an extra daemon/service added for implementations connected to an external LDAP directory server. The calendar server daemons/services are:
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.
The Engine (
uniengd) accepts and services client requests. Since many of these requests can be received at the same time, the servicing Engines rely on the Lock Manager to ensure orderly access to local nodes. 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 Synchronous Network Connection daemon/service (
unisncd) 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.
In its second function, used only in implementations with an external directory server, the
unisncd acts as a broker, granting connections to the Directory Access Server (
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.
For technical information concerning the configuration of the Synchronous Network Connections daemon/service, including a list of parameters and their default values, see the calendar server Reference Manual, Appendix B, "Server Parameters." Unless otherwise indicated, the Synchronous Network Connections daemon/service must be restarted in order for a configuration change to take effect.
The Corporate-Wide Services (
unicwsd) daemon/service allows the exchange of information between users who reside on different nodes. People on one node may need to view calendar information or schedule events with users from another node. This service also provides e-mail notification through an SMTP mail server and wireless notification through Oracle's wireless services.
unicwsd communicates with other nodes using TCP/IP sockets and named pipe connections. These links provide fast communication and instant free-time lookups when scheduling an event. The TCP/IP sockets and named pipe connections are provided and managed by the Synchronous Network Connection daemon/service (
The Corporate-Wide Services daemon processes local requests for remote information as well as requests from other nodes for local information. Local requests are requests for information concerning users on another node, or to send mail messages to remote users. These requests are made by the users on the local node and are put in a local queue. The Corporate-Wide Services daemon/service processes the requests by reading them one after another from the queue. If a TCP/IP connection is available, the information requested by the local user can be accessed by connecting directly to the other node.
The only mail handling
unicwsd performs is the sending of notifications when a user creates an event and the attendees need to be notified. These mail notifications are dependent on user-controlled options.
For technical information concerning the configuration of the Corporate-Wide Services daemon/service, including a list of parameters and their default values, see the calendar server Reference Manual, Appendix B, "Server Parameters." Unless otherwise indicated, the Corporate-Wide Services must be re-started in order for a configuration change to take effect.
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 (
Two configurations are presented here. One uses the calendar server's internal directory, and the other uses an external LDAP directory server.
In this configuration, the calendar server uses its internal directory instead of connecting to an LDAP directory server, and does not use the
unidasd daemon/service. The node network may or may not include other calendar servers. For simplicity, a single client session is represented.
The client first connects to the
uniengd daemon/service (1). The
uniengd daemon/service then spawns a
uniengd server for that client session (2). All subsequent requests from the same client are sent to this dedicated
uniengd server. This is referred to as a "persistent connection".
Web clients do not adhere to this model. Instead, the Web client application running on the Web server establishes persistent connections to the calendar server at startup. The client divides these connections among the users actively making requests through their Web browsers.
In the course of 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 server handles reads and writes on the local node (the node containing the user) differently from reads and writes on remote nodes.
To perform reads or writes on the local node, the client's
uniengd server requests access to the node database (
/users/unison/db/<node name>) from the
unilckd. When the
unilckd grants access, the
uniengd performs the read or write operation. It then relinquishes access to the node database, and if necessary, returns data to the client.
To read information from a remote node, the client's
uniengd server requests a connection to the remote node from the
unisncd. When the
unisncd hands it a connection to that node, the client's
uniengd sends the read request to the
uniengd server at the other end of the connection (see "Connections to nodes" below). 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 server. The requesting
uniengd server receives the information, returns the connection to the
unisncd, and hands the information to the client.
Writes to a remote node arise when the user adds, modifies, or deletes calendar and/or user information. In this case, the
uniengd server places a request in the queue of the local node (see "Node request queue" below for a discussion of the node queue). Another
uniengd server associated with this local node services these requests in the same manner as reads on a remote node.
unisncd establishes persistent connections to other nodes on startup, using information in the
nodes.ini file to determine the number of connections to establish to each node. 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 spawns a
uniengd server to handle requests to the specified node. A
uniengd server sits on the end of each connection to a remote node. This diagram does not show the
uniengd server at the end of each connection, nor does it show that each of these
uniengd servers obtains access to their node database from
Although not shown on this diagram, each node has a request queue associated with it. This request queue is maintained within the node database and used by all
uniengd servers associated with the node. These request queues contain requests for SMS and e-mail notification, and requests for replication of data (resulting from creation, modification, and/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 server for each node on the local machine. The
uniengd daemon/service then spawns one
uniengd server per node to service that node's request queue. The diagram shows one of these
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 Oracle9iAS Wireless. If the request is for a write to a remote node, it hands the request to the
uniengd server servicing the request queue of the node.
unicwsd also deletes redundant requests in order to optimize performance.
This configuration is the same as the previous one except that all calendar servers now use an LDAP directory server for user attributes. All nodes in a node network that use a directory server must use the same one.
The notable addition here is the
unidasd server, which handles all interactions with the LDAP directory server.
unisncd reads the
numconnect parameter from the
[YOURHOSTNAME, unidas] section of the
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 (not shown). The
unidasd daemon/service spawns a
unidasd server for each of the requested connections. When a
uniengd server requires directory server access, it requests a connection to a
unidasd server from
unisncd passes a connection to the requesting
uniengd server, which retrieves the necessary information from
unidasd and subsequently returns the connection to
unisncd. Only a single
unidasd server is shown in this diagram.