Service Discovery
The Web Analysed in ODP terms

Tabulated below are the results of an exercise to identify the steps required to discover and access services. They are described in generic terms familiar to those who work in the open distributed systems field, then in Web terms alongside. This provides some insights into how closely the Web can be construed to be compliant with the ODP model. The big assumption (cheat) made, is that systems designed for human as against machine interaction are comparable. If the comparison holds up, it implies (as a generalisation) that the Web is merely deficient in the structure of its data, rather than in its functional elements.

The concepts service, service type, service discovery and service access are used here as defined in Discovery and Access of Services in Globally Distributed Systems, and the type repository function and functions of trading, locating and naming are defined in the ISO/ITU Reference Model for Open Distributed Processing (RM-ODP) which is a framework, defining concepts and functions in open distributed processing.

Service Discovery & Access in ODP Terms Figure 1 - Steps in Service Discovery & Access in ODP Reference Model Terms

Table 1 - Steps between opening a service for business and the first clients walking through the door

Generic distributed system
Web implementation
Service Export
(some parts may have to repeat regularly for dynamic services)
1The service must have its name(s) registered against its address(es) in the name server (pre-supposing allocation of these uniquely) A name for the service is placed somewhere that potential clients already go (e-mail, Web document) with the URL beneath it (i.e. a hyper-link). A page of hyper-links is a name-server (albeit unidirectional) and the Web is a massive scale federation of name servers
2Type(s) need to be chosen by which it is sensible to classify the service and which are known of by the (extensible) type repository The service is classified by the provider and gradually by those that use it, usually in their natural language, but also in the classification graphs of popular indexes Natural language descriptions are a major step towards machine-readable classification systems and point to the need for classification in many alternative contexts
3The service needs its name to be registered against the type of service on offer in the trader hyper-links to the service are gradually placed in popular indexes, in relevant Web pages, news postings and e-mails The Internet is a massive scale federated trader database from the point of view of services
Service Discovery
4, 5, 6, 7The client needs to choose a type of service (and possibly properties) which describes what is required and exists in the type repository (which may interact with the trader for sub-types) The user browses down an index choosing the most likely categories presented or scans the results of a search engine query (a few tries of the links out of the index may be required before a good path is found) It is impractical to propose global standards for service type definitions. In a massive scale federation the service types can only have meaning within a context that contains that service
8, 9The client receives a service name(s) from the trader that best satisfies the requirements description A resource is found which appears to have the right context and contains a hyper-link with a tempting name The Web is a massive scale federated trader database from the point of view of clients
10, 11, 12, 13The client puts the service name(s) to the locator which interrogates the name server to find the address(es) to which these names map. The locator then decides on the best service address for this particular request and returns it to the client The hyper-link doesn't directly access the service required, but presents choices of hyper-links with the relative merits of each described. The user chooses the "best" hyper-link (closest, fastest) Parts of the Web already act as locators (although this is not at all prevalent)
Service Access
14The client uses the address to contact the service The hyper-link chosen directs the client to the service address underlying it -

It can be seen that the Web does indeed contain all the functions that the ODP model would suggest should be present.

Cick here Useful conclusions can be drawn by considering how it is that one (rather large) assumption can make the Web nearly conform to the ODP reference model (in terms of service access and discovery).

Bob Briscoe, BT
last modified on 25 March, 1996