Distributed processing

Options

• Sockets - low-level
• RPC - extend procedural abstraction. Call a procedure, get a small set of data types back
• CORBA, etc - object based RPC, plus: call an object method, get a primitive data type or reference to an object
• Java RMI - extends O/O to RPC: call an object method, get a primitive data type or an object

Jini and RPC

• Reduce dependence on addresses of objects by discovery
• Recognise network is part of the call, not just hide it
• Requires widespread knowledge of interfaces
• Reflection can be used, but isn't easy and is hardly done

Web services

• Need address, and then call a procedure at that address.
• Get back an XML document, neither an object nor a primitive data type - can't make further method calls on the document
• No recogntion of network issues

Success stories

• What are the largest successful distributed systems?
  • Web
  • email
• Why are they successful?
• How can they form the basis of other distributed systems?

Success factors of the Web

• Everything (object) has an address - a URI
• When you access an object, you get back a representation of that object e.g. an HTML page
• The representation may contain addresses of other objects
• So: everything is an address and you get addresses to handle further objects
• Late binding: an object only needs to exist when it is being accessed
• Addresses can be referenced even if they don't exist yet or are not presently available
• So: you don't the object to exist when authoring documents or at any time except when you access it
• HTTP has only a small number of operations: GET, POST, PUT, HEAD, ...
• It is simple to talk to any object using these "verbs": GET address, etc
• You don't need different "verbs" (methods) to talk to different types of addresses
• So: a small collection of verbs, universally understood

REST

• Representational State Transfer
• Term invented by Roy Fielding in his PhD
• Wiki at http://internet.conveyor.com/RESTwiki/moin.cgi/

REST omponents

REST describes a networked system in terms of

• data elements (resource, resource identifier, representation)
• connectors (client, server, cache, resolver, tunnel)
• components (origin server, gateway, proxy, user agent)

Aspects of REST

• Data elements are accessed through a standardized interface
• Components communicate by transferring representations of resources through this interface rather than operating directly upon the resource itself
• Connectors present an abstract interface for component communication, hiding the implementation details of communication mechanisms.
• Components use connectors to access, provide access or mediate access to resources
• All requests made to connectors must contain all the information necessary for the understanding of that request without depending on any previous request, i.e. they are stateless

REST critique of web services

• To call a method on a web service, you have to send an XML document to an address
• There isn't just an object at that address that returns a representation
• Instead there is an object that can delve inside the XML document and do something based on what it finds
• The GET/POST semantics is lost (GET = no change, POST = possible change)
• The endpoint must know the HTTP protocol and in addition must also know another protocol (interface)
• Knowing one simple, standard procotol is scalable (demonstrated by the Web). Needing to know per-application protocols (interfaces) is not
• The result of a web service call is another XML document. This doesn't represent the object at the endpoint, but something unknown that happened at the endpoint
• The returned document doesn't have a URI - you can't pass a reference to it to other people

REST web service

• Make an HTTP request as you would to any URL
• Get (usually) an XML document in return
• The document could contain primitive values
• It will not contain other objects - instead it will give URLs for them
• To find the content of another object you have to make another HTTP request

REST example

Query a database

• Get a list of customers

  
        GET http://host/CUSTOMERS
        

• Return:

  
  <resources xmlns:xlink="http://www.w3.org/1999/xlink">
      <resource xlink:href="http://host/CUSTOMER/0/">0</resource>
      <resource xlink:href="http://host/CUSTOMER/1/">1</resource>
      <resource xlink:href="http://host/CUSTOMER/2/">2</resource>
      <resource xlink:href="http://host/CUSTOMER/3/">3</resource>
  </resources>
        

• Query a customer

  
        GET http://host/CUSTOMER/1/
        

• Return:

  
  <resources xmlns:xlink="http://www.w3.org/1999/xlink">
      <ID>11</ID>
      <FIRSTNAME>Julia</FIRSTNAME>
      <LASTNAME>White</LASTNAME>
      <STREET>412 Upland Pl.</STREET>
      <CITY>Chicago</CITY>
  </resources>
        

• Clearly, you still need to understand the XML document you get in response, but you don't have to know the service structure in order to get it

Jini etc compared to REST?

State

• REST services don't have state - a request should contain all state info needed. Cookies, etc are regarded as a non-scalable hack
• Jini, CORBA services (objects) have state, but not on a per-session basis
• Web services may or may not have state - depending on the programmer

Consistent model

• All REST services are either primitive values or addresses (no stateful objects)
• All CORBA/Jini services are either primitive values or objects CORBA has object references that can be handed out to others. Jini has object proxies that can be moved around (but only between JVMs)
• WS may have primitive values, addresses, objects and XML data structures - whatever the programmer feels like

Binding

• REST and WS have late binding. A service only needs to exist when it is called. It does not need to exist when its address is created
• Jini and CORBA objects have to exist when their address is created, and must also exist as the "same" object when called. Activation may be used to "pause" an object

Protocols

• REST has one protocol for accessing things, HTTP over TCP
• WS, Jini and CORBA have one protocol for access (HTTP, JRMP or IIOP) and a per-object protocol for service methods