Beyond the Web: Recent Internet Services

Jan Newmarch
School of Network Computing, Monash University

The Web

  • The Internet? Isn't that the Web?
  • Recent DETYA questionnaire investigated use of "Web services" [sic] such as email, telnet and ftp.
  • Much confusion and inaccuracies often abound about new technologies

Distributed Systems

  • Distributed systems are commonplace now, with the Web and email common examples
  • Distributed systems normally consist of computing nodes linked by middleware

Old middleware

  • Sockets
  • Sun's RPC/IETF ONC
  • DCE
  • DCOM

New middleware

There are a number of middleware systems that have appeared recently, such as

  • Jini
  • Web services
  • Peer to peer: JXTA
This talk gives a review of some of the technical features of these systems, including implications for network traffic.


This talk looks at a number of the newer protocols, and examines them for issues such as

  • What they claim to be
  • What they are
  • language dependence
  • how network modes are discovered
  • how services are discovered
  • how services are delivered
  • potential network traffic


  • Jini is a Java middleware system
  • It was released in 1999
  • It is an O/O system, relying on O/O type safety in many places
  • It is a "network aware" model, recognising that networks are not as reliable as local systems
  • It can bridge to non-Java systems by surrogate or proxy techniques

Jini structure

Web Services

  • Web services bring automation to the browsing experience
  • Software can search out information, without human falibility
  • Instead of delivering HTML pages with human-oriented markup, Web Services deliver XML which can be processed efficiently by automated systems
  • Web Services are an initiative of IBM, Microsoft and Artima

Web Service Structure


  • Peer to peer systems regained popularity with Napster
  • Napster is a file sharing system - often of illegal MP3 files
  • In Napster, every node can be a source or consumer of MP3 files
  • GNUTella generalises this: every node is a source or consumer of any type of file
  • JXTA is an infrastructure for peer to peer: every node is a source or consumer of arbitrary services

JXTA Service Structure

Lookup versus Discovery

  • Lookup is the mechanism whereby you find a new service by querying a known directory or agent.
  • No search is performed by the seeker, as any searching is performed by the directory as it searches its own databases.
  • Examples: DNS, LDAP, CORBA Naming Service


  • Discovery is the mechanism for more dynamic systems in which there may be much more change. Services or service providers may come and go, and which services are available at any time is volatile.

Network implications

  • A lookup mechanism usually runs from a well-known location, and if it becomes popular enough will become a single point of congestion or failure.
  • Discovery systems may be able to avoid these dependencies on single points of access. Conversely, they have the potential to generate a large amount of traffic between peers.


What's in a directory

Search Semantics

Service representation:

  • string describing the service
    • keyword
    • directory
    • XML
  • an object interface for the service
Service matching:
  • The matching may be exact, or
  • may allow some degree of pattern matching - bottleneck if performed at directory

Service Invocation

  • Once a service is located, it can be invoked
  • mechanism varies according to the system
  • mechanism may be language dependent or independent.

Jini - scope

  • Jini is a Java-specific discovery system.
  • It allows Java clients to discover Java services and call methods on these services.
  • Early publicity: bring h/w hardware into the network as Jini services,
  • Reality: Java Virtual Machines too large
  • Reality: Jini has been successful in building distributed software systems such as
    • travel agent services
    • management of distributed electricity supply systems

Jini directory discovery

  • Jini uses a "directory" called a LookUp Service (LUS).
  • LUS is dynamically populated by services registering with it.
  • There can be many lookup services, either locally or remotely.
  • Jini has both lookup and discovery systems
  • multicast can be made to discover the lookup service.
  • outside of multicast scope, unicast lookup can be used

Jini lookup discovery

Jini service discovery

  • The search for a Jini service is primarily based on object class matching
  • Exact matching used, or wildcard matching - no inequality

Jini service invocation

  • A service is delivered as a Java object to a client requesting the service.
  • Ordinary Java method calls are made on the service.
  • many possible implementations of the service
    • it may run locally
    • it may be an RMI stub (like an RPC stub), making RPC-like calls across the network
    • it may use a private protocol to communicate to any other systems

Jini network implications

  • Jini uses multicast to discover lookup services.
  • It obeys conventions about TTL (time to live) so that multicast packets are usually restricted to the local network.
  • Jini uses leasing as the main mechanism for ensuring that knowledge about Jini services is reasonably up-to-date.
  • The use of leases ensures that the state of the system is only about five minutes out-of-date (at worst).
  • The traffic caused by this is fairly minor.

