650 likes | 955 Vues
Service Discovery @ Wayne State, October 2002 -- Prof. Golden G. Richard III. 2. Service Discovery: What?. Protocol suites for building highly dynamic client/server architecturesAutomatic discovery and configuration of new devices plugged into a networkSelf-healing networks: automatic ?demise" o
E N D
1. Service Discovery Golden G. Richard III
Associate Professor
Dept. of Computer Science
University of New Orleans
New Orleans, LA 70148
golden@cs.uno.edu
http://www.cs.uno.edu/~golden
2. Service Discovery @ Wayne State, October 2002 -- Prof. Golden G. Richard III 2 Service Discovery: What? Protocol suites for building highly dynamic client/server architectures
Automatic discovery and configuration of new devices plugged into a network
Self-healing networks: automatic demise of devices removed from a network
Highly dynamic system configurations
Cooperation between resource poor devices
Solves form-factor vs. peripheral richness problem for mobile devices
Printing, FAX, storage, long-range networking services can be obtained from nearby servers
Helps reduce duplication of functionality
eliminates "toolbelt" syndrome
Affects both mobile and wired systems
See Service and Device Discovery: Protocols and Programming (G. G. Richard III, McGraw-Hill, 2002)
3. Service Discovery @ Wayne State, October 2002 -- Prof. Golden G. Richard III 3 Service Discovery: Who? Jini
Sun Microsystems (Java)
www.jini.org
Universal Plug and Play
Microsoft
www.upnp.org
Service Location Protocol
Internet Engineering Task Force (IETF)
www.srvloc.org Salutation
Salutation Consortium
www.salutation.org
Bluetoooth (SDP)
Bluetooth Special Interest Group
www.bluetooth.com
Ninja system at Berkeley
ninja.cs.berkeley.edu
4. Service Discovery @ Wayne State, October 2002 -- Prof. Golden G. Richard III 4 Dynamic Device Discovery
5. Service Discovery @ Wayne State, October 2002 -- Prof. Golden G. Richard III 5 Dynamic System Configuration
6. Service Discovery @ Wayne State, October 2002 -- Prof. Golden G. Richard III 6 Dynamic Client/Server Architectures
7. Service Discovery @ Wayne State, October 2002 -- Prof. Golden G. Richard III 7 Service Discovery: Capabilities Protocol suites provide most or all of the following:
Ability to advertise available services
Automatic discovery of nearby services
Potential to discover services that arent nearby
Ability to "discuss" service capabilities
Abstraction
I just need a printer
Service catalogs (some)
Garbage collection facility (catalogs, service advertisements)
8. Service Discovery @ Wayne State, October 2002 -- Prof. Golden G. Richard III 8 Jini Java-based protocol suite
A federation of clients and services
Entities in federation provide and/or obtain services to/from other entities
All development in Java
Code mobility
Relies heavily on:
Object serialization
RMI: Remote Method Invocation
Interesting services because of mobile code
9. Service Discovery @ Wayne State, October 2002 -- Prof. Golden G. Richard III 9 Jini Entities
10. Service Discovery @ Wayne State, October 2002 -- Prof. Golden G. Richard III 10 Jini, The Big Picture
11. Service Discovery @ Wayne State, October 2002 -- Prof. Golden G. Richard III 11 What is a Jini Service? A client in need of service ultimately downloads a Java object
The object can either:
Provide the service locally (e.g., entirely algorithmically)
Provide the service by invoking operations on a remote server using a private protocol
Proxy object is an RMI stub (object is remote)
(Provide the service by interacting with a remote human being, through a remote server)
To the client, there is no essential difference between these choices
Client generally doesnt know the location of service or wire protocol used to communicate with service
12. Service Discovery @ Wayne State, October 2002 -- Prof. Golden G. Richard III 12 Finding a Lookup Service: Protocols Unicast discovery protocol
TCP: Protocol for communication with a specific lookup service
Scope: Global Internet
Multicast request protocol
UDP: Used to discover nearby lookup services via multicast
Local or administrative scope
Multicast announcement protocol
UDP: Used to announce availability of a lookup service via multicast
Local or administrative scope These protocols are not coded by a Jini applications programmerthey form a foundation for Jinis LookupDiscovery class (discussed on the previous slide).These protocols are not coded by a Jini applications programmerthey form a foundation for Jinis LookupDiscovery class (discussed on the previous slide).
13. Service Discovery @ Wayne State, October 2002 -- Prof. Golden G. Richard III 13 Jini: Unicast Discovery Protocol
14. Service Discovery @ Wayne State, October 2002 -- Prof. Golden G. Richard III 14 Jini: Multicast Request Protocol
15. Service Discovery @ Wayne State, October 2002 -- Prof. Golden G. Richard III 15 Jini: Multicast Request Protocol
16. Service Discovery @ Wayne State, October 2002 -- Prof. Golden G. Richard III 16 Jini: Multicast Request Protocol
17. Service Discovery @ Wayne State, October 2002 -- Prof. Golden G. Richard III 17 Jini: Multicast Request Protocol
18. Service Discovery @ Wayne State, October 2002 -- Prof. Golden G. Richard III 18 Jini: Multicast Announcement Protocol
19. Service Discovery @ Wayne State, October 2002 -- Prof. Golden G. Richard III 19 Service Registration: ServiceItem public ServiceItem(ServiceID id, Object service, Entry [] attributes)
Registration describes an available service:
universally unique id,
object to provide to client, and
set of attributes (which are Entry objects)
On registration, lookup service returns an object that allows leasing to handled, possibly assigned universally unique ID
20. Service Discovery @ Wayne State, October 2002 -- Prof. Golden G. Richard III 20 Search for Services is by Interface Lookup is based on object interfaces, not simply name/value pairs
So client might hold the following interface, which defines a remote file storage service:
public interface StorageService {
public boolean open(String username, String password,)
public boolean close();
public boolean store(byte[] contents, String pathname);
public byte[] retrieve(String pathname);
public boolean delete(String pathname);
public String[] listFiles();
}
Client generally does not know the implementation of the service
Just asks lookup for services matching this interface and having certain attribute values
Once it has an instance, invokes methods in interface
21. Service Discovery @ Wayne State, October 2002 -- Prof. Golden G. Richard III 21 Other Jini Stuff LeaseRenewalManager
JoinManager
ServiceDiscoveryManager
JavaSpaces
Linda-like object spaces
Transactions
Provides a 2PC-based transaction framework
Distributed Events
(Used for notification of lookup and/or appropriate services becoming available)
22. Service Discovery @ Wayne State, October 2002 -- Prof. Golden G. Richard III 22 Jini Security Based on Java 2 security system
Digital signatures
Verify authenticity of downloaded code
Encryption
Security Manager uses access control lists
A variety of actions can be controlled
Security Manager can be subclassed and customized extensively
By default, very tight security
Novice Jini users often cheat and turn off security by using a very liberal (or wide open) policy file
23. Service Discovery @ Wayne State, October 2002 -- Prof. Golden G. Richard III 23 Jini Security (2)
24. Service Discovery @ Wayne State, October 2002 -- Prof. Golden G. Richard III 24 Java Security Manager Terminate application
Read from a specified file
Write to a specified file
Delete files
Accept socket connections
Open a socket connection
Use IP multicast
Use native methods
Load a class from a specified package
Can have different policies depending on where the class files originated
25. Service Discovery @ Wayne State, October 2002 -- Prof. Golden G. Richard III 25 Jini: Thoughts Ubiquitous use will require standardization of Java interfaces
e.g., What interface defines a printer?
Nice, fuzzy feeling about high-level, object-oriented approach
Requires adoption of Java
In general, device must be capable of supporting a Java VM, and all the core Java 2 classes
Raises the computational bar slightly higher than other approaches
Security is very important for mobile-code approaches like Jini
26. Service Discovery @ Wayne State, October 2002 -- Prof. Golden G. Richard III 26 UPnP (Universal Plug and Play) Microsofts offering
UPnP "core"
AutoIP
SSDP (Simple Service Discovery Protocol)
SOAP (Simple Object Access Protocol)
GENA (Generic Event Notification Architecture)
Discussion based on 1.0 specs
No mobile codeinstead, standardized protocols and service descriptions
XML-based service descriptions and device ?? client protocols
Some discussion about a new spec which replaces SOAP with WSDL? (If so, not right away)
A very interesting standardization process ()
27. Service Discovery @ Wayne State, October 2002 -- Prof. Golden G. Richard III 27 UPnP: Device Model
28. Service Discovery @ Wayne State, October 2002 -- Prof. Golden G. Richard III 28 UPnP Device Model Example
29. Service Discovery @ Wayne State, October 2002 -- Prof. Golden G. Richard III 29 UPnP: Six Steps Addressing
For the IP address impaired
Discovery
Discovery and advertisement
Description
What are the characteristics of a service?
Control
Making a service do its thing(s)
Eventing
Updates on interesting service state changes
Presentation
Device GUI SSDP = Simple Service Discovery Protocol
SOAP = Simple Object Access Protocol
GENA = SSDP = Simple Service Discovery Protocol
SOAP = Simple Object Access Protocol
GENA =
30. Service Discovery @ Wayne State, October 2002 -- Prof. Golden G. Richard III 30 Intel SDK for Linux Schematic
31. Service Discovery @ Wayne State, October 2002 -- Prof. Golden G. Richard III 31 Addressing: AutoIP IP address assignment w/o DHCP
Try to find DHCP server on failure
Pick a random address from a range of local addresses (169.*.*.* range)
ARP: Verify address is not in use
If in use, retry until some max attempts exceeded
Configure and use address
Periodically try to find DHCP server by sending discover query
If DHCP offer is received, use it
These addresses are not routable!!
32. Service Discovery @ Wayne State, October 2002 -- Prof. Golden G. Richard III 32 AutoIP
33. Service Discovery @ Wayne State, October 2002 -- Prof. Golden G. Richard III 33 Discovery: SSDP Simple Service Discovery Protocol
Supports both discovery and advertisement
Based on UDP multicast / HTTP
local administrative scope multicast address 239.255.255.250 (see RFC 2365)
Weak search capabilities
service type (multiple responses) or
unique device name (at most one response)
Responses to discovery are URLs that identify device description documents
Description document must be retrieved using standard HTTP to learn more about the device
34. Service Discovery @ Wayne State, October 2002 -- Prof. Golden G. Richard III 34 SSDP in Action
35. Service Discovery @ Wayne State, October 2002 -- Prof. Golden G. Richard III 35 SSDP Service Announcement
36. Service Discovery @ Wayne State, October 2002 -- Prof. Golden G. Richard III 36 UPnP Description Documents XML description document contains:
Essential characteristics of device
Presentation URL
Provides link to HTML GUI for device
Service types offered by device
Control URLs for services
Entry point for device commands
Event subscription URLs for services
Allows subscription to device's event service
Significant device changes will result in notification
Provide our own event sink URL to subscribe
Pointers to Service Control Protocol (SCP) documents for services (these are also XML)
37. Service Discovery @ Wayne State, October 2002 -- Prof. Golden G. Richard III 37
38. Service Discovery @ Wayne State, October 2002 -- Prof. Golden G. Richard III 38
39. Service Discovery @ Wayne State, October 2002 -- Prof. Golden G. Richard III 39
40. Service Discovery @ Wayne State, October 2002 -- Prof. Golden G. Richard III 40
41. Service Discovery @ Wayne State, October 2002 -- Prof. Golden G. Richard III 41 Sample of SCPD Data Types ui1, ui2, ui4: One, two, and four byte unsigned integers.
i1, i2, i4: One, two, and four byte signed integers.
r4, r8: Four and eight byte signed floats.
char: A single character Unicode string.
string: A Unicode string of arbitrary length.
date: A standard ISO 8601 format date (e.g., YYYY-MM-DD).
time: ISO 8601 format without date and without time zone.
boolean: Boolean value (0, 1, false, true, yes, no).
bin.base64: Unlimited length MIME-style Base64 data.
bin.hex: Stream of hexadecimal digits of unlimited length.
uri: Universal Resource Identifier.
--and others
Unlike Jini, no complex types out of the box
42. Service Discovery @ Wayne State, October 2002 -- Prof. Golden G. Richard III 42 UPnP: Control via SOAP
43. Service Discovery @ Wayne State, October 2002 -- Prof. Golden G. Richard III 43 UPnP: Events (GENA) General Event Notification Architecture
Expired IETF Draft (Microsoft authors)
Subscription-based event notification service
Subscribe (service of interest, callback URL)
Resubscribe
Unsubscribe
Reports changes in state variable values for UPnP devices
Event messages contain XML-encoded state variables/values
Unreliable, administratively-scoped UDP multicast and extensions to HTTP
44. Service Discovery @ Wayne State, October 2002 -- Prof. Golden G. Richard III 44 GENA Message Formats (1) Subscription request (NT is notification type)
SUBSCRIBE publisher path HTTP/1.1HOST: publisher host:publisher portCALLBACK: <delivery URL>NT: upnp:eventTIMEOUT: Second-requested subscription duration
Response:
HTTP/1.1 200 OKDATE: when response was generatedSERVER: OS/version UPnP/1.0 product/versionSID: uuid:subscription-UUIDTIMEOUT: Second-actual subscription duration
45. Service Discovery @ Wayne State, October 2002 -- Prof. Golden G. Richard III 45 GENA Message Formats (2) Device sends a notification when important service changes occur:
NOTIFY delivery path HTTP/1.1HOST: delivery host:delivery portCONTENT-TYPE: text/xmlCONTENT-LENGTH: Bytes in bodyNT: upnp:eventNTS: upnp:propchangeSID: uuid:subscription-UUIDSEQ: event key<e:propertyset xmlns:e="urn:schemas-upnp-org:event-1-0"> <e:property> <variableName>new value</variableName> </e:property> Other variable names and values (if any) go here.</e:propertyset>
46. Service Discovery @ Wayne State, October 2002 -- Prof. Golden G. Richard III 46 Concrete GENA Subscription
47. Service Discovery @ Wayne State, October 2002 -- Prof. Golden G. Richard III 47 Concrete GENA Subscription Response
48. Service Discovery @ Wayne State, October 2002 -- Prof. Golden G. Richard III 48 Concrete GENA Event
49. Service Discovery @ Wayne State, October 2002 -- Prof. Golden G. Richard III 49 UPnP: Presentation
50. Service Discovery @ Wayne State, October 2002 -- Prof. Golden G. Richard III 50 UPnP: Thoughts Lighter weight than Jini
Some serious limitations
No directory agents
No security architecture
Limited search capabilities ()
How much community involvement?
Some scary language (to me) in the standardization process
Widespread adoption almost certain
51. Service Discovery @ Wayne State, October 2002 -- Prof. Golden G. Richard III 51 SLP: Service Location Protocol SLP: IETF draft protocol
Defines three types of agents:
User Agents: acquire service handles for apps
Service Agents: advertise service handles
Directory Agents: catalogs of available services, cache service handles
Interesting stuff:
Allow UAs to obtain service handles with or without DAs
Tries to avoid being chatty
More powerful search capabilities than UPnP
Eliminate some device responses during discovery
Scoping to tame administrative hassles
Security considered very important
52. Service Discovery @ Wayne State, October 2002 -- Prof. Golden G. Richard III 52 SLP Schematic (from whitepaper)
53. Service Discovery @ Wayne State, October 2002 -- Prof. Golden G. Richard III 53 Thoughts (or, SLP vs. UPnP) SLP <> UPnP
Major differences
More limited queries in UPnP
SLP: Supports attribute searches (see next slide)
SSDP: Search by type or unique device name only
Protocol used for SSDP
SSDP based on HTTP
Some concerns about how complexity of HTTP headers
No DAs in UPnP (at all)
Client ?? service application protocol outside SLP scope
Security framework, including digital signatures for SLP messages to verify authenticity
New SLP service types will not even be considered for standardization w/o addressing security issues!
!! No scary Microsoft stuff in the standardization process !!
54. Service Discovery @ Wayne State, October 2002 -- Prof. Golden G. Richard III 54 Attribute Searches (Echo) Can use an LDAP-style filter in a service request:
(manufacturer=ibm) will restrict the set of discovered services to those that have an attribute manufacturer with a case-insensitive value of ibm.
(&(manufacturer=ibm)(model=printstar*)) restricts the set of discovered services to those with an attribute manufacturer with a case-insensitive value of ibm and which further have an attribute model with a value beginning with printstar.
(|(contactname=golden)(contactname=gerrod)) matches only services with an attribute contactname whose value is either golden or gerrod (case-insensitive, as above).
Can significantly reduce the number of responses to a discovery request
55. Service Discovery @ Wayne State, October 2002 -- Prof. Golden G. Richard III 55 Ninja Project (UC Berkeley) Java-based service discovery protocol
XML service descriptions and queries
Focus on higher security
All communication encrypted (Authenticated RMI)
All entities have digital certificates
Authentication of endpoints (e.g., clients, services)
Rather than only restrict access to services, restrict knowledge of existence of services
See An Architecture for a Secure Service Discovery Service (Czerwinski, Zhao, Hodes, Joseph, Katz), Mobicom 99, pp. 24-35.
56. Service Discovery @ Wayne State, October 2002 -- Prof. Golden G. Richard III 56 Interoperability Some protocol enhancements are done outside the various special interest groups
e.g., mSLP (Mesh-enhanced SLP)
Interoperability an important research area for the rest of us
Why?
Jini, UPnP, SLP (at the least) are all healthy
Want enabled devices supporting one protocol to be usable by all clients
Cheap devices arent going to support more than one protocol
In current dog eat dog phase, not too much work on interoperability coming out of the SIGs themselves
If youre a systems type, fun!
57. Service Discovery @ Wayne State, October 2002 -- Prof. Golden G. Richard III 57 Jini ?? UPnP Interoperability Interoperability both ways
UPnP clients can use Jini services
Jini clients can use UPnP services
Light (?) coding required for each service type
Must write virtual UPnP and Jini service implementations
Virtual clients provided by framework, perform discovery of services
Virtual Jini service is instantiated when UPnP service of corresponding type is discovered, vice versa
58. Service Discovery @ Wayne State, October 2002 -- Prof. Golden G. Richard III 58 Jini ?? UPnP Interoperability (2) See Jini Meets UPnP: An Architecture for Jini/UPnP Interoperability (J. Allard, V. Chinta, S. Gundala, G. G. Richard III), to appear at SAINT 2003 (Orlando).
59. Service Discovery @ Wayne State, October 2002 -- Prof. Golden G. Richard III 59 Other Interoperability Salutation uses SLP directories beyond the local network segment
There is a Jini ? SLP bridge
Smart agent finds Jini-enabled SLP services and registers them with Jini lookup services
Enabled means the service has a bundle of static Java code
Static code is a factorycan instantiate a live object to speak the appropriate protocol for communicating with the service
Simply: The static code is a Java device driver
Service does not run a JVM
One direction onlydoes not provide access to SLP services for Jini clients
See Automatic Discovery of Thin Servers: SLP, Jini and the SLP-Jini Bridge (E. Guttman, J. Kempf), IECON, San Jose, 1999.
60. Service Discovery @ Wayne State, October 2002 -- Prof. Golden G. Richard III 60 Interoperability (2) Everything over Bluetooth
Can run IP over Bluetooth, thus Jini et al
Either use Bluetooth as data link protocol and forget Bluetooth SDP, or map protocol operations to Bluetooth SDP operations
Salutation over Bluetooth
As above (Salutation over IP over Bluetooth)
Some work on mapping Salutation API directly to Bluetooth SDP
See paper Mapping Salutation Architecture APIs to Bluetooth Service Discovery Layer
http://www.salutation.org/whitepaper/BtoothMapping.PDF
61. Service Discovery @ Wayne State, October 2002 -- Prof. Golden G. Richard III 61 Summary Service discovery great for building highly dynamic systems
Enabler for small information appliances
Lots of contenders for the title
Best technical approach wont necessarily be the winner
So far, very little standardization of service types (for any of the protocol suites)
Good device standards critical
Interoperability important
Security very important
Lots of industrial need ? consulting, contracts
62. ??