3 About the Control and Daemon Servers
This chapter provides information about the Control and Daemon servers and configuration parameters associated with these servers.
About Control Servers
The Control server is an application server that controls all other Oracle Communications ASAP applications and manages system startup and shutdown. For more information about starting up ASAP, see ASAP System Administrator's Guide.
The Control server consists of application processes running in the background as servers and clients. Application processes can be configured using the Service Activation Configuration Tool (SACT) (see "Configuring ASAP Servers"). ASAP uses service activation request manager (SARM), network element processors (NEPs), and Admin processes as an application server, and they are configured to run as part of the system.
The Control server starts these applications by first verifying that the UNIX program executable file for the application server is located in the ASAP_home/programs directory and is executable. If it is executable, the Control server spawns a child process, which in turn overlays itself with the application executable. At this point, the application process returns details of the application back to the Control server.
The Control server manage alarms generated by the individual server processes. For more information see "Control Server Alarm Generation."
The Control server monitors every client and server application in the ASAP system. If an application terminates unexpectedly, the Control server generates the alarm for the relevant operational community and can also attempt to restart a terminated process. For information about alarm configurations, see the chapter about monitoring and managing ASAP in ASAP System Administrator's Guide. For more information about configuring Control server monitoring and setting process restart attempts, see "Control Server Database and File System Monitoring."
After the application processes have been identified based on your service requirements, determine the Host machine for each process. You can use a single machine or multiple machine configuration to run the ASAP system.
About the ASAP Daemon Server
The ASAP daemon makes it possible for the Oracle WebLogic Server instance to reside on a different machine than the one on which an ASAP instance resides. Consequently, the ASAP daemon manages I/O operations required by WebLogic Server against a remote ASAP instance.
The ASAP daemon handles the file I/O operation requests issued from another UNIX user group or another machine. The ASAP daemon accommodates I/O operations between ASAP applications that use a WebLogic server, such as the SACT, Service Activation Deployment Tool (SADT), and Java SRP.
Specifically, the ASAP daemon supports WebLogic Server applications to do the following:
-
File operations against an ASAP instance, as an alternative to Java's File class:
-
ASAP file read or write
-
ASAP file/directory state checking, such as isFile, canRead, canWrite, exists, length, or lastModified time
-
Other ASAP file manipulations, such as delete, renameTo
-
-
Special commands performed on the ASAP side:
-
File copy from source to target
-
File move from source to target
-
File extract from a jar to a certain file
-
Run a script
-
Other special commands
-
Figure 3-1 displays I/O operations for an ASAP instance on a UNIX file system, such as reading and writing a file, or executing a UNIX command or ASAP script. Some methods of accessing ASAP or the UNIX file system, such as RPCs and JDBCs, are independent of the daemon.
