• Run a method of a Java class that lives somewhere on a network using remote method invocation (RMI)
• Find an object that provides a remote service using JNDI.
• Run a method of a remote component that may be written in some language other than Java using CORBA.
• Dynamically add the services of a device to an application running on a network using JINI.
• Mention remote procedure calls using Simple Object Access Protocol (SOAP)

• Remote Method Invocation
• Object Serialization
• Java Naming and Directory Interface (JNDI)
• CORBA and SOAP
• Restful Web Services
• JINI

• Imagine that you could send a message to an object that lived somewhere on the network as if it was on your local machine.
• With Java RMI you can!

• RMI makes heavy use of interfaces
• You talk to the remote object through its interface

1. Remote interface must be public.
2. Must extend java.rmi.Remote.
3. Must declare java.rmi.RemoteException in its throws clause (plus any other application-specific exceptions).
4. Any object passed as an argument must be serializable.
5. A remote object, passed as an argument or return value must be declared as the remote interface, not the implementation class.

1|Example 1: a remote time service (at-m42/Examples/lecture11/TimeHereI.java)

extern> http://www.cpjobling.org.uk/~eechris/at-m42/Examples/lecture11/TimeHereI.java

1|Example 2: the remote object (at-m42/Examples/lecture11/TimeHere.java)

extern> http://www.cpjobling.org.uk/~eechris/at-m42/Examples/lecture11/TimeHere.java

• Create and install a security manager that supports RMI. Sun provides RMISecurityManager.
• Create one or more instances of the remote objects.
• Register at least one of the remote objects with the RMI object registry (for bootstrapping).
  • One remote object can have methods that produce handles to other remote objects.
  • Client only needs to go to registry once to get the first remote object.

• An RMI registry server process (default port 1099) must be running on the server before remote objects can be registered:
• Windows

start rmiregistry 2005

1|Example 3: register the remote method via Groovy (at-m42/Examples/lecture11/startTimeHere.groovy)

extern> http://www.cpjobling.org.uk/~eechris/at-m42/Examples/lecture11/startTimeHere.groovy

• Unix

rmiregistry  2005 &

• Once the registry is running, you may bind your remote object to it by calling static method Naming.bind(String address, Object remote_object)

• localhost may not be a valid name for the server host. If testing locally you need the system’s host name (dell-laptop in the example).
• RMI must have an active TCP/IP connection. On a dial-up service you must allow the network to connect!

• Some additional factoids
• Once main exits the object is still left around and alive by the registry.
• To destroy an object use Naming.unbind() or shut down rmiregistry.
• Awkward when testing!
• You can start a registry from a program (useful for testing) using

LocateRegistry.createRegistry(2005);

• We now need to create the networking infrastructure

• Created for you by rmic (RMI compiler)¹⁾

rmic uk.ac.swan.egm42.rmi.TimeHere

• Creates TimeHere_Stub.class.
• Stub is placed in classpath of client

l|Example 4: RMI client in Groovy (at-m42/Examples/lecture11/displayTimeHere.groovy)

extern> http://www.cpjobling.org.uk/~eechris/at-m42/Examples/lecture11/displayTimeHere.groovy

• Need a policy file entry (.java.policy located in your “home” directory) to give access to RMI tool.
• I've always had problems with this so I use:

grant {
  permission java.security.AllPermission;
};

• Use policytool (installed with JDK) to set this up.

Not this setting effectively turns Java's security system. It should never be used on a production server!

• Run the server process:

<cli prompt='>'> e:\dev\at-m42-2009\Examples\lecture11>groovy startTimeHere.groovy Ready to tell time </cli>

• Run the client from another command window:

