SLP Agents and Processes
The following table describes the agents and processes that make up the SLP framework.
Table 1-1 SLP Agents and Processes|
The directory agent (DA) is an optional SLP agent that stores and maintains a cache of service advertisements sent by the service agent (SA). When deployed, the DA resolves user agent (UA) service requests. The DA responds to active solicitations from the SA and UA for directory advertisements. Consequently, the SA and UA discover the DAs and scopes (see below) with which they are associated. A DA sends periodic unsolicited advertisements through which UAs and SAs discover the DA within shared scopes. |
|
|
The service agent (SA) maintains service advertisements for a networked service. If no DA is available, the SA answers multicast service requests from UAs. If a DA is available, the SA registers and, optionally, deregisters services with DAs that support its scopes. |
|
|
The user agent (UA) acts on behalf of the user application and queries for the identity of its corresponding scopes, directory agents, and service advertisements. |
|
|
A scope is a grouping of UAs and SAs arranged either administratively, topologically, or in another organizational manner. You can use scopes to tailor how you provision service access across the enterprise (see Chapter 5, Configuring Scopes). |
|
|
In the Solaris implementaion of SLP, slpd is a daemon process that acts as either a DA or an SA server. Service processes on a host register their service advertisments with slpd rather than maintaining the advertisements individually. These service processes contain an SA client library that communicates with slpd, acting as the SA server. slpd forwards all registrations and deregistrations to DAs, and times out expired service advertisements. slpd also maintains a table of available DAs by performing active and passive DA discovery. Through these mechanisms, DA information is provided to UA clients. UA clients use slpd on their host only for DA information. Each SLP host automatically has an slpd daemon. You can optionally configure slpd as a DA. |
|
|
A legacy service is a networked service that is not SLP-enabled. Legacy services can be supported, provided that a proxy registration is created for them. Proxy registrations enable you to register non-SLP-enabled services with SLP. SLP-based clients can then discover legacy services (see Chapter 7, Incorporating Legacy Services). |
|
|
A service advertisement is a URL and a collection of attribute/value list pairs that describe a service. All service advertisements have a lifetime. After the lifetime expires, the service advertisement is no longer valid, unless reregistered. |
|
|
A service URL is used to advertise the network location of services. It contains the service type name, host name, or network address of the system hosting the service, optional port number, and other information necessary to use the service. |
The following figure shows the basic agents and processes that implement the SLP architecture.
Figure 1-1 SLP Basic Agents and Processes
The figure above also represents a default deployment of SLP in which no configuration has been done. Only two agents are required, the UA and SA. The SLP framework allows the UA to multicast requests for services to the SA. When the SA receives requests for a service that it advertises, it unicasts a reply to the UA containing the service advertisement.
The following figure shows the basic agents and processes that implement the SLP architecture when a DA is deployed in the framework.
Figure 1-2 SLP Architectural Agents and Processes Implemented with a DA
In more complex enterprises, one or more DAs are used. The DA serves as a cache for registered service advertisements. SAs send register messages (SrvReg) that list all the services they advertise to DAs and receive acknowledgments in reply (SrvAck). The service advertisements are refreshed with the DA, or they expire according to the lifetime set for the advertisement. Once a UA discovers a DA, UAs unicast requests to DAs rather than multicasting requests to SAs.
For more information about Solaris SLP messages, refer to Appendix A, SLP Message Types.
- © 2010, Oracle Corporation and/or its affiliates