Extending Zeroconf Technology to Enable Web Services Auto-discovery in a Local Network Environment

1. Extending Zeroconf Technology to Enable Web Services Auto-discovery in a Local Network Environment Advisors: XiaoPing Jia, Luigi Guadagno Author: Ying Gan

2. Problem: How to manage network service discovery, delivery and invocation in a cost effective way • In a local network, Network Service includes printing service, file sharing service, security service, etc. Almost every functionality in a local network can be wrapped in a service that can be shared by all network devices in the same network.

3. Service Provider Interacts with Service Consumer at Runtime

4. Solution part 1: Standardization • Standardization allows the use of standard tools and knowledge; So that the cost can be reduced, efficiency increased. • Service can be standardized as Web Services. • Network protocol can be standardized as IP. • Application protocol can be standardized as HTTP or SOAP.

5. Service Discovery is still the weakest link • Hard code the service address in the application configuration file. • Network Admin needs to change configuration file during the initial setup • Network Admin needs to modify client’s configuration file when service is moved.

6. Cost Efficiency Problems • Imagine a network with 100 services and 500 devices (PCs or PDAs, etc) • Network Admin needs to maintain 50,000 configurations.If it takes you 1 minute to exam one configuration, you need more than one month to exam all of them only once. Given that you have the knowledge to work with a lot of different devices, platform, OS. • Labor-intensive, tedious, and error-prone. • Hard to check and debug:A service provider can also be a consumer to other services.

7. Solution part 2: Auto Configuration of Service Addresses and Decentralized Service Discovery • Apple Computer’s AppleTalk • Microsoft’s NetBIOS • Novell’s IPX • IP-based Zeroconf • IP-based UPnP (universal plug and play)

8. Zero Configuration IP Networking • Zeroconf Working Group of IETF (The Internet Engineering Taskforce) since 1999 • Goals: • Allocate addresses without a DHCP server. • Translate between names and IP addresses without a DNS server. • Find services, like printers, without a directory server. • Allocate IP Multicast addresses without a MADCAP server.

9. A Zeroconf World

10. My Research Goals • By using Zero Configuration IP Networking (Zeroconf) technology, I am searching a way to help users locate the best network services to fit their needs in an efficient way. • By extending Zeroconf technology ,adding rich service description information and allowing run-time service query and quote, I am trying to achieve advanced features such as runtime negotiation and run-time service selection.

11. Design: Partial Knowledge Framework(PKF) for Web Service Delivery and Invocation • Service Consumer only have partial knowledge of the service. • Service call is done via a universal service interface: Object[] call(Object[] params) • Consumer does not know how the service is doing with those parameters. It just pass in an array, and expect an object array back. • Service provider may choose to ignore some parameters it can not understand. • Service Quote and Price negotiation on the fly.

12. Design:PKF continues • Zeroconf’s role: • Service Discovery will use zeroconf to be automatic. • Zeroconf also serves as a distributed directory service. First of all, we can check zeroconf’s service type. Within the same type of services, the “Service Info” of each service will contain the service category and subcategory information. • Service addition and removal is automatically reported to all clients who are interested in the same type of service.

13. PKF - design, implementation and run time

14. Design:PKF Design Time • At design and implementation time, the Universal Service Interface is known to everyone. For a specific type of service, there is also a strong-typed Application Service Interface. Whether the service can process certain parameter is in the capability description. • On the service consumer side, since the Universal Service Interface is known to everyone, it only requires the Application Service Interface of a certain service type. At run time, the consumer will ask each service provider for its service info description, and from that it can find the capability supported by the service. • The Application Service Interface code for each service type/category/subcategory should be made public to everyone. This is used to generate application service proxy or adapter

15. Design:PKF Run Time • On the service provider side, if a web services is published, it will publish itself as a zeroconf service at the same time. • On the service consumer side, when there is a request to do certain type of service, • it will search for all services of the zeroconf service type. • Start the service negotiation: it will query each service for service info. • In service info, it will find category, address, etc. • Choose the best fit to the requirements. And then make the call. • If the call is successful, record that in the activity log. If not, record this also, and try the next available service; If none is available, just wait till some service is online. • The Universal Service Interface structure allows extensible service interface by defining new parameters. This allows maximum compatibility between the client program and all existing different versions of service implementations in the network.

16. PKF Design and Implementation • Choice of Technology • JmDNS for zeroconf network • xMethods GLUE for web services

17. PKF Layered Architecture

18. Universal Service Layer Introduction • “Black Box” approach. Keep the details of transmission layer within PKF only, not to the application programmers • Publishing and discovery of service descriptor based on zeroconf network • Publishing, hosting, and invocations of web services based on GLUE • Standard and extensible service descriptor form in xml • Edu.depaul.se690.pkf.usi.* package

19. Universal Service Layer Service

20. Universal Service Layer Client

21. Application Base LayerIntroduction • Application Base works between USI and an actual application service/client • Serve as base for all application services. Defines basic behavior of a kind of application service and client. Reduce complexity in application programming.

22. Application Base LayerIntroduction - continued • Added two more methods: Quote and Query. Defines the basics interface of a query-able, quote-able application service • Extend USIService Descriptor to BaseServiceDescriptor • Introduces BaseServiceProxy as the proxy to a service and hides the details of interaction with USI. • Edu.depaul.se690.pkf.base.* package

