CALIFORNIA SOFTWARE LABS

Transcription

1 UPnP,Jini and Salutation - A look at some popular coordination frameworks for future networked CALIFORNIA SOFTWARE LABS R E A L I Z E Y O U R I D E A S California Software Labs 6800 Koll Center Parkway, Suite 100 Pleasanton CA 94566, USA. Phone (925) Fax (925) info@cswl.com

2 UPnP,Jini and Salutation - A look at some popular coordination frameworks for future networked Technical Expertise Level : Intermediate Shelf Life : 6 months A Technical Report INDEX INTRODUCTION... 3 JINI... 4 JINI LOOKUP SERVICES... 5 EXPOSING INTERFACES... 5 JINI COORDINATION IN A NUTSHELL... 6 UNIVERSAL PLUG AND PLAY... 7 SERVICE DISCOVERY... 8 CONFIGURATION... 9 UPNP COORDINATION IN A NUTSHELL SALUTATION SERVICE DISCOVERY COMMUNICATION SALUTATION COORDINATION IN A NUTSHELL CONCLUSION CSWL Inc, Pleasanton, California - 2

3 INTRODUCTION With the world of specialized information appliances poised to take over the technology landscape in the coming years, coordination between devices has become a serious research issue. A number of architectures addressing mobile and specialized devices have emerged recently. These architectures are essentially coordination frameworks that propose certain ways and means of device interaction with the ultimate aim of simple, seamless and scaleable device inter-operability. Among the well known contenders, Universal Plug and Play ( Jini ( and Salutation ( architectures are prominent, coming primarily from the industry. There is also a great amount of active research happening "silently" in the academic world. Whichever gets to become standard(s), it will be useful to understand what these frameworks are all about. Device coordination essentially means providing a subset of the following capabilities to a device: Ability to announce its presence to the network. Automatic discovery of devices in the neighborhood and even those located remotely. Ability to describe its capabilities as well as query/understand the capabilities of other Self configuration without administrative intervention Seamless inter-operability with other devices wherever meaningful It is not easy for coordination frameworks to have much of a say on data communication protocols between This is because devices can be very specialized, following umpteen different data protocols. It will be tough for a CSWL Inc, Pleasanton, California - 3

4 framework to adapt them all into a standard. However, a coordination framework can make devices become aware of one another in sufficient detail. The intelligence within a device can decide whether it can or should talk to another device and also what protocol(s) to use. The framework can also provide protocol definitions in an attempt of standardization. It should be borne in mind that for any coordination framework to work, it MUST introduce some standards into the operations of the Otherwise the devices simply cannot coordinate. The essential problem here is maintaining a balance between standardization requirements and device autonomy. By device autonomy we mean the use of proprietary protocols and techniques and the need (marketbased or otherwise) to continue using them. As can be seen later in this article, Jini takes standardization to one extreme while UPnP takes autonomy to another extreme. Jini Jini from Sun Microsystems, underneath all the hype, is but a coordination framework evolved and adapted from academic research and tailored specifically to Java. The original inspiration comes from the works of David Gelernter (Yale University) and Nick Carriero who built the Linda coordination model using Tuple Spaces, about a decade ago. An inspired result was the JavaSpaces technology with its later evolution into Jini. Jini uses the term federation to imply coordination between A federation is a collection of autonomous devices which can become aware of one another and cooperate if need be. To facilitate this, a Jini subsystem constains a set of lookup services that maintain dynamic information about available These services are key to the proper functioning of the Jini subsystem. CSWL Inc, Pleasanton, California - 4

5 Jini Lookup Services Jini Lookup services must be running on a network for the concept to really work. Using well-defined protocols, devices can discover these key services and enter into a dialogue with them. Every device must discover one or more such lookup services before it can enter a federation. The location of these services could be known before hand, or they may be discovered using a multicast. (Note: multicast is a feature that allows controlled broadcast to a group of devices within a selected range. This range can potentially be the whole Internet or just the local LAN). It is possible to assign group names to lookup services so that a device may look for a specific group in its vacinity. For e.g. in a company, administrative decisions may force certain hardcopy devices to belong to some special group, with restricted access. Once a device has located a lookup service of interest it can now tell the service about itself (register), or query the service for information on other devices in the federation. When registering itself, it can associate a set of properties (name/value pairs) with this information which can be matched against queries from other Exposing Interfaces Now here comes an interesting part of Jini. During the registration process it is possible for a device to upload some Java code to the lookup service. This code is essentially a "proxy" that can be used to contact an interface on the device and invoke methods of that interface. So a querying device can automatically download this proxy and call methods inside our device. This is accomplished using Remote Method Invocation (RMI) in Java that allows a Java program to call a method in a remotely running Java program through some exposed interface. The main issue here is that both the devices must have Java embedded for this to work. However, it is possible to avoid the use of RMI and use the Jini lookup services simply to extract information about a device in question. A proprietary protocol can then be CSWL Inc, Pleasanton, California - 5

6 used to contact the device. In this case the lookup service is reduced to a directory service. The Jini lookup services can form an ensemble, passing on queries up a hierarchy for resolution. These services also try to make sure that they have an accurate snapshot of the current set of active This is done by providing registration leases with expiry. Devices should renew their leases periodically for the lookup services to maintain their registration information. Any information on devices which simply vanish without explicit de-registration will automatically be purged from the databases after the lease time expires. Jini Coordination in a Nutshell Announcing Presence: Unicast/Multicast to Jini lookup services and subsequent registration. Lease expiry also helps provide a more or less up-to-date status of the devices available. Discovering other devices: Querying lookup services with properties of devices of interest. Optionally download an RMI proxy to access the remote device Describing capabilities: Registration information can have attribute/value pairs that are amenable to querying. Device manufacturers can also come to agreement on the network interface methods to be supported via RMI so that after recognizing a device, the methods to invoke will be known. This needs some standardization. There are two phases here. Standardization of the registration information and then of the exposed RMI interfaces. Self configuration: Jini does not directly address this area. An IP device when plugged onto a network will have to be configured with an IP address, subnet mask and optionally a gateway and DNS server. From then on, the lookup services can be used. But the use of the Java platform means that it cannot directly interfere with the native operating system and its configuration. The AutoIP and Multicast DNS protocols used by UPnP can actually fit snugly into this void!! CSWL Inc, Pleasanton, California - 6

7 Invoking services: Java's no-need-for-drivers scenario is not as simple as it sounds. The methods in RMI interfaces to devices have to be well defined (a standard) for this to work. If all manufacturers of a certain device type agreed on a standard, then one piece of code that follows that standard would work for all (the proxy code in Java). Thus the driver will hopefully be reduced to one or more pieces of universal code in Java. This is essentially a trading of proprietary drivers for universal standards - not very easy to arrive at. There can be many reasons a device manufacturer would not like to switch to Java, performance being but one side issue. Even a java "bridge" to a proprietary protocol may not be acceptable. Security: Native to Java & RMI. Jini does not seem to define anything more. Transports: TCP/IP and proxies to other transports There are ways by which non-java devices can participate in a federation. This is essentially through the use of gateways/bridges/proxies (all meaning the same here) that do protocol translations. However, these are not attractive solutions, and would also introduce single point of failures on the network. More information on Jini can be found from online documents at Sun Microsystems ( Universal Plug and Play UPnP, pushed primarily by Microsoft, is a framework defined at a much lower level than Jini. Though it is considered at some levels to be a natural extension of Microsoft Plug and Play to the networking scenario, its implementation framework is so different from Microsoft Plug and Play, that the so-called "extension" becomes nothing other than an imagined concept. UPnP is a different beast altogether. If you do not have a "run-anywhere" solution like Java, then you must look towards leveraging code that is implemented almost anywhere. What better choice exists than the TCP/IP protocol suite? UPnP works primarily with these lower layer CSWL Inc, Pleasanton, California - 7

8 network protocols suite, implementing standards at this level instead of at the application level. This primarily involves additions to the suite, certain optional protocols which can be implemented natively by The keyword here is "natively". UPnP attempts to make sure that all device manufacturers can quickly adhere to the proposed standard without major hassles. It also makes sure that it will be able to ride the next generation Internet Protocol (IPv6) wave when it hits. By providing a set of defined network protocols, UPnP allows devices to build their own APIs that implement these protocols - in whatever language or platform they choose. As of this writing, the particulars of these protocols are still in a flux. Prototypes do exist. Draft versions are available on the Internet, primarily through pointers at and Microsoft. But we will take a look at the key ingredients that form the recipe of UPnP. Service Discovery UPnP uses a special protocol known as SSDP (Simple Service Discovery Protocol) that enables devices to announce their presence to the network as well as discover available This can work with or without a lookup (directory) service in between. If there is such a directory service (called a proxy) available on the network, then devices will use it, otherwise they will follow a proxy-less operation. This discovery protocol (SSDP) will use HTTP over both unicast and multicast UDP. This may sound surprising, since we are familiar with HTTP as a TCP protocol. However, the same data format can be followed in UDP as well, even in multicast. These protocols can be referred to as HTTPU (unicast UDP) and HTTPMU (Multicast UDP) respectively. The registration/query process will send and receive data in HTTP format, but having special semantics. An announcement message called ANNOUNCE and a query message called OPTIONS are embedded in HTML to facilitate this. CSWL Inc, Pleasanton, California - 8

9 A device joining the network can then send out a multicast ANNOUNCE - telling the world about itself. A directory service, if present can record it, or other devices may directly see this as well. The multicast is sent out on a reserved multicast channel (address) to which all devices must listen. The ANNOUNCE message must also contain a URI that identifies the resource (e.g. "dmtf:printer") and a URL to an XML file that provides a description of the announcing device. The latter essentially uses a style sheet tailored to various types of A query for device discovery can also be multicast (an OPTIONS message) - to which devices may respond directly, or it may be directed towards a directory service if present. Queries however do not seem to be very powerful. They do not seem to be targeted at the XML descriptions, but must use URIs like "/ietf/ipp/printer". The XML description is looked at only after discovery takes place. Configuration UPnP also addresses the problem of automatic assignment of IP addresses and DNS names to a device being plugged in. For these, a few more protocols are introduced. One way to assign an IP address is to look for a DHCP server on the network. If not present, then the device can choose an IP from a reserved IP address range known as the LINKLOCAL net (address range x.x?). It must use the ARP protocol to find an unused address in this range locally and assign to itself. This is known as AutoIP. Note that this is not a routable IP address and therefore packets will not cross gateways. If a DHCP server comes up anytime, the devices will attempt to switch their IP address (Easier said than done). To address issues in naming, a multicast DNS proposal has been drafted. This would allow plugged-in devices to a) discover DNS servers via multicast and also b) resolve DNS queries about itself via multicast. So when plugged into a network having no DNS servers locally, a device can send out a multicast packet and CSWL Inc, Pleasanton, California - 9

10 discover a remote DNS server and then use it for Internet name resolution (like resolving URLs). The device itself can optionally listen on the multicast channel and respond to queries for its own name! However no security issues seem to have been addressed by UPnP yet. Once the discovery process is through and the XML description of a device is received, proprietary protocols can take over in communicating with the UPnP Coordination in a NutShell Announcing presence: Use SSDP and Directory service proxies (optional) Discovering other devices: Listen to SSDP multicast channel directly or contact a directory service proxy. Describing capabilities: XML description of the device is made available at a specified URL. However, these are not amenable to queries during the discovery process. Simple URIs are used instead. Self configuration: This is primarily DHCP or AutoIP, and multicast DNS. Auto configuration seems to be the strongest feature of UPnP as yet. Invoking Services: UPnP does not address this area. Even though style sheets can describe device capabilities, it would still be difficult to talk to ANY device of the same class. E.g. sending a page to an HP printer or a Fujitsu printer would still need drivers even though both would fit in the same class (unless both support a protocol like the HP JetSend protocol or some other standard). By concentrating on base level discovery and device capability querying only, UPnP leaves a void in this area for future additions. Security: In progress. Transports: TCP/IP and proxies to other transports As in Jini, devices using other transport protocols may use UPnP through the use of proxies. Essentially, proxies sitting on the TCP/IP network can perform registration and discovery on behalf of such CSWL Inc, Pleasanton, California - 10

11 Salutation The Salutation coordination framework seems to be a more rigorous and useful framework from a coordination perspective than either Jini or UPnP. It seems to have drawn more from research on intelligent agents than other frameworks mentioned here. Salutation trods a middle way between device autonomy and standardization. This would allow many vendors to adapt many of their products more or less easily to the specification and inter-operate with one another. Service Discovery In Salutation, a device almost always talks directly to a Salutation Manager, which may be in the same device or located remotely. What we see is an ensemble of Salutation Managers (SLMs) that coordinate with one another. They act like agents that do everything on behalf of their clients. Even data transfer between devices, including those across different media and transports, is mediated through them. The framework provides call-backs into the devices to notify of events like data arriving or devices becoming unavailable. All registration is done with the local or nearest available SLM. SLMs discover other nearby SLMs and exchange registration information, even with those on different transport media. The latter is done using appropriate transport-dependent modules called Transport Managers which may use broadcast internally. Broadcast RPC is optionally used for this. The concept of a 'service' is broken down into a collection of Functional Units, each unit representing some essential feature (e.g., Fax, Print, Scan or even subfeatures like Rasterize). A service description is then a collection of functional unit CSWL Inc, Pleasanton, California - 11

12 descriptions, each having a collection of attribute records (name, value). These records can be queried and matched against during the service discovery process. Certain well defined comparison functions can be associated with a query that searches for a service. The discovery request is sent to the local SLM which in turn will be directed to other SLMs. SLMs talk to one another using Sun's ONC RPC (Remote Procedure Call). Salutation defines APIs for clients to invoke these operations and gather the results. Communication One of the key features that Salutation tries to provide is transport protocol independence. The communication between clients and functional units (services) can be in a number of ways. In the native mode these may use native protocols and talk to one another directly without the SLMs getting involved in data transfer. In the emulated mode, the SLMs will manage the session and act as a conduit for the data, delivering them as messages to either party. This provides something very important - transport protocol independence. In the salutation mode, SLMs not only carry the data, but also define the data formats to be used in the transmission. In this mode well-defined standards of interoperation with functional units are to be followed, allowing generic inter-operability. All communication in the latter two modes involve APIs and events which are well defined. Data descriptions follow a popular notation/encoding called ASN.1 (Abstract Syntax Notation One) from OSI. Instead of lease management, SLMs can be asked to periodically check the availability of functional units and report the status. This allows a client or functional unit (service) to become aware when either have left the scene. Salutation has already defined a number of Functional Units for various purposes like faxing and voice mail. These also allow the use of vendor specific features. The consortium seems to have taken great pains in defining acceptable (?) and general functional unit specifications. CSWL Inc, Pleasanton, California - 12

13 Salutation Coordination in a Nutshell Announcing Presence: Through cooperation between Salutation Managers (SLMs). Simply register with a known, probably local SLM. Discovering other devices: Send queries to the local SLM. SLMs coordinate and returns results Describing capabilities: Structured descriptions of services as functional units which in turn contain attribute records. Functional units identify "type" or "features" of a service. Attributes provide much more detail. All amenable to powerful queries. Standard functional unit definitions allow easier interoperability. Self configuration: Salutation does not address this issue. Being a transport independent framework, it would not be easy to provide a generic solution to this. In the area of IP networks, AutoIP and multicast DNS as used by UPnP is a possible candidate. Invoking Services: Flexible. Provides for vendor specific protocols, SLM managed sessions providing transport independence, as well as defined (standard) data and protocols for selected functional units. The defined APIs can be implemented on most platforms. Security: Salutation allows user authentication using a user-id and password scheme. It can also optionally provide any registered information about a caller to the callee. Transports: Transport independent architecture The need for proxying hardly exists in Salutation. SLMs are transport independent, this work being handled by Transport Managers that plug into the architecture. CSWL Inc, Pleasanton, California - 13

14 Conclusion This article attempts to take a close look at some popular emerging coordination frameworks of today. It tries to present some essential information to the reader for assessment. Though we feel that none among these is a real winner compared to the others in terms of features and functionality, the reader may have specific reasons in favoring one over the other. To us, it seems that the features of UPnP related to self-configuration are key ingredients that should be allowed into other frameworks as well. But it should also be mentioned that these features of UPnP are indeed addressed (if not fully) in the next generation Internet protocol (IPv6) and hence should be available to the other frameworks in the future. Again to us, as they stand today, Salutation seems to be a better defined and more viable architecture than the other contenders. But none of them are yet ready for popular consumption since the evolution to stabilization based on industry feedback will take time. And architectural ingenuity is not the sole recipe for success in the market. That said, we can expect many more changes and additions to these and other architectures in the near future, as they race towards creating a niche in the technology landscape Copyright Notice: 2002 California Software Labs. All rights Reserved. The contents on the document are not to be reproduced or duplicated in any form or kind, either in part or full, without the written permission of California Software labs. Product and company names mentioned here in are the trademarks of their respective companies. CSWL Inc, Pleasanton, California - 14