Rendezvous with Web Services
June 24, 2003
Overview
Zeroconf is a technology, being developed in the IETF, to enable Zero Configuration IP Networking. This means you could network computers together without the usual headache of complex configuration. Zeroconf also allows computers to find services, such as printers, without a directory server. Apple is branding ZeroConf as Rendezvous, and using this emerging technology as a substitute for the old AppleTalk standard, using it in Mac OS 10.2 Jaguar and in some iApps like Safari. This article will introduce Zeroconf and demonstrate how it can be used with web services.
Functionality similar to ZeroConf has already been provided, in one form or another, by AppleTalk, Novell IPX, and Microsoft Netbios. The main problem is that these proprietary protocols don't work on IP networks and are suited only to local networks. Zeroconf aims at filling this gap, providing a royalty-free, open standard.
Zeroconf defines four areas of functionality:
- Automatic Interface Configuration.
- Automatic Multicast Address Allocation.
- Name-to-Address Translation and vice versa.
- Service Delivery.
With automatic interface configuration, a device (computer, printer, or embedded device) is able to obtain a free IPv4 address without using configuration or DHCP (support for IPv6 is in the works). Both Apple and Microsoft operating systems have support for this functionality. Linux support for Zeroconf specification is under development, in the form of the zcip library. Although automatic interface configuration has been implemented inside various operating systems, there are some limitations and disparities.
For example, the Windows ME function ("Obtain an IP address automatically") uses DHCP first. If it fails, and no previous DHCP lease exists, it uses a variant of the Zeroconf trick. In Windows 2000 and XP, first it tries with DHCP; if that fails, it'll do the Zeroconf configuration. Remember, however, that Windows UPnP (Universal Plug and Play) implementation is based on an old version of the Zeroconf specification. The good news is that the current version is compatible with previous versions. The two technologies should then work at this level.
Introducing iSafe
As a test for Rendezvous name-to-address functionality I put together a simple Java application, using jrendezvous, an open source GPL implementation of Rendezvous protocol. iSafe is a simple Java application that runs on Mac OS X and Windows platforms; it's meant to solve a simple problem: fast backup of data stored in an iBook on a Windows XP machines, without having to configure networking or sharing. You can simply pop-up iSafe on each computer, so that each application discovers the other one, thus enabling a sort of simple file sharing.
|
|
iSafe requires Java2 SDK 1.4 or 1.3.1 with JAXP, and it was tested on Windows XP, Windows 2000 and MacOS 10.2. Download the source code here. You'll also need to download jrendezvous.
The user interface provides a list of available servers on the net, obtained using Rendezvous. Clicking on a server, the list on the right is populated with the files hosted by the node. To add a file to the server, simply choose "Add" from the toolbar and pick the desired file. To refresh the view, use the other button on the toolbar.
The communication between nodes is implemented using SOAP messaging, but the transport layer is not the usual HTTP protocol: to keep the code simple, a simple socket protocol has been used. The files are stored on each node under ~/.iSafe.
Rendezvous-Enabling the Application
With jrendezvous, it is possible to define classes that listen to events related
to Rendezvous services. A class simply implements the ServiceListener
interface, providing three methods:
addService(). Called when a new service joins the net.removeService(). Called when a service quits the net.resolveService(). Called when the subsystem resolves a service name upon therequestServiceInfo()request.
Each method has three parameters: the Rendezvous object, and the type and name
of the service.
As you can see in the following code, these method implementations simply store the
information provided by the jrendezvous library in DefaultListModel; instances
used in the Swing user interface and in java.util.List and
java.util.Map objects. These references will be useful while interacting with
other peer.
public void addService(Rendezvous rendezvous, String type,
String name) {
rendezvous.requestServiceInfo(type, name);
if( !hosts.contains( name ) ) {
hosts.add( name );
hostModel.addElement( name );
panel.revalidate();
}
}
public void resolveService(Rendezvous rendezvous, String type,
String name, ServiceInfo info) {
hostsInfo.put( name, info );
}
public void removeService(Rendezvous rendezvous, String type,
String name) {
hosts.remove( name );
hostModel.removeElement( name );
}
A consideration when you create a Rendezvous enabled client is that a service doesn't
have
a fixed IP address and port. In a DHCP environment, the address can change. The service
names are the intended stable identifiers for service instances. So don't store address
and
port in the application preferences file, but refresh it each time. The
ServiceInfo jrendezvous object contains the service address and port. Take a
look at some code from the sendRequest() method, which is responsible for
sending SOAP messages to the peer on the client.
Document sendRequest( ServiceInfo info, String xml )
throws IOException, SAXException,
IllegalArgumentException, ParserConfigurationException {
String address = info.getAddress();
int port = info.getPort();
Document response = null;
Socket socket = new Socket( address, port );
//...
}
To obtain the list of files hosted on a node, the user must exist on that node in the user interface. iSafe then sends to the socket the following string:
ISAFE_DATA: 175
175 represents the length of the remaining content. After a newline, the following SOAP message is sent,
<?xml version="1.0"?>
<SOAP-ENV:Envelope
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
<SOAP-ENV:Body>
<getStoredData/>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
Creating the service
The name of the service is not the Rendezvous name on MacOS 10.2. That is to say, it is not the name presented in the network panel, but it should be a screen name, a sort of description of the service. For simplicity's sake, iSafe uses the local host's name. (Unfortunately, on OSX this is really the Rendezvous name. As a hack, the program strips the local part of the string, thus generating a correct name for the service.)
public iSafeServer() {
try {
name = InetAddress.getLocalHost().getHostName();
if( name.endsWith(".local.") ) {
name = name.substring(0,
name.indexOf(".local."));
}
System.out.println("iSafeServer.() name="+name);
} catch( UnknownHostException ex ) {
ex.printStackTrace();
}
}
Notice that service name and ports should be registered with IANA. Rendezvous, unlike UPnP, doesn't impose the socket port and protocol, as they are subordinate applications. Take Apache for OSX: it is Rendezvous-enabled, so the sites on a local link are automatically available inside the Safari Rendezvous bookmarks.
The protocol name used by iSafe is "_iSafe", but it is not registered, as this is not a public application but a simple test. The complete type is "_iSafe._tcp.local." denoting the fact that the protocol is based on TCP socket, in contrast to _ucp.local., which denotes a datagram UDP protocol.
Using simple SOAP messages makes debugging easier, but raises some problems:
- Binary attachments (such the files transferred between peers) needs to be encoded. iSafe uses base64 encoding provided by Gokul Singh.
- You need a SOAP server to parse messages, yet various standard implementations, like JAXM and JAX-RPC are too heavy and require HTTP. iSafe opted for simple parsing of SOAP messages that doesn't conform strictly to the SOAP 1.1 specification. In particular, the server doesn't check for presence and compliance of each SOAP tag.
- Arguably, base64 encoding and XML parsing consume unnecessary amounts of processor time and bandwidth.
Managing faults
Things go, inevitably, wrong. In a Rendezvous-enabled application, nodes can pop up and shut down without notice, so the program must be ready to deal with inconsistent situations and a server that suddenly disappears. iSafe doesn't have broad support for error handling, but implements SOAP Faults to represent runtime errors that arise in the form of Java Exceptions.
The client side has in fact specific parsing code to detect such messages and present a message dialog with the exception. Stack trace and faultcodes are not supported.
if( responseXml != null && responseXml.length()>0 ) {
DocumentBuilderFactory factory =
DocumentBuilderFactory.newInstance();
DocumentBuilder builder =
factory.newDocumentBuilder();
response = builder.parse(
new ByteArrayInputStream( responseXml.getBytes() ) );
NodeList list = response.getElementsByTagName("Fault");
if( list.getLength() > 0 ) {
list = response.getElementsByTagName("faultstring");
if( list.getLength() > 0 ) {
Node node = list.item(0);
raiseError( node.getFirstChild().getNodeValue() );
} else {
raiseError( "Malformed response" );
}
}
}
Summary
Rendezvous is an amazing technology that brings simplicity to networking, making it easy to create local networks and with multiple devices, services and data sharing. Jrendezvous, makes this possible with Java. Although new, ZeroConf already has a fair bit of support; for example in Captain FTP, for instant discovery of Rendezvous enabled FTP Servers, or in Hydra, for cooperative editing of source files in an Extreme Programming way.
Rendezvous and web services are natural combination: once services are discovered with Rendezvous, SOAP and XML provides a flexible and standard platform for communication.
Download the iSafe application. You'll also need to download jrendezvous.