Jini network implications

  • Communication with a LUS is on port 4160.
  • RMI services will use a random port above 1024
  • It is possible to piggy-back RMI over HTTP port 80

Web Services - scope

  • One of the latest "revolutions" to hit the Web world
  • These are internet services accessible using protocols such as HTTP.
  • They are promised to allow agents to perform the same kind of browsing that humans do but without the need for gaudy user interfaces, and in a much more precise manner using machine-readable XML instead of HTML.

Web services - technologies

  • SOAP - Simple Object Access Protocol
  • WSDL - Web Services Description Language
  • UDDI - Universal Description, Discovery and Integration


  • SOAP is "a lightweight protocol for exchange of information in a decentralized, distributed environment. It is an XML based protocol..."
  • Basically, SOAP/WSDL/UDDI is the latest in RPC technologies.
  • It is the first open standard RPC supported by Microsoft
  • developed by Microsoft, IBM and Artima.


Here is what SOAP isn't:

  • It isn't object oriented - it is procedural
  • It isn't simple - it requires an understanding of XML, including XML namespaces
  • It isn't lightweight - it needs XML generators/parsers on client and server sides, and just sending a one-byte character of payload can use 1000 bytes of message
  • It isn't complete as an RPC system


  • Services are described using Web Services Description Language
  • WSDL is an XML DTD
  • A WSDL is in text format, but is largely unreadable
  • WSDL descriptions are typically reverse-engineered from a Web service implementation

Web services - now

The current state of this RPC mechanism is

RPC requirement SOAP
data types defined by SOAP/XML standard data types
wire format for data defined by SOAP using XML
wire format for messages defined by SOAP over HTTP
an IDL defined by WSDL
generation of client stubs vendor specific
generation of server stubs vendor specific
linking implementation vendor specific

Web services - directory discovery

  • UDDI directories are at well-known locations, such as XServices
  • Clients locate these using unicast to these known addresses.
  • UDDI claims it allows service discovery.
  • In the terms we are using the phrase, it is just lookup, not discovery.
  • Services can publish information to the registry and remove it or modify it.
  • However, there is no leasing mechanism, so that if a service dies then stale entries will not be removed from the registry.

Web service discovery

Each UDDI server contains a registry that can be searched for

  • "white page" (name, address, etc)
  • "green page" (technical information about the service) or
  • "yellow page" (business information) entries.

Web service discovery

Each UDDI server contains a registry that can be searched for

  • The technical information from "green pages" can be a WSDL document.
  • The IBM implementation of a UDDI server allows wildcard searches on things like company name.
  • When a service is found, an XML document which could contain a WSDL document is returned
  • A WSDL document includes information about the location of the service, so once a service has been looked up, it can be contacted.

Web service invocation

The WSDL description of a service is an XML document that includes

  • information about the procedures that can be called on the service, including the parameter types and return types.
  • It is not necessary for the client to be aware of the service description beforehand, as it can get this from the WSDL document.
  • A WSDL description does not describe the semantics of the service, though
  • The client makes a SOAP call which is language independent.

Web service network implications

  • Interaction between a client and a UDDI server is standard client/server using TCP.
  • The client has foreknowledge of the server location so just connects to it.
  • Once a search has been performed on the UDDI server a direct connection can be made to the service on port 80 to make SOAP calls.
  • There are no particular overheads, but the UDDI server may become a bottleneck if heavily used.

JXTA - scope

  • JXTA is a recently publicised P2P system
  • It is intended as a research tool at present
  • It is basically an infrastructure on which services (such as file sharing) can be built,
  • JXTA is intended to be language and network independent.
  • The current implementation (v1.0) is in Java on top of TCP/IP but this is not inherent in the design.

JXTA concepts

  • UUID identifiers for each entity, which may be bound to external information such as a network address
  • Advertisements which are XML documents. These can be used to describe any resource such as nodes or services
  • Peers. These are "nodes" of the JXTA network, and can speak the JXTA peer protocols.
  • Peer groups. These allow grouping of peers in any useful fashion. They are deliberately not clearly specified, and could represent e.g. a collection of services, a geographical group, etc

