extending zeroconf technology to enable web services auto-discovery in a local network environment
DESCRIPTION
Extending Zeroconf Technology to Enable Web Services Auto-discovery in a Local Network Environment. Advisors: XiaoPing Jia, Luigi Guadagno Author: Ying Gan. Problem: How to manage network service discovery, delivery and invocation in a cost effective way. - PowerPoint PPT PresentationTRANSCRIPT
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
PKF Layered Architecture
Service call translation and dispatch between layers
PKF Layered Architecture
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.
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.
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)
Printing application service and clients
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
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
Printing application service and clients
My First Printing Client DemoStart printing service #1 at port 60000
Printing application service and clients
My First Printing Client DemoStart printing service #2 at port 60001
Printing application service and clients
My First Printing Client DemoStart printing client, compare results from quote, and choose the cheaper service at $16.19
Printing application service and clients
My First Printing Client DemoStart printing service #3 at port 60002
Printing application service and clients
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