<cli prompt='>'> e:\dev\at-m42-2009\Examples\lecture11>groovy displayTimeHere.groovy Time on remote server: Thu Apr 16 19:44:33 BST 2009 Time on remote server: Thu Apr 16 19:44:33 BST 2009 Time on remote server: Thu Apr 16 19:44:33 BST 2009 Time on remote server: Thu Apr 16 19:44:33 BST 2009 Time on remote server: Thu Apr 16 19:44:33 BST 2009 Time on remote server: Thu Apr 16 19:44:33 BST 2009 Time on remote server: Thu Apr 16 19:44:33 BST 2009 Time on remote server: Thu Apr 16 19:44:33 BST 2009 Time on remote server: Thu Apr 16 19:44:33 BST 2009 Time on remote server: Thu Apr 16 19:44:33 BST 2009 </cli>

• Remote Method Invocation
• Object Serialization
• Java Naming and Directory Interface (JNDI)
• CORBA and SOAP
• Restful Web Services
• JINI

• Sometimes you need to pass objects (i.e. method parameters) to and return objects (i.e. return values) from a remote object.
• You cannot use pass-by-reference when objects are distributed, instead you have to use pass-by-value.
• Objects are serialized at one end, passed across the network and reconstructed at the other (called marshalling).
• All Java/groovy objects can be serialized (work done by Object class) but this ability is turned off by default.
• You just have to implement Serializable and hey-presto it’s done!

• Recall that in Groovy, method parameters are passed by value
  • a copy of the reference (handle) is passed
  • actual object is in the heap in the JVM
• In RMI, you cannot pass a reference to a remote object, since the object only exists in the local heap.
• Following scenarios illustrate RMI in action
  • Adapted from Sierra and Bates, Head First EJB, O’Reilly, 2003.

• Suppose you want to return a reference to another remote object. How would this be achieved?

• After the process … your two heaps have to look like this

• Remote Method Invocation
• Object Serialization
• Java Naming and Directory Interface (JNDI)
• CORBA and SOAP
• Restful Web Services
• JINI

• Naming service – associates a name with a component:
  • E.g. a file system associates a file name with a physical location of data on a hard drive
• Directory service – allows you to associate attributes as well as a name to a component
  • E.g. Address book associates person with a name and allows attributes such as the person’s phone number, title, address with that name.

• JNDI = Java Naming and Directory Interface
• Java Enterprise API for working with networked naming and directory services.
• Allows Java programs to use name servers and directory servers to look up objects or data by name and search for objects or data according to a set of specified attribute values.
• Implemented in the javax.naming package and its sub-packages as a standard extension to the Java 2 platform.

• Not specific to any particular name or directory server protocol.
• Provides a generic API that will work with any name or directory server.
• To support a particular protocol:
  • Plug in a service provider for that protocol into a JNDI installation.
  • Service providers for common protocols: NIS, LDAP, and Novell’s NDS available.
  • Service providers also available for RMI and CORBA object registries.

• Remote Method Invocation
• Object Serialization
• Java Naming and Directory Interface (JNDI)
• CORBA and SOAP
• Restful Web Services
• JINI

• Need to interface with legacy data stores?
• Need to call methods of a language other than Java?
• Need services from a server object regardless of its physical location?
• Then you need some form of remote procedure call (RPC):
  • Common Object Request Broker Architecture (CORBA) is an integration specification defined by the Object Management Group.
  • Simple Object Access Protocol (SOAP) uses XML and networking technology to achieve much the same ends.
• Both promise distributed, language independent object interoperability.

• Common Object Request Broker Architecture (CORBA) is not a language feature; it’s an integration technology.
• It's a specification that vendors can follow to implement CORBA-compliant integration products.
• CORBA is part of the OMG's effort to define a standard framework for distributed, language-independent object interoperability.
• CORBA supplies the ability to make remote procedure calls into Java objects and non-Java objects, and to interface with legacy systems in a location-transparent way.
• Java complements CORBA rather than competing with it.

• One of the main CORBA features is RPC support, which allows your local objects to call methods in remote objects.
• RMI makes RPC possible between Java objects.
• CORBA makes RPC possible between objects implemented in any language.
• RMI can be used to call services on remote, non-Java code.
  • you need is some kind of wrapper Java object around the non-Java code on the server side.
  • the wrapper object connects externally to Java clients via RMI, and internally connects to the non-Java code using Java Native Interface (JNI).
