Service discovery

Before a client can use a service, it must find where it is
The process can be just between a client and service, or use a third agency such as a directory service
The client can ask for services which are waiting for requests
Services can advertise to clients which are waiting for adverts
Some sort of fixed address may be used (lookup) or a more dynamic search (discovery)

Service adverts

Services can tell a known client about themselves
This can be done on startup, and every time they change state
This requires a means of directly addressing clients e.g.
- A TCP host id and port
- A firewire identifier
Services can broadcast to anyone listening about themselves
The broadcast can be done regularly, or every time the service changes state
This requires a means of broadcasting to many listeners e.g
- IP multicast

Adverts

Adverts can just consist of a service identifier e.g an ethernet card MAC address. Matching must be done knowing this identifier
They can be a simple string saying what the service is e.g. an RMI registry entry such as "FileClassifier". Matching must be done using this string
They can be a string representing a structured object such as "printers/postscript/HP20". Matching could then be done using patterns e.g. "printers/postscript/*"

There could be a set of strings, for name plus attributes


      type: printers/postscript/HP20
      speed: 24ppm
      colour: yes

The advert could be an object class such as FileClassifierImpl.class. Matching could then be done in a type-safe manner, by class or superclass

The advert could be a set of objects: service class plus attribute objects


      service: HP20.class
      attribute: new Speed(20)
      attribute: new HasColour(true)

Client lookups

If the client knows a direct address of a service, it can make requests directly
A client can listen for broadcasts adverts and select those it wants
A client can form a description of desired service and ask a known directory service if it knows any services matching the request
A client can form a description of desired service and broadcast the description
- Services listening for requests can see if they match and reply directly
- Directories listening for requests can see if they match and reply directly with a list of services

Directories

From a service view, directories are special clients that don't want to call services but just keep information about them
From a client view, directories are special services whose role is to return lists of other services that match requests
Directories can be at "well known" locations or may need to be searched for
Directories may know about other directories, and pass on requests that they can't handle themselves
Directories may search their store of adverts in various ways e.g. a set of strings
- may match on service type only, and return the set of attributes for the client to match
- may match on service type and attributes as well
- may only do exact string matches, or allow some sort of pattern matching
Directories may keep adverts until the service removes them, or may only keep them for a short time, requiring "renewals" of advert

HAVi

Each device (or functional component of a device) has a unique 10 byte SEID (Software Element Identifier). This is made up of a GUID and a swHandle (element within a device)
Information about each device or functional component is stored in system-wide registry (present on each LAV and FAV)
The registries are federated, so a query to one is sent to all the others, and their replies are collated
Registry keeps SEID plus attributes
Each attribute is a 31 bit indentifier plus arbitrary length value
Predefined attributes include: VendorID, DeviceClass, DeviceModel, UserPreferredName
The type attribute is associated with different APIs for different devices: DCM, APPLICATION_MODULE, GENERIC_VCR, etc

HAVi service discovery

Services register by


      Registry::RegisterElement(in SEID seid,
                                in sequence<Attribute> table)

Clients lookup the registry using


      Registry::GetElement(in SimpleQuery, out sequence<SEID> seidList) 
      Registry::MultipleGetElement(in ComplexQuery query, out sequence<SEID;gt; seidList)

There are no broadcast mechanisms, and all discovery is done using the registry
The registry supports a comparison operation which includes
- equals, not equals, greater than, etc
- bitwise and/or
- sequence equals, greater than, etc

A simple query is


      struct SimpleQuery {
          AttributeName   attr;
          sequence   compareValue;
          CompOperation   compareOp;
      }

A complex query is performed on two sequences of SEIDs - not quite sure what this does - some sort of recursive hack

Service Location Protocol

SLP is an IETF (Internet Task Force) standard for service discovery and execution (RFC 2608)
It assumes the TCP/IP protocol suite (including UDP and multicast)
There is a standardised C API, and a Java one in development
It is "a decentralised, scalable and extensible protocol for service discovery within a site. It allows but does not require centralized administration."

Service request

A client may multicast a service request to all possible services
Each suitable service will send a service reply giving their location

Directory Agents

