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

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

Advisors: XiaoPing Jia, Luigi GuadagnoAuthor: Ying Gan

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.

A network made up of inter-connected network services and consumers

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.

Service Provider Interacts with Service Consumer at Runtime

Solution part 1: Standardization• Standardization allows the use of stand

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

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

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.

Cost Efficiency Problems

• Imagine a network with 100 services and 500

devices (PCs or PDAs, etc)

• Network Admin needs to maintain 50,000 con

figurations. If it takes you 1 minute to exam one configuration, yo

u 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 als

o be a consumer to other services.

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)

Zero Configuration IP Networking• Zeroconf Working Group of IETF (The Int

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

A Zeroconf World

A Zeroconf World

Zeroconf• Pros

– IP-based open standard– Does not restrict Application Service Type (

Unlike UPnP)– Based on Multicast DNS, easy to learn if yo

u know DNS.– Simple and easy to implement

Zeroconf• Cons

– Not very popular yet

– Cost some network bandwidth

– Can not go beyond local network yet.

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.

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.

Plan: Partial Knowledge Framework(PKF) for Web Service Delivery and Invocation• Service Consumer only have partial kno

wledge of the service. • Service call is done via a universal service inter

face: Object[] call(Object[] params)• Consumer does not know how the service is do

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

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.

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.

PKF - design, implementation and run time

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.

Plan: PKF Run Time• On the service provider side, if a web services is published, it will publis

h itself as a zeroconf service at the same time.

• On the service consumer side, when there is a request to do certain typ

e of service, – it will search for all services of the zeroconf service type. – Start the service negotiation: it will query each service for service in

fo. – 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 t

his 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 inter

face by defining new parameters. This allows maximum compatibility be

tween the client program and all existing different versions of service im

plementations in the network.

Plan: The flexibility of partial knowledge• I am still in the middle of laying out the details, the principle is like the fo

llowing 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]);

– }

Class Diagram

Sequence Diagram

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);

– }

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)

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.

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.

Possible Further Development• Use PKF service to simplify P2P

programming.

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

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

References• Book

– Web Services: Buliding Blocks for Distributed Systems • by Grahan Glass

– jRendezvous: Java and Rendezvous Working Together• by Seth Ladd

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

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