Extend Zeroconf Technology

Download Report

Transcript Extend Zeroconf Technology

Extending Zeroconf Technology
to Enable Web Services Autodiscovery 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
• 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
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.
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
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:
be a consumer to other services.
A service provider can also
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
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.
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
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.
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
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
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.
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 Layer
Introduction
– 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 Layer
Introduction - 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 Layer
Service
Application Base Layer
Client
PKF Layered Architecture
Service call translation and dispatch between layers
PKF Layered Architecture
Service call response and translation between layers
PKF Class Diagram
Application Layer
HelloWorld Server
• The minimal application to showcase PKF
• public Object[] sayHello()
• {
•
return toArray("hello, world,
from:["+this.descriptor.name+"]");
• }
Application Layer
HelloWorld 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 Demo
Start printing service #1 at port 60000
Printing application service and clients
My First Printing Client Demo
Start printing service #2 at port 60001
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
Printing application service and clients
My First Printing Client Demo
Start printing service #3 at port 60002
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
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.ht
m
• An IP Address Configuration Algorithm for Multi-Router
Zeroconf Networks ---IEEE Computer Society
http://info.computer.org/proceedings/iscc/1671/16710462abs.ht
m - 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.htm
l
• 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