[Version 5.0.1 and later]Location service daemons

Location service daemons provide the CORBA location service in support of Remote Method Invocation and Internet Inter-ORB Protocol (RMI/IIOP).

When a client makes a remote call to an enterprise bean, a location service daemon determines which server or servers are eligible to process the request. The location service daemon makes the decision with the z/OS workload management function (WLM). The daemon then routes the request to the selected server, which establishes a CORBA session with the client. Subsequent calls to the same enterprise bean flow directly over the established session.

One location service daemon is available for each system in a cell. An example of a system is the z/OS operating system on a logical partition (LPAR). There are two options for daemon existence - a base application server environment and a network deployment manager environment. It is important to understand that in the creation of a Network Deployment configuration, a node goes through two life cycles: first, as a Base Application Server node; and then, when federated, a Network Deployment configuration node. In both phases of its life, the node relies upon the services of a Daemon, but the Daemon it relies upon is different before federation as compared to after.

All nodes must have access to the services of a Daemon. A Base Application Server node has its own Daemon. After federation the newly federated node will rely upon a different Daemon. What Daemon a federated node will use after federation is dependent on whether that node is on the same MVS image as the Deployment Manager or not.

Base Application Server node federated into Deployment Manager cell on same MVS image

When a Base Application Server node is federated into a Deployment Manager cell on the same MVS image, the Base Application Server's Daemon is set aside. The federated node starts using the Deployment Manager's Daemon. For example, when a Base Application Server node is federated into a Deployment Manager cell on the same MVS image, the already existing Deployment Manager Daemon simply picks up more work, while the original Base Application Server node's Daemon is no longer used.

A Base Application Server node's Daemon should be considered temporary. It is only used until the node is federated. Thereafter, the Base Application Server's Daemon is no longer used. That means the following things are temporary when a Base Application Server is intended for eventual federation into a Deployment Manager cell:

Base Application Server node federated into Deployment Manager cell from different MVS image

Things are slightly different when the Base Application Server node being federated is on a different MVS image from the Deployment Manager. The original Base Application Server Daemon is still set aside, but a new Daemon is created.

There are two points to be made here:




Searchable topic ID:   cagtlocsrvdmn
Last updated: Jun 21, 2007 9:56:50 PM CDT    WebSphere Application Server for z/OS, Version 5.0.2
http://publib.boulder.ibm.com/infocenter/wasinfo/index.jsp?topic=/com.ibm.websphere.zseries.doc/info/zseries/ae/cagt_locsrvdmn.html

Library | Support | Terms of Use | Feedback