JXTA concepts

  • Messages. These are datagram style messages, so can be used on unreliable, asynchronous and uni-directional transports such as IP.
  • Pipes. These connect between peers and are used to send messages. They can be one-to-one, many-to-many, etc.
  • Pipes are bound at runtime, allowing the possibility of being rebound if errors occur. Pipes are used as the single communication mechanism

JXTA peer discovery

Peer discovery can be done in a variety of ways:

  • By multicast on (usually) a local network.
  • By unicast connection to a repository of peers. This can be used to bootstrap a peer and inform it of world-wide peers. The current implementation has a hard-coded set of repositories, but this will be fixed
  • By requesting peer lists that are known by another peer
  • By offering a peer list to another peer

JXTA Service discovery

  • The lowest level of searching for services is by the Peer Discovery Protocol. Peers are distinguished by being "ordinary" peers or by being "rendezvous" peers.
  • Ordinary peers keep information about the services they offer.
  • Rendezvous peers cache service adverts so that they act as proxies for service adverts - they act as directories

JXTA Service discovery

Searching involves

  • Ask all the peers one hop away if they have the service
  • Ask the known rendezvous servers if they know of the service
  • The rendezvous servers may ask other rendezvous servers if they know of the service
  • The peer asking for the service must backoff for a certain time before making a repeat search (cf ARP requests)

Service invocation

  • Services are described using WSDL.
  • Services are invoked are invoked using JXTA pipes.
  • The invocation mechanism through a pipe could be e.g. SOAP

Network implications

  • JXTA does currently not prescribe the scope of messages.
  • To avoid message floods, message transmission is limited in the current implementation to the peer groups the peer belongs to
  • In effect, this is bounding multicast scope to the peer group rather than to the local LAN.

Data representation (what is moved)

Sockets byte/char streams
ONC XDR (External data representation)
RMI Java MarshalledObject
Web services SOAP
CORBA CDR (Common data representation)
Jini Java MarshalledObject
JXTA byte streams

Transport (how it is moved)

Sockets TCP/UDP
RMI JRMP (Java remote method protocol)
Web services various, usually HTTP
CORBA IIOP (Internet inter-orb protocol
Jini Jini protocols (discovery, join, etc)
JXTA pipes

Service description

Sockets none
ONC Sun IDL (Interface definition language)
RMI Java interface
Web services WSDL (Web service description language)
Jini Java interface
JXTA Advert of WSDL document

Locating services

Sockets known address
ONC known address
RMI RMI Naming Service
Web services UDDI (Universal Description, Discovery and Integration)
CORBA Naming service/Trader
Jini Jini Lookup Service
JXTA immediate peers or rendezvous peers

Lookup matching

Sockets none
ONC none
RMI exact string match
Web services string searches
CORBA string match or string search
Jini object match
JXTA predicate/pattern match

Language bindings

Sockets Unix C, Java, Perl, Visual Basic, Visual C++, ...
ONC Unix C, Java, Perl, ...
RMI Java only (JDK 1.1 on, not Visual Java)
Web services Java, .NET, Perl
CORBA C, C++, Cobol, Python, ...
Jini Java only (JDK 1.2 on)
JXTA Potentially any, Java at present

Language paradigm

Sockets streams
ONC procedure call
RMI method call
Web services procedure call
CORBA method call
Jini method call
JXTA stream

Remote reference

Sockets socket
ONC opaque data structure
RMI proxy object
Web services URL
CORBA proxy reference
Jini proxy object
JXTA XML document


Some middleware systems support event mechanisms for asynchronous processing, some only support synchronous processing

Sockets synchronous
ONC synchronous
RMI synchronous
Web services synchronous
CORBA synchronous/asynchronous
Jini synchronous/asynchronous
JXTA synchronous

Garbage collection

Some systems will garbage collect objects/services and clean up registries. Others won't.

Sockets no
ONC no
RMI yes
Web services no
Jini yes


  • Jini: distributes objects which can communicate in any way
  • Web services: traditional RPC using heavyweight mechanisms
  • JXTA: experimental infrastructure for peer-to-peer computing
  • Search and discovery protocols have effects on usability of the systems and on network traffic


  • This talk:
  • Related paper:

Jan Newmarch (
Last modified: Wed Nov 21 12:40:06 EST 2001
Copyright ©Jan Newmarch