23. Application Base LayerService

24. Application Base LayerClient

25. PKF Layered ArchitectureService call translation and dispatch between layers

26. PKF Layered ArchitectureService call response and translation between layers

27. PKF Class Diagram

28. Application LayerHelloWorld Server • The minimal application to showcase PKF • public Object[] sayHello() • { • return toArray("hello, world, from:["+this.descriptor.name+"]"); • }

29. Application LayerHelloWorld Client • Call BaseServiceClient.findAllProxies(String xpath) to get all helloworld service proxies • Then call the service proxy’s method call(Object[] input) • The result is an array of Objects • No knowledge of web services or mDNS needed • Partial knowledge of Helloworld server is needed. Its category is “helloworld”

30. Printing application service and clients • Based on BaseService and BaseServiceClient • Runtime query and quote • Multiple service comparison at runtime • Query service capability, instead of knowing all about service interface at design time.

31. Printing application service and clients • Why are runtime queries necessary? • The formula for Price Quote may be much complicated than a number. So it can not be put directly in the service descriptor and broadcast to every client. • Things such as “next available job processing time” can not be decided at design time. It requires runtime information.

32. Printing application service and clients My First Printing Service Demo • New additional info in Service Descriptor for Printing (class PrintingServiceDescriptor) • SupportBW (boolean) • MaxGrayLevel (int) • SupportColor (boolean) • MaxColorDepth (int)

33. Printing application service and clientsMy First Printing Client Demo • Client side: new class PrintingServiceProxyVisitor helps to work with BaseServiceProxy • Client-Side Strategies • Find the first printing service • Find the most affordable service • First find all printing services • Send Price Quote to every service found • Choose among all services with valid price quotes

34. Printing application service and clients My First Printing Client Demo • At Runtime, clients can automatically detect services as they are turned on or off. • When a printing call is needed, client try to find available services at that time following a certain strategy. Then make the call. • Command Line-based interface, for simplicity

35. Printing application service and clients My First Printing Client Demo Start printing service #1 at port 60000

36. Printing application service and clients My First Printing Client Demo Start printing service #2 at port 60001

37. Printing application service and clients My First Printing Client Demo Start printing client, compare results from quote, and choose the cheaper service at $16.19

38. Printing application service and clients My First Printing Client Demo Start printing service #3 at port 60002

39. Printing application service and clients My First Printing Client Demo Printing client automatically discovers the new service, compares all 3 services and choose the most affordable one @ $16.19

40. Summary: PKF Advantages • Combines the flexibility of Web Services and the service auto-discovery feature of Zeroconf network into one set of API. • API can dramatically reduce the development time of self-discovery web services. • Uses service descriptors for static service information, uses Query and Quote for runtime dynamic service negotiations.

41. Summary: PKF Advantages - 2 • Service information is xml based, not all decided at design time. This allows clients work with services with only partial knowledge. • Client can work with services that are built in the future, in the past, or by different programmers, on different platforms. As long as it is based on zeroconf, with the compatible xml format of service descriptor. • PKF does not limit the types of services. It can be used with any types of services

42. Summary: PKF Limitations • Service Discovery limited in local network only – Zeroconf limitation • API can be improved. For now, PKF API is for concept demo purpose only • The samples are based on Java 100%. Need to explore the possibility for other platforms such as Microsoft .NET

43. References • Zeroconf---http://www.zeroconf.org/ • zeroconf requirement (internet draft) ---http://www.ietf.org/internet-drafts/draft-ietf-zeroconf-reqts-12.txt • zeroconf host requirement (internet draft) ---http://files.zeroconf.org/draft-ietf-zeroconf-host-prof-01.txt • Cost-Optimization of the IPv4 Zeroconf Protocol -- Henrik Bohnenkamp IEEE Computer Society http://csdl.computer.org/comp/proceedings/dsn/2003/1952/00/ 19520531abs.htm • IP Address Configuration Algorithms for Routerless and Single-Router Zeroconf Networks ---IEEE Computer Society http://info.computer.org/proceedings/iscc/1671/16710037abs.htm • An IP Address Configuration Algorithm for Multi-Router Zeroconf Networks ---IEEE Computer Society http://info.computer.org/proceedings/iscc/1671/16710462abs.htm - 10.7KB

44. References • MultiCast DNS--- http://www.multicastdns.org/ • Apple Rendezvous and Zeroconf---http://www.zeroconf.org/Rendezvous/ • JmDNS--http://jmdns.sourceforge.net/ • Official Apple Developer Support Rendezvous FAQ---http://developer.apple.com/macosx/rendezvous/faq.html • Rendezvous with Web Services--- • http://webservices.xml.com/lpt/a/ws/2003/06/24/rendezvous.html • Jrendezvous--http://javangelist.snipsnap.org/space/jRendezvous

45. References • Book • Web Services: Buliding Blocks for Distributed Systems • by Grahan Glass • jRendezvous: Java and Rendezvous Working Together • by Seth Ladd

46. Need more Information? Please visit my research web page: http://students.depaul.edu/~ygan1/SE690/SE690.html