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. A network made up of inter-connected network services and consumers

4. Network Service • A network service is made up of: service address, service interface, and service provider implementation. • Service address is the entry point of the service. • Service interface is the description of the functionality provided by the service. • Service provider is the deployed service. Usually a server program.

5. Service Provider Interacts with Service Consumer at Runtime

6. 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.

7. Web Services asStandardized Services • Service Address: Web Service URL. • Service Interface Description: WSDL • Service Provider: Web Services Provider. Usually a Web Server Farm. • Service Consumer: Web Services Client. Can be any device that can understand HTTP and XML

8. 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 the configuration file when service is moved.

9. 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.

10. 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)

11. 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.

12. A Zeroconf World

13. A Zeroconf World

14. Zeroconf • Pros • IP-based open standard • Does not restrict Application Service Type (Unlike UPnP) • Based on Multicast DNS, easy to learn if you know DNS. • Simple and easy to implement

15. Zeroconf • Cons • Not very popular yet • Cost some network bandwidth • Can not go beyond local network yet.

16. 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 and adding rich service description information, I am also trying to achieve advanced features such as: the dynamic negotiation of Service Level Agreement (SLA), run-time selection of services with partial design-time knowledge.

17. We need a total solution • A complete solution for web service automatic discovery, distribution, and invocation. • Service consumer does not need to know where the provider is deployed. • Service consumer does not need to always keep track of changes in service interface. • Distributed Directory service to allow searching and comparing SLA(service level agreement) and price, etc.

18. Plan: 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 Level Agreement negotiation on the fly. • Service Quote and Price negotiation on the fly.

19. Plan: 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.

20. Plan: PKF continues • Service Description Information: • Zeroconf already have the “service type” concept. • The Service Info will be an xml file that contains: • The service basic info (name, version, owner, timestamp) • Service category and subcategory. • Service address (WSDL URL) • SLA “service level agreement” information. Used in the service automatic selection. This also includes a description of the capability of the service.

21. PKF - design, implementation and run time

22. Plan: 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 Functional Service Interface. Whether the service can process certain parameter is in the capability description that is part of the SLA info in service info. • On the service consumer side, since the Universal Service Interface is known to everyone, it only requires the Functional 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 Functional Service Interface code for each service type/category/subcategory should be made public to everyone. This is used to generate functional service proxy or adapter.

23. Plan: 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, SLA, 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.

24. Plan: The flexibility of partial knowledge • I am still in the middle of laying out the details, the principle is like the following example, no new compile for client/server is needed • Client code (Functional Proxy): • public Object[ ] printBW(Object content, int DPI){ • Object[] input = new Object[3]; • input[0] = "printBW"; • input[1] = content; • input[2] = 300; • USIProxy p = new USIProxy( ); • return p.call(input); • } • An older server implementation: (USIAdaptor) • public Object[ ] call(Object[ ] input){ • if(input[0].Equals(“printBW”) • new PrintingFSAdaptor( ).printBW(input[1]); • } • An newer server implementation: (USIAdaptor) • public Object[] call(Object[ ] input){ • if(input[0].Equals(“printBW”) • new PrintingFSAdaptor( ).printBW(input[1], input[2]); • }

25. Class Diagram

26. Sequence Diagram

27. PKF: an example printing service • Universal Service Interface: • Object[] call(Object[] params); • Functional Service Interface for printing service • interface PrintingService{ • public void printColor(int ColorDepth, byte[] postscriptBin); • public void printBW(byte[] postscriptBin); • public void printBW(byte[] postscriptBin, int DPI); • }

28. PKF: an example printing service • Service Provider • Publish itself as “printing service” type zeroconf service. Publish itself as a web service • Fills its own service info as: • category: paper-based • SLA: 24x7, 99% up-time. Problems have to be fixed in 5 minutes or penalty is $1per minute. • Price $0.10 per page for 2-color, $0.25 for 4-color. • Capability: DPI=250, Color=4 (black and white)

29. PKF: an example printing service • Service Consumer • Searches for “printing service” type zeroconf service. • Search among the results for category “paperbased” • Among those services that meet the service requirement (24x7, 90% up-time), and capability requirement (300dpi, no color requirement, language=postscript) find the one using some strategy. Make runtime decisions such as whether or not go with a 250DPI result that is 50% cheaper than a 300DPI.

30. Plan: PKF continues • PKF solves one set of problems for service discovery, distribution, and maintenance problem for a local network environment. • Not a silver bullet. • SLA negotiation is just at starting stage. The quality of service and price tag can be very complicated issue.

31. Possible Further Development • Use PKF service to simplify P2P programming.

32. 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

33. References • MultiCast DNS--- http://www.multicastdns.org/ • Apple Rendezvous and Zeroconf---http://www.zeroconf.org/Rendezvous/ • Apple Developer Support Rendezvous---http://developer.apple.com/macosx/rendezvous/ • 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

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

35. Plan and Target Dates • Phase 1: Select topic • Milestone 1: Select the area of research. Completed June 2003. I choose web-services-related area. • Milestone 2: Background research of web services, service-oriented architecture, Zeroconf technology. Completed October 2003 • Milestone 3: Prepare draft of project proposal, collect materials. Completed October 2003 • Phase 2: First presentation • Milestone 1: Prepare first draft of the presentation and meet advisors. Completed November 3rd, 2003 • Milestone 2: Refine presentation. By November 14th, 2003 • Milestone 3: Finalize project proposal. By November 14th, 2003 • Milestone 4: First presentation. On November 14th, 2003

36. Plan and Target Dates • Phase 3: Research and second presentation • Milestone 1: Detailed project planning. By the end of 2003 • Milestone 2: Experiment and choose the right technology and tools. By the end of 2003 • Milestone 3: Finish architectural design. By Jan. 15th, 2004 • Milestone 4: Prepare Final Presentation. By Jan 31st, 2004 • Completion: target date : Feb. 2004 • My website: • http://students.depaul.edu/~ygan1/SE690/SE690.html