• 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 are commonplace now, with the Web and email common examples
• Distributed systems normally consist of computing nodes linked by middleware

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

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

• Jini
• Web services
• Peer to peer: JXTA

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

• 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

• 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

• 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.

• 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.

Service representation:

• string describing the service
  • keyword
  • directory
  • XML
• an object interface for the service

• The matching may be exact, or
• may allow some degree of pattern matching - bottleneck if performed at directory

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

• 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 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

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

• 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 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.

• 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

• 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.

• 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

The current state of this RPC mechanism is

• 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.

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.

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.

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.

• 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 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.

• 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

• 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

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

• 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

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)

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

• 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.

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

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

• 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: http://jan.newmarch.name/services/presentation2.html
• Related paper: http://jan.newmarch.name/services/paper.html