- Introduction to the Service Location Protocol
- Deployment scenarios
- Examples
- Why LiveTribe :: SLP does not implement RFC 2614
- Frequently Asked Questions
Introduction to SLP, the Service Location Protocol
One of the key concepts of SLP is the notion of service.
A service is anything that a client (normally a user or a computer) can consume to perform something. Examples of services are mail servers, networked printers, RPC-style services (including web services and Java's RMI servers), etc.
Entities that provide services are called service providers.
SLP defines how these services can be advertised, and how services can be discovered without knowing their network address.
SLP defines the architecture to make the discovery and advertisement reliable, scalable and interoperable between different operative systems and platforms.
ServiceURLs and ServiceTypes
In SLP, a service is identified by a ServiceURL and a language string. The ServiceURL is a URI that contains enough information to locate, connect to and consume that particular service. For example, if a service provider exposes the ability to perform REST-like commands at this URL:
http://myhost:8080/commands
then the service can be represented by this ServiceURL:
service:http://myhost:8080/commands
Note the service: prefix used by ServiceURLs.
A ServiceURL is composed by the ServiceType (service:http), the host (myhost), the port (8080), the path (/commands).
The ServiceURL contains all the information needed by a client to contact the service: the protocol to use to communicate (http), the network address of the service (myhost:8080) and additional information stored in the path (/commands).
ServiceTypes are a way of grouping similar services together. A ServiceType specifies the type of the service but does not tell where the service is located.
In the example above, the ServiceType indicates that the service is an HTTP service that can therefore be accessed by an HTTP client.
A ServiceURL also carries the information about the lifetime of the service. The ServiceURL is generally not available for an indefinite period of time, but has a lifetime beyond which it is not available anymore. It is possible to renew the availability of the service when its lifetime is about to expire, so that distributed systems become more robust to network failures.
For more information about ServiceURLs, RFC 2609 is the master source.
In SLP, a service has scopes, a list of case-insensitive strings, that are used to group similar services together. This grouping is purely a logical grouping decided by the party that provides the service. For example, administration services can be provided under the ADMIN scope, while normal services can be provided under the DEFAULT scope.
In SLP, a service may have attributes, a map of key/value(s) that specify additional information about the service.
Attribute values can be string, integers, boolean or a byte array (also called opaque sequence). An attribute can have more than one value, but the values must be homogeneous.
For example, a service can have these attributes:
requiresLogin=false # A boolean attribute timeout=15000 # An integer attribute name=CommandsExecutor # A string attribute saslMechanisms=ANONYMOUS,PLAIN # A multi-values string attribute
Thus, a complete definition of the example service is:
ServiceURL: URI: service:http://myhost:8080/commands
lifetime: 10800 seconds (3 hours)
Language: en
Scopes: DEFAULT
Attributes: requiresLogin=false
timeout=15000
name=CommandsExecutor
saslMechanisms=ANONYMOUS,PLAIN
ServiceAgents, UserAgents and DirectoryAgents
The SLP standard defines three major entities, called UserAgent, ServiceAgent and DirectoryAgent.
The UserAgent is the entity that discovers services on the network on behalf of a client. A UserAgent allows clients to specify the ServiceType, scope, attributes or language of the services to find. The UserAgent discovers matching services in the network, and returns the matching services to the client. Among the information returned to the client is the ServiceURL of the service, that allows the client to contact the service directly.
The ServiceAgent is the entity that advertises one or more services on behalf of the service provider. A ServiceAgent allows a service provider to register new services, deregister existing services, and modify attributes of registered services.
A ServiceAgent is not the service provider, it merely allows the service provider to advertise services via SLP.
ServiceAgents emit notifications when a service is registered or deregistered. Interested clients (such as UserAgents) can subscribe as listeners for these notifications, so that they can be notified when a new service is registered or when a service is deregistered.
ServiceAgents listen for service requests from UserAgents; if the service request matches one or more services that the ServiceAgent advertises, it replies sending information about the services that matched, otherwise ignores the request.
The DirectoryAgent is the entity that provides scalability to SLP. A DirectoryAgent is a cache for services; ServiceAgents register the services they advertise with DirectoryAgents, and UserAgents contact preferably DirectoryAgents over ServiceAgents to get a list of matching services.
This reduces network traffic due to SLP and allows faster replies to service requests.
Small networks
In small networks, DirectoryAgents are normally not deployed. The only entities present are ServiceAgents, that advertise services on behalf of service providers, and UserAgents, that find services on behalf of client applications.
Large networks
In large networks, DirectoryAgents are deployed and provide caching of services advertised by several ServiceAgents. UserAgents contact DirectoryAgents to find services on behalf of client applications.
