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.
A network made up of interconnected 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
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.
Web Services as
Standardized 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
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
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
you 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
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.
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
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.
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]);
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 4color.
• 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