• This approach requires you to write a kind of integration layer, which is exactly what CORBA does for you, but the advantage is that you don’t need a third party ORB.

• RMI over Internet Inter-Orb Protocol
• A variation of RMI that uses the standard Object Request Broker (ORB) to provide RMI services.

• Simple Object Access Protocol (SOAP) is a lightweight protocol for the exchange of information in a decentralized, distributed environment.
• It is an XML based protocol that consists of three parts:
  • an envelope that defines a framework for describing what is in a message and how to process it,
  • a set of encoding rules for expressing instances of application-defined data-types,
  • a convention for representing remote procedure calls and responses.
• SOAP can potentially be used in combination with a variety of other protocols; however, the only bindings defined in [the specification] describe how to use SOAP in combination with HTTP and HTTP Extension Framework.
• Big part of Microsoft’s .NET strategy. Java Support for SOAP from IBM. Support from Sun in J2EE 1.4. Possibly easier to use than CORBA.

Source: Technical Note: SOAP 1.1, 8/5/2000. http://www.w3.org/TR/SOAP.

A problem with SOAP is that it uses HTTP as a transport protocol, primarily to avoid firewall problems (HTTP messages are normally allowed through corporate firewalls).

• Remote Method Invocation
• Object Serialization
• Java Naming and Directory Interface (JNDI)
• CORBA and SOAP
• Restful Web Services
• JINI

“Representational state transfer (REST) is a style of software architecture for distributed hypermedia systems such as the World Wide Web. The terms 'representational state transfer' and 'REST' were introduced in 2000 in Roy Fielding's doctoral thesis²⁾.” Wikipedia article

In summary, the five key principles³⁾

• Give every “thing” an ID
• Link things together
• Use standard methods
• Resources with multiple representations
• Communicate statelessly

Notes: Fielding was one of the principal authors of the Hypertext Transfer Protocol (HTTP) specification. REST is a set of principles that define how Web standards, such as HTTP and URIs, are supposed to be used. If you adhere to REST principles you will end up with a system that exploits the Web's architecture to your benefit.

On the web any individual object can have a URL:

http://game.com/players/1234
http://game.com/actions/2009/04/17/26
http://game.com/items/4554
http://game.com/processes/move/east

But so can collections:

http://example.com/actions/2007/11
http://example.com/items?weight=10 

This makes it easy for both web browsers and other programs to be able to find objects that need to be manipulated in a distributed system.

Some made up XML:

<inventory carrier='http://game.com/players/1234' > 
   <weight>120</weight> 
   <potency>12</potency>
   <item ref='http://games.com/items/4554' /> 
   <item ref='http://games.com/items/4556' /> 
</order> 

Represents the inventory of a player in our game (could of course be HTML is a web application, but I wanted to emphasize machine-to-machine communication). Note that we are using familiar concept to link to define relationships. Thus to find out more, e.g. about one of the items being carried, the application can navigate to that resource via its URL.

• Traditional Service-Oriented Architecture: must use API as defined.
• Might be implemented in RMI, CORBA, SOAP

You can see that there are two services defined here (without implying any particular implementation technology). The interface to these services is specific to the task – it's a GameManagement and PlayerManagement service we are talking about. If a client wants to consume these services, it needs to be coded against this particular interface – there is no way to use a client that was built before these interfaces were specified to meaningfully interact with them. The interfaces define the services' application protocol.

• Must use verbs from the HTTP application protocol.

You can see that what have been specific operations of a service have been mapped to the standard HTTP methods – and to disambiguate, we have created a whole set of new resources.

Essentially, this makes your application part of the Web – its contribution to what has turned the Web into the most successful application of the Internet is proportional to the number of resources it adds to it. In a RESTful approach, an application might add a few million game item URIs to the Web; if it’s designed the same way applications have been designed in CORBA times, its contribution usually is a single “endpoint” – comparable to a very small door that provides entry to a universe of resource only for those who have the key.

