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

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.

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.

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.

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

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.

Design: 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 Quote and Price negotiation on the fly.

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.

PKF - design, implementation and run time

Design: PKF Design Time• At design and implementation time, the Universal Service Interface is kn

own to everyone. For a specific type of service, there is also a strong-typ

ed Application Service Interface. Whether the service can process certai

n parameter is in the capability description.

• On the service consumer side, since the Universal Service Interface is k

nown to everyone, it only requires the Application Service Interface of a

certain service type. At run time, the consumer will ask each service pro

vider for its service info description, and from that it can find the capabilit

y supported by the service.

• The Application Service Interface code for each service type/category/su

bcategory should be made public to everyone. This is used to generate

application service proxy or adapter

Design: 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, 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.

PKF Design and Implementation• Choice of Technology

– JmDNS for zeroconf network– xMethods GLUE for web services

PKF Layered Architecture

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

Universal Service Layer Service

Universal Service Layer Client

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.

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

Application Base LayerService

Application Base LayerClient


Service call translation and dispatch between layers


Service call response and translation between layers

PKF Class Diagram

Application LayerHelloWorld Server

• The minimal application to showcase PKF

• public Object[] sayHello()• {• return toArray("hello, world, from:["+this.descriptor.name+"]");

• }

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”

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.


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


My First Printing Service Demo• New additional info in Service Descriptor for

Printing (class PrintingServiceDescriptor)• SupportBW (boolean)• MaxGrayLevel (int)• SupportColor (boolean)• MaxColorDepth (int)


My 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


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


My First Printing Client DemoStart printing service #1 at port 60000




My First Printing Client DemoStart printing client, compare results from quote, and choose the cheaper service at $16.19




My First Printing Client DemoPrinting client automatically discovers the new service, compares all 3 services and choose the most affordable one @ $16.19

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.

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

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

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/

• 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

References• Book

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

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

Need more Information?Please visit my research web page:

http://students.depaul.edu/~ygan1/SE690/SE690.html

Documents

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