Directory Agents (DAs) may also exist to store service adverts
A DA is just a special kind of service
Clients and services discover directory agents by
- the address may be hard-coded into the client/service
- a DHCP request can be made to find if any DHCP servers know DA addresses
- a client or service issues a multicast service request for "Directory Agent" when they start, and each DA will reply will reply with a unicast Directory Agent Advert
- DAs will send out multicast Directory Agent Adverts every now and then, which clients and services acan be listening for
A service can register with a DA by a unicast service registration
A client can send a service request by unicast to a DA and get a list of services meeting the request that the DA knows about

Scoping

Services, DAs and clients all have a "scope"
The scope is to allow them to be partitioned in some way e.g.
- Monash students scope
- Monash admin staff scope
- Caulfield campus scope
The scope is just a string

Adverts

A service advert consists of service type and address and optional attributes

The service type and address are given as a url e.g.


      service:ftp://www.monash.edu.au:8080

The attributes are given in a single string of the form


      tag=value, tag=value, ...

e.g


      "volume=5, channel=SBS"

Services should be defined by a Service Template (RFC 2609)

Service matching

For a service to match a service request
- the service must belong to at least one requested scope
- the service must support the requested type
- the service must satisfy the "request predicate" i.e. pattern match
- the service must not be in the request's "already known" list
- e.g. with no filter
```
	    <type=service:printer>
	    <scope="Bldg B, Bldg C">
	    <known=""> 
	    
```

The predicate is an LDAP search filter e.g


      (& (queue_length < 4) (ppm > 20))

Advert expiry

A service advert specifies how long the adverts should be kept
The lifetime is anything between 0 and 0xffff (about 18 hours)
Entries are discarded if they are not renewed within the lifetime
the DA will at worst have 18 hour old stale entries if the service dies without deregistration
A DA advert can specify the "min-refresh-interval" to stop lifetimes being too short and causing too much network traffic

Invoking services

SLP says nothing about this
SLP is about service discovery, not service invocation
How the client and service communicate is upto them: the client knows the service type, the host and the TCP port
The service should have a server running on that host listening on the port, to handle TCP messages for that service protocol

LDAP

LDAP (Lightweight Directory Access Protocol) is also an IETF standard (RFC 2251)
It defines a directory structure for naming nodes in a tree using a naming convention derived from X.500 e.g www.monash.edu.au would be described as node
```
      <country = au>
      <org-type = edu>
      <organisation = monash>
      <server = www>
      
```
A node of the tree has an entry which consists of a set of attributes tag = value of types integer, string, boolean, sequence, etc
LDAP defines how searches are carried out on the tree
- read attributes from a single entry
- read from entries immediately below a particular entry
- read from a whole subtree of entries
LDAP specifies a predicate used to match attributes of entries
LDAP is silent about how it may be located by services that wish to add/modify entries or clients that wish to access entries - in current practise you need to know the address of the LDAP server

Jini

Jini is Java specific middleware to locate (Java) services and to move (Java) mobile objects that represent the service to the client
Clients, services and lookup services (directories) can use multicast to find each other and unicast to communicate directly
Lookup services store services by class and a set of attributes
Lookup is by service implementing or subclassing requested class, and by simple equality matching on attribute values
Lookup is type-safe and cheap, but does not have the boolean capabilities of SLP or LDAP
Mobile objects (e.g. RMI stubs) end up in the client, which can call methods directly

Web services

Personal opinion: web services are a poor implementation of 30 year old technology, implemented in a more clumsy and inefficient manner than the technology it aims to replace
Industry opinion: web services (and particularly .NET services) are the "now" thing, the latest bandwagon to jump onto for at least the next year
Web services are layered
- the SOAP (Simple Object Access Protocol) protocol is the RPC layer
- service description is done using WSDL (Web Services Description Language)
- Service discovery is done using UDDI (Universal Description, Discovery and Integration) directories
Services and clients need to know UDDI locations - no discovery is possible
Service adverts are strings - with weak data types using XML
Service matching is like LDAP matching (???)
RPC references as URLs are returned
RPC calls are made using the SOAP XML-based protocol

Conclusion

There are many ways of locating services
These depend on capabilities of the medium (unicast, multicast) but also on design decisions made by service location architects
The decisions cover a range from "zero configuration" to heavy sysadmin configuration
The references returned from a search are of many kinds
- specialised protocol (e.g. ftp)
- RPC protocol (e.g. SOAP)
- O/O method call protocol (e.g. Jini)

Jan Newmarch <jan@newmarch.name>

This work is licensed under a Creative Commons License
The moral right of Jan Newmarch to be identified as the author of this page has been asserted.