The client architecture includes the following components:
The following picture diagrams the layers of the client management architecture.
Figure 1.7 Client management architecture components.
The top layer of the architecture presents SNA Server Manager information to the user. This includes the SNA Server Manager user interface and automation controllers (such as a Visual Basic application). They typically deal with configuration and management data, and receive notification of changes to the data either by polling or by implementing a special OLE object that is used to inform the application of changes to the underlying objects. The applications open a domain to initiate the reading of the configuration file and obtaining of status data from all SNA Server computers in a subdomain.
The second layer consists of OLE servers for configuration and management data. The OLE servers allow access to the properties and status of a service or resource, an interface for sending commands, and some control functions to facilitate the display of the objects. Communication is achieved with C++ objects in one or more DLLs. The OLE servers are little more than wrappers of the third layer into OLE objects.
The third layer is made up of C++ objects. It links the configuration data and the status information of an object. Every configuration record and management data object must be linked to an item. An item may or may not have a corresponding OLE server object, but every OLE server object must have an item. This is the central glue that holds together the data and the presentation of the data.
This layer is the interface for accessing configuration information. The SNACFG.DLL provides an interface for reading and writing the configuration file and for accessing the various records in the file. It is also used by other parts of the system that need to be configured. SNACFG will support extensions by allowing new record types to be dynamically defined and stored in the configuration file. This preferred method of storage provides a common interface, as well as coherent security, replication, and backup mechanisms.
Multiple management applications can be active simultaneously and share the same management objects. A separate process is responsible for maintaining all the client-server links for a client workstation, which prevents the creation of client-server links for each active application. The combined set of management data is kept in shared memory, where all the client application processes can access it. This is a management database for all the objects that the client machine is managing.
Access to shared memory is via a set of objects. Objects contain data about the various components of SNA Server. Each process has its own copy of the object interfacing to shared memory. The object provides a wrapper for changes to shared memory, and will propagate change notifications to all the processes that have requested notification for that object. Each process may have only a subset of the complete object set. The actual object data is common for all the processes. The objects also enforce access control on the data to prevent conflicts (mutual exclusion).
Each shared management object keeps track of which processes have a reference to the shared data, and what type of notifications each process has requested per object.
The App Notify Queue is used to queue update notifications from the underlying management objects, and to dispatch the queued notifications to the proper item for handling. Each process creates a "notify queue" for receiving events. The events are dispatched to the "notifysink" that is registered to accept messages for the manage object that generated the event. If a new manage object is created, notification is sent to the sink of the parent object.
The App Notify Queue resides in shared memory, allowing the MngCli process to place notifications in the queue and the client application process to remove and process the notifications.
The Proxy Notify Queue is used to queue requests, commands, and notification of changes to the underlying management objects, and to dispatch the queued notifications to the proxy process for handling. It is identical to the App Notify Queue, except that the source and destination are switched.
The Proxy Notify Queue resides in shared memory, allowing the App process to place notifications in the queue and the proxy process to remove and process the notification.
Each process that requires notification of events to manage objects will create a Notify Sink. The Notify Sink is the destination object of an event notification. The sinks do not exist in the shared management objects layer; however, they are used when needed. The Notify Sink receives notification after information is taken out of the queue by a process.
This layer uses Manage Client and Domain control to provide data exchange between clients and SNA Server computers in the subdomain.
This module links the actual manage data on the servers with the shared manage objects. MngCli is started by the SNA Server Manager on the client computer. MngCli opens a connection with each MngAgent in the subdomain through which all management information flows. MngCli receives and sends messages from the SNA Server computers via Manage Agent (MngAgent). It uses the received messages to create, modify, or destroy shared management objects. It accepts commands and notifications from management objects (via a Notify Sink) and sends messages to SNA Server computers.
Domain control is responsible for opening and closing subdomains, discovering the location of configuration servers, and security. It keeps a reference count per subdomain to track when an open subdomain should actually be closed.