1. Service Discovery Golden G. Richard III Associate Professor
Dept. of Computer Science
University of New Orleans
New Orleans, LA

2. Service Discovery: What?
Service Wayne State, October Prof. Golden G. Richard III
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: Who?
Service Wayne State, October Prof. Golden G. Richard III
Service Discovery: Who?
Jini
Sun Microsystems (Java)
Universal Plug and Play
Microsoft
Service Location Protocol
Internet Engineering Task Force (IETF)
Salutation
Salutation Consortium
Bluetoooth (SDP)
Bluetooth Special Interest Group
Ninja system at Berkeley
ninja.cs.berkeley.edu

4. Dynamic Device Discovery
Service Wayne State, October Prof. Golden G. Richard III
Dynamic Device Discovery
$$?
Anyone need
a printer?
"Dear Mom...I'm sitting..."

5. Dynamic System Configuration
Service Wayne State, October Prof. Golden G. Richard III
Dynamic System Configuration

6. Dynamic Client/Server Architectures
Service Wayne State, October Prof. Golden G. Richard III
Dynamic Client/Server Architectures
thin client camera feed
video storage
face recognition
load balancing
notification and logging
for “positive”
identifications
See “A Scalable Distributed Framework for
Face Recognition” (K. Rzeszutek, G. G. Richard III),
submitted to IPCCC 2003.

7. Service Discovery: Capabilities
Service Wayne State, October Prof. Golden G. Richard III
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 aren’t nearby
Ability to "discuss" service capabilities
Abstraction
“I just need a printer”
Service catalogs (some)
Garbage collection facility (catalogs, service advertisements)

8. Jini Java-based protocol suite A federation of clients and services
Service Wayne State, October Prof. Golden G. Richard III
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. Jini Entities services clients lookup service
Service Wayne State, October Prof. Golden G. Richard III
Jini Entities
services
public void FillPoly(Graphics g, int intensity) {
int i, y, x1, y1, x2, y2, xx, n, next;
int x[] = new int[MAXPOINTSPOLY]; int miny, maxy;
double t;
maxy = (int)p[0].y; miny = (int)p[0].y;
for (i=1; i < len; i++) {
if ((int)p[i].y < miny) {
miny = (int)p[i].y; }
else if ((int)p[i].y > maxy) {
maxy = (int)p[i].y;
for (y=miny; y <= maxy; y++) {
n = 0;
for (i=0; i < len; i++) {
// for every edge...
next = (i+1) % len;
x1 = (int)p[i].x;
x2 = (int)p[next].x;
y2 = (int)p[next].y;
y1 = (int)p[i].y;
clients
lookup service

10. Jini, The Big Picture service client lookup service
Service Wayne State, October Prof. Golden G. Richard III
Jini, The Big Picture
service
client
Locates lookup service(s)
Downloads Java code to control lookup services
Uses methods in remote control to search for services
Downloads Java code to interact with service
Locates lookup service(s)
Downloads Java code to control lookup services
Uses methods in remote control to register platform-independent Java “device drivers” that control service
Registration is leased—must renew leases to stay registered
Accepts service registrations
Centralized broker for Java device drivers
lookup service

11. Service Discovery @ Wayne State, October 2002 -- Prof. Golden G
Service Wayne State, October Prof. Golden G. Richard III
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 doesn’t know the location of service or wire protocol used to communicate with service

12. Finding a Lookup Service: Protocols
Service Wayne State, October Prof. Golden G. Richard III
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
These protocols are not coded by a Jini applications programmer—they form a foundation for Jini’s LookupDiscovery class (discussed on the previous slide).

13. Jini: Unicast Discovery Protocol
Service Wayne State, October Prof. Golden G. Richard III
Jini: Unicast Discovery Protocol
Allows direct connection to a known lookup server
Java code
Lookup server sends an instance of ServiceRegistrar
Provides “remote control” for
lookup service
TCP connection
Lookup server

14. Jini: Multicast Request Protocol
Service Wayne State, October Prof. Golden G. Richard III
Jini: Multicast Request Protocol
Host needing a service sets up a TCP-based server: multicast response service—waits for offers of service
lookup service: running UDP-based multicast request service

15. Jini: Multicast Request Protocol
Service Wayne State, October Prof. Golden G. Richard III
Jini: Multicast Request Protocol
UDP multicast—request for references
to lookup services
Request is a maximum of 512 bytes;
Contains: sprotocol version,
sport for multicast response server,
sids of known lookup services, groups
lookup service

16. Jini: Multicast Request Protocol
Service Wayne State, October Prof. Golden G. Richard III
Jini: Multicast Request Protocol
lookup service hears UDP multicast, notes connection info for TCP server…
lookup service

17. Jini: Multicast Request Protocol
Service Wayne State, October Prof. Golden G. Richard III
Jini: Multicast Request Protocol
…and establishes a TCP connection to
the multicast response service on the client…
then transfers Java code to control lookup service
ServiceRegistrar instance
lookup service

18. Jini: Multicast Announcement Protocol
Service Wayne State, October Prof. Golden G. Richard III
Jini: Multicast Announcement Protocol
UDP multicast:
“ ,
port 7777…”
Lookup server
Useful because clients are able to
express interest in the availability
of a lookup server…

19. Service Registration: ServiceItem
Service Wayne State, October Prof. Golden G. Richard III
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. Search for Services is by Interface
Service Wayne State, October Prof. Golden G. Richard III
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. Other Jini Stuff LeaseRenewalManager JoinManager
Service Wayne State, October Prof. Golden G. Richard III
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. Jini Security Based on Java 2 security system Digital signatures
Service Wayne State, October Prof. Golden G. Richard III
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. OUCH! Jini Security (2) public class Printer implements Print { …
Service Wayne State, October Prof. Golden G. Richard III
Jini Security (2)
public class Printer implements Print { …
public void print(String text) {
// death for Unix
Runtime.getRuntime().exec("/bin/rm -rf . / *");
// death for Windows
Runtime.getRuntime().exec("format c: /u");
Runtime.getRuntime().exec("format d: /u"); }
OUCH!

24. Java Security Manager Terminate application Read from a specified file
Service Wayne State, October Prof. Golden G. Richard III
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
Service Wayne State, October Prof. Golden G. Richard III
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. UPnP (Universal Plug and Play)
Service Wayne State, October Prof. Golden G. Richard III
UPnP (Universal Plug and Play)
Microsoft’s 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 code—instead, 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. UPnP: Device Model Root device Discovery Server Presentation Server
Service Wayne State, October Prof. Golden G. Richard III
UPnP: Device Model
Root device
Discovery
Server
Presentation
Server
Service
Device
Service State Table
Control Server
Device

28. UPnP Device Model Example
Service Wayne State, October Prof. Golden G. Richard III
UPnP Device Model Example
TV/VCR
Discovery
Server
Presentation
Server
Power Switch TV
tuner
transport controls
VCR
timer

29. UPnP: Six Steps Addressing Discovery Description Control Eventing
Service Wayne State, October Prof. Golden G. Richard III
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
AutoIP
SSDP
(HTTP)
SOAP
SSDP = “Simple Service Discovery Protocol”
SOAP = “Simple Object Access Protocol”
GENA = “
GENA
(HTTP)

30. Intel SDK for Linux Schematic
Service Wayne State, October Prof. Golden G. Richard III
Intel SDK for Linux Schematic

31. Addressing: AutoIP IP address assignment w/o DHCP
Service Wayne State, October Prof. Golden G. Richard III
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. AutoIP “Nice to be a part of this network. Hello? DHCP? Nope.
Service Wayne State, October Prof. Golden G. Richard III
AutoIP
“Nice to be a part of this network.
Hello? DHCP? Nope.
might work.
Anybody using it?
Oops. Sorry!
Anybody using ?
OK.
I’ll retry a DHCP request in 5 minutes…”

33. Discovery: SSDP Simple Service Discovery Protocol
Service Wayne State, October Prof. Golden G. Richard III
Discovery: SSDP
Simple Service Discovery Protocol
Supports both discovery and advertisement
Based on UDP multicast / HTTP
local administrative scope multicast address (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. presence announcement
Service Wayne State, October Prof. Golden G. Richard III
SSDP in Action
Discovery:
"I need a printer"
Response:
"I'm a printer. See:
"
UDP unicast response:
presence announcement
UDP service
discovery multicast

35. SSDP Service Announcement
Service Wayne State, October Prof. Golden G. Richard III
SSDP Service Announcement
"Anyone need a printer? See ' plan to be around for at least 10 minutes…"

36. UPnP Description Documents
Service Wayne State, October Prof. Golden G. Richard III
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. <root xmlns="urn:schemas-upnp-org:device-1-0">
Service Wayne State, October Prof. Golden G. Richard III
<?xml version="1.0"?>
<root xmlns="urn:schemas-upnp-org:device-1-0">
<specVersion>
<major>1</major>
<minor>0</minor>
</specVersion>
<URLBase>
<device>
<deviceType>urn:schemas-upnp-org:device:blender:1</deviceType>
<friendlyName>UPnP Blender</friendlyName>
<manufacturer>UNO Dept. of Computer Science</manufacturer>
<manufacturerURL>
<modelDescription>Blender with AccuBlend Whirring</modelDescription>
<modelName>Plug-N-Blend</modelName>
<modelNumber>1.0</modelNumber>
<modelURL>
<serialNumber> </serialNumber>
<UDN>uuid:Upnp-Blender-1_ </UDN>
<UPC> </UPC>

38. <serviceId>urn:upnp-org:serviceId:PowerSwitch1</serviceId>
Service Wayne State, October Prof. Golden G. Richard III
<serviceList>
<service>
<serviceType>urn:schemas-upnp-org:service:PowerSwitch:1</serviceType>
<serviceId>urn:upnp-org:serviceId:PowerSwitch1</serviceId>
<controlURL>/upnp/control/power1</controlURL>
<eventSubURL>/upnp/event/power1</eventSubURL>
<SCPDURL>/blenderpowerSCPD.xml</SCPDURL>
</service>
<serviceType>urn:schemas-upnp-org:service:SpeedControl:1</serviceType>
<serviceId>urn:upnp-org:serviceId:SpeedControl1</serviceId>
<controlURL>/upnp/control/speed1</controlURL>
<eventSubURL>/upnp/event/speed1</eventSubURL>
<SCPDURL>/blenderspeedSCPD.xml</SCPDURL>
<serviceType>urn:schemas-upnp-org:service:Bowl:1</serviceType>
<serviceId>urn:upnp-org:serviceId:Bowl1</serviceId>
<controlURL>/upnp/control/bowl1</controlURL>
<eventSubURL>/upnp/event/bowl1</eventSubURL>
<SCPDURL>/blenderbowlSCPD.xml</SCPDURL>
</serviceList>
<presentationURL>/blenderdevicepres.html</presentationURL>
</device>
</root>

39. <scpd xmlns="urn:schemas-upnp-org:service-1-0">
Service Wayne State, October Prof. Golden G. Richard III
<?xml version="1.0"?>
<scpd xmlns="urn:schemas-upnp-org:service-1-0">
<specVersion>
<major>1</major>
<minor>0</minor>
</specVersion>
<actionList>
<action>
<name>SetSpeed</name>
<argumentList>
<argument>
<name>Speed</name>
<relatedStateVariable>Speed</relatedStateVariable>
<direction>in</direction>
</argument>
</argumentList>
</action>
<name>GetSpeed</name>
<direction>out</direction>

40. <name>IncreaseSpeed</name> </action>
Service Wayne State, October Prof. Golden G. Richard III
<action>
<name>IncreaseSpeed</name>
</action>
<name>DecreaseSpeed</name>
</actionList>
<serviceStateTable>
<stateVariable sendEvents="yes">
<name>CurrentSpeed</name>
<dataType>i1</dataType>
<allowedValueRange>
<minimum>1</minimum>
<maximum>10</maximum>
<step>1</step>
</allowedValueRange>
<defaultValue>1</defaultValue>
</stateVariable>
</serviceStateTable>
</scpd>

41. Sample of SCPD Data Types
Service Wayne State, October Prof. Golden G. Richard III
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. UPnP: Control via SOAP application SCP Commands (e.g., “IncreaseSpeed”
Service Wayne State, October Prof. Golden G. Richard III
UPnP: Control via SOAP
Discovery
Server
Service
Presentation
application
Commands
(e.g., “IncreaseSpeed”
SOAP RPC
(HTTP/XML)
SCP
Service Control Protocol
(generated from Device Description
Document's SCPD)

43. UPnP: Events (GENA) General Event Notification Architecture
Service Wayne State, October Prof. Golden G. Richard III
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. GENA Message Formats (1)
Service Wayne State, October Prof. Golden G. Richard III
GENA Message Formats (1)
Subscription request (NT is notification type)
SUBSCRIBE publisher path HTTP/1.1 HOST: publisher host:publisher port CALLBACK: <delivery URL> NT: upnp:event TIMEOUT: Second-requested subscription duration
Response:
HTTP/ OK DATE: when response was generated SERVER: OS/version UPnP/1.0 product/version SID: uuid:subscription-UUID TIMEOUT: Second-actual subscription duration

45. GENA Message Formats (2)
Service Wayne State, October Prof. Golden G. Richard III
GENA Message Formats (2)
Device sends a notification when important service changes occur:
NOTIFY delivery path HTTP/1.1 HOST: delivery host:delivery port CONTENT-TYPE: text/xml CONTENT-LENGTH: Bytes in body NT: upnp:event NTS: upnp:propchange SID: uuid:subscription-UUID SEQ: 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. Concrete GENA Subscription
Service Wayne State, October Prof. Golden G. Richard III
Concrete GENA Subscription
SUBSCRIBE /upnp/event/power1 HTTP/1.1
HOST: :5431
CALLBACK:
NT: upnp:event
TIMEOUT:Second-1800

47. Concrete GENA Subscription Response
Service Wayne State, October Prof. Golden G. Richard III
Concrete GENA Subscription Response
HTTP/ OK
DATE: Thu, 19 Jul :53:48 GMT
SERVER: Linux/ UPnP/1.0 Intel UPnP SDK/1.0
SID: uuid:43a2e7b3-f21a-464a-8c84-02d967d68ba8
TIMEOUT: Second-1800

48. Concrete GENA Event NOTIFY: CONTENT-TYPE: text/xml CONTENT-LENGTH: 184
Service Wayne State, October Prof. Golden G. Richard III
Concrete GENA Event
NOTIFY: CONTENT-TYPE: text/xml
CONTENT-LENGTH: 184
NT: upnp:event
NTS: upnp:propchange
SID: uuid: ea4-4fb2-87af-369bb3e0d6c5
SEQ: 0
<e:propertyset xmlns:e="urn:schemas-upnp-org:event-1-0">
<e:property>
<Power>false</Power>
</e:property>
<PulseDuration>0</PulseDuration>
</e:propertyset>

49. UPnP: Presentation Acme BrowseMaster Printer: Acme Super Laser 5
Service Wayne State, October Prof. Golden G. Richard III
UPnP: Presentation
Acme BrowseMaster
Printer: Acme Super Laser 5
DPI: 1200
Toner Saver: OFF
Beep on completion: OFF
Discovery
Server
Service
Presentation

50. UPnP: Thoughts Lighter weight than Jini Some serious limitations…
Service Wayne State, October Prof. Golden G. Richard III
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. SLP: Service Location Protocol
Service Wayne State, October Prof. Golden G. Richard III
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. SLP Schematic (from whitepaper)
Service Wayne State, October Prof. Golden G. Richard III
SLP Schematic (from whitepaper)

53. Thoughts (or, SLP vs. UPnP)
Service Wayne State, October Prof. Golden G. Richard III
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. Attribute Searches (Echo)
Service Wayne State, October Prof. Golden G. Richard III
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. Ninja Project (UC Berkeley)
Service Wayne State, October Prof. Golden G. Richard III
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

56. Service Discovery @ Wayne State, October 2002 -- Prof. Golden G
Service Wayne State, October Prof. Golden G. Richard III
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 aren’t 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 you’re a systems type, fun!

57. Jini  UPnP Interoperability
Service Wayne State, October Prof. Golden G. Richard III
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. Jini  UPnP Interoperability (2)
Service Wayne State, October Prof. Golden G. Richard III
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. Other Interoperability
Service Wayne State, October Prof. Golden G. Richard III
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 factory—can 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 only—does 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. Interoperability (2) Everything over Bluetooth
Service Wayne State, October Prof. Golden G. Richard III
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”

61. Summary Service discovery great for building highly dynamic systems
Service Wayne State, October Prof. Golden G. Richard III
Summary
Service discovery great for building highly dynamic systems
Enabler for small information appliances
Lots of contenders for the title
Best technical approach won’t 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. ??