Download
1 / 18
180 likes | 215 Views
Service Discovery Middleware. Introduction. Mobility introduces interesting challenges for the delivery of services to clients. Because mobile devices typically are more resource-poor than their wired counterparts and know much less about their current environment.
E N D
Introduction • Mobility introduces interesting challenges for the delivery of services to clients. • Because mobile devices typically are more resource-poor than their wired counterparts and know much less about their current environment. • While a desktop computer typically has ready access to many peripheral devices such as printers, scanners, and tape backup. • mobile clients are generally not bound to particular infrastructure, trading those bonds for increased freedom.
A service discovery-enabled key chain in a user’s purse could turn on lights, transfer desktop settings, or adjust stereo systems as the user moves about. • Broadly, a service discovery framework is a collection of protocols for developing highly dynamic client-server (CS) applications that standardizes a number of common mechanisms for interaction between clients and services.
Central questions in the design of CS systems include: • What types of services are available? • Where are the services? • How can clients contact services? • What protocols do client and service use? • How can we make CS systems self-healing? • How can we effectively manage system load or enhance fault tolerance by adding redundant components? • How safe is it for a client to use a service or for a service to interact with a particular client?
The most basic interactions between clients and services are service advertisement and service discovery. • Service advertisement allows services to announce their presence when they enter the network and to announce their departure from the network. • The advertisement typically includes necessary contact information and descriptive attributes or information that allows these descriptive attributes to be discovered. • service discovery allows clients to discover dynamically services present either in their local network environment or on a larger scale (e.g., in the global Internet).
The discovery attempt typically includes information about the type of services needed, including the standardized service type name(s) and service characteristics. • These characteristics might identify the specific (geographic) location of a service device capabilities (e.g., duplex capability for a printer) in the case of hardware services, accounting information, such as the cost to use the service. • Whether services are sought directly or a catalog is consulted.
Common Ground • Standardization of services. • Discovery of services. • Service “subtyping.” • Service insertion and advertisement. • Service browsing. • Service catalogs. • Eventing. • Garbage collection. • Scoping.
Universally unique identifiers • It is useful to be able to identify services uniquely, particularly in large networks where many instances of the same service type may be present. • Assigning universally unique identifiers (UUIDs) to services has several benefits: • It allows clients to search for a specific service by its identifier. • It allows clients and service catalogs to determine if two service instances are in fact the same service
At first, it might seem difficult to generate universally unique identifiers without global infrastructure • but in fact, most computers with network interfaces already contain at least one unique identifier • An IEEE 802.3 Media Access Control (MAC) address. • MAC addresses are 6 byte quantities with 3 bytes allocated to a vendor ID and 3 bytes to a vendor-specific serial number. • For example, MAC addresses beginning with bytes 0x0000A0 are allocated to Sanyo, Inc.
MAC addresses alone are insufficient for universally unique service IDs for a number of reasons. • The first is that some services may be hosted on devices with no assigned MAC address. • A second reason is that MAC addresses can be configured in software, potentially resulting in duplicates. • Another reason is that a device with a single MAC address may host many services, each of which requires a universally unique ID. • Finally, it is not generally desirable to tie a service to a particular machine.
JINI • An additional mechanism to allow UUIDs to be created without reference to an MAC address, and is adequate for a broad class of applications. • UUIDs in Jini are 128 bits long • Are created using a combination of random numbers, a measure of the current time, and possibly a MAC address. • The most significant 64 bits of the identifier are composed of a • 32-bit time_low field, • 16-bit time_mid field, • a 4-bit version number, and • a 12-bit time_hi field.
The least significant 64 bits of the identifier are composed of a • 4-bit variant field, • a 12-bit clock_seq field, • a 48-bit node field. • The variant is always 2. • The version field can contain either 1 or 4. • If the version field contains 1, then the node field is set to a 48-bit MAC address, the clock_seq field is set to a random number, and the three time fields are set to a 60-bit measure of elapsed time (in 100-ns increments) from midnight, October 15, 1582. • If the version field is 4, then the other fields (except for the variant) are set to a random number.
Standardization • An essential component in service discovery frameworks is a standardization process for new service types. • For clients to discover needed services (in an abstract sense, printers, scanners, high-performance compute services), it must be possible for the client to specify service types in a standard way. • This is more than a simple naming problem—beyond the initial discovery of services of a specific type, a client must know how to interact with the service—how to make the service.
What does it mean to be a service of type X? • What operations are appropriate for services of type X? • What protocols does an instance of type X use? • What descriptive attributes are required to adequately describe the • characteristics and capabilities of a service?
Textual descriptions • Most of the proposed service discovery frameworks use textual descriptions for standardizing services. • The Service Location Protocol (SLP),Universal Plug and Play (UPnP), Salutation, and the Bluetooth Service Discovery Protocol (SDP), among the current commercial protocol suites, all use programming language–independent textual descriptions to describe services. • Ninja, which is primarily a research prototype emphasizing advanced security features for service discovery, does as well.
<?xml version="1.0"?><root xmlns="urn:schemas-upnp-org:device-1-0"><specVersion><major>1</major><minor>0</minor></specVersion><URLBase>http://10.0.0.13:5431</URLBase><device><deviceType>urn:schemas-upnp-org:device:blender:1</deviceType><friendlyName>UPnP Blender</friendlyName>
There are two problems in constructing a textual service description. • The name of the service type must be standardized so that clients have a mechanism for specifying needed services. • In addition, the names of standard attributes must be defined so that capabilities and characteristics of service instances can be determined either during the initial discovery attempt or during a post discovery service interrogation. • The second issue is choosing the particular protocol used between a client and a service instance. Some service discovery frameworks, such as SLP, use an attribute to specify an external protocol that is used for client/service communication; SLP is not concerned with the definition of this protocol.
Using interfaces for standardization • Another approach to standardizing a new service type is to define an interface (generally in the object-oriented sense of the word) that service instances implement. • The exemplar of this approach is Jini. • which uses Java interfaces as the mechanism for standardizing services. • The interface defines precisely the methods that will be used in interacting with the device.