The uniform interface also enables every component that understands the HTTP application protocol to interact with your application.

To summarize: For clients to be able to interact with your resources, they should implement the default application protocol (HTTP) correctly, i.e. make use of the standard methods GET, PUT, POST, DELETE.

• An HTTP client is expected to be able to handle multiple resources types and to make use of content negotiation to request a particular format:

GET /players/1234 HTTP/1.1
Host: game.com 
Accept: text/html

GET /players/1234 HTTP/1.1
Host: game.com 
Accept: application/atom+xml

There is a significant benefit of having multiple representations of a resource in practice: If you provide both an HTML and an XML representation of your resources, they are consumable not only by your application, but also by every standard Web browser — in other words, information in your application becomes available to everyone who knows how to use the Web.

• HTTP is a stateless protocol: every request is a new request.
• Therefore state must be stored in the client or in the resources.

• World-wide web is built on a RESTful architecture, so you could argue that it's already proved its worth.
• Becoming more popular for distributed computing: key feature of application frameworks like Rails and Grails.
• Needs a rethink: away from traditional OO design based around a few nouns and a rich vocabulary of verbs to few verbs and many nouns.

• Remote Method Invocation
• Object Serialization
• Java Naming and Directory Interface (JNDI)
• CORBA and SOAP
• Restful Web Services
• JINI

• Jini is a set of APIs and network protocols that can help you build and deploy distributed systems that are organized as federations of services.
• A service can be anything that sits on the network and is ready to perform a useful function. Hardware devices, software, communications channels–even human users themselves–can be services.
  • A Jini-enabled disk drive could offer a “storage” service.
  • A Jini-enabled printer could offer a “printing” service.
• A federation of services is a set of services, currently available on the network, that a client (meaning a program, service, or user) can bring together to help it accomplish some goal.

• In Jini there is no central controlling authority.
• Because no one service is in charge, the set of all services available on the network form a federation—a group composed of equal peers.
• Jini's run-time infrastructure merely provides a way for clients and services to find each other via a lookup service.
• After services locate each other, they are on their own. The client and its enlisted services perform their task independently of the Jini run-time infrastructure.
• If the Jini lookup service crashes, any distributed systems brought together via the lookup service before it crashed can continue their work.
• Jini includes a network protocol that clients can use to find services in the absence of a lookup service.

• To perform a task, a client enlists the help of services, e.g.:
  • client program might upload pictures from the image storage service in a digital camera
  • download the pictures to a persistent storage service offered by a disk drive
  • send a page of thumbnail-sized versions of the images to the printing service of a colour printer.
• The client program builds a distributed system consisting of itself, the image storage service, the persistent storage service, and the colour-printing service.
• The client and services of this distributed system work together to perform the task: to offload and store images from a digital camera and print a page of thumbnails. 

• Distributed computing is when you have some part of the application on one machine and some part(s) on another machine perhaps separated geographically.
• If both parts of the application are written in Java you can use RMI or RMI/IIOP.
• To find the services available on a server you can use JNDI
• If some part of the application uses legacy code or is not written in Java then use CORBA
• SOAP is a recent attempt to simplify distributed computing by use of XML and standard internet technologies like HTTP.
• RESTful services recognizes that HTTP itself can provide many of the benefits of CORBA or SOAP at much lest cost.
• JINI is a networking technology that allows small applications or networked devices to communicate with other and dynamically configure themselves to create distributed applications.

Apart from some special cases, current trend (as we'll see) is away from distributed computing using RMI, CORBA and SOAP towards a Web-Based architecture constructed from user-facing HTML clients consuming RESTful services over HTTP and with machine-to-machine communications exploiting XML resource exchange over HTTP. JINI is a niche technology that was in the doldrums for a long time. JNDI, RMI, and SOAP are still important in Enterprise Application Development, but over time, I would expect them to become relegated to very specialized “back office” applications.

Home | Previous Lecture | Lectures | Next Lecture