| Oracle Calendar Server Administrator's Guide Release 5.5 Part Number B10093-01 |
|
| View PDF |
| Oracle Calendar Server Administrator's Guide Release 5.5 Part Number B10093-01 |
|
| View PDF |
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 (unidasd).
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 (unisncd).
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 (unisncd) daemon/service.
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".
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 unilckd.
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 uniengd servers.
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.
On startup, 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. 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.
|
 Copyright © 1996, 2002 Oracle Corporation. All Rights Reserved. |
|
