~~SLIDESHOW~~
Distributed Computing
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)
Distributed Computing APIs
RMI (Remote Method Invocation)
Remote Interfaces
Remote interface must be public.
Must extend java.rmi.Remote
.
Must declare java.rmi.RemoteException
in its throws
clause (plus any other application-specific exceptions).
Any object passed as an argument must be serializable
.
A remote object, passed as an argument or return value must be declared as the remote interface, not the implementation class.
Structure of an RMI Application
A remote time service
The remote object
Setting up the server
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).
Starting the registry
The Server
Some potential problems
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!
Registration for RMI serving
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’re not finished yet!
The stub and skeleton
Created for you by
rmic
(RMI compiler)
1)
rmic uk.ac.swan.egm42.rmi.TimeHere
Now we can write the client
RMI Deployment
Calling the remote method
To Make it Work (1)
grant {
permission java.security.AllPermission;
};
Not this setting effectively turns Java's security system. It should never be used on a production server!
To Make it Work (2)
<cli prompt='>'>
e:\dev\at-m42-2009\Examples\lecture11>groovy startTimeHere.groovy
Ready to tell time
</cli>
<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>
Distributed Computing APIs
Object Serialization
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!
How RMI uses Serialization
Recall that in Groovy, method parameters are passed by value
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
Passing an Object 1
Passing an Object 2
Passing an Object 3
Passing an Object 4
Thought Question
Hint
Distributed Computing APIs
Naming and Directory Services
JNDI: Accessing Naming and Directory Services
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.
JNDI – the facts
Distributed Computing APIs
CORBA and SOAP
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.
What is CORBA?
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.
CORBA vs. RMI
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-IIOP
A One Slide Guide to SOAP
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).
Distributed Computing APIs
Restful Web Services
“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
2).”
Wikipedia article
In summary, the five key principles3)
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.
Give every "thing" an ID
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.
Link things together
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.
Use standard methods
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.
RESTful services
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.
Resources with multiple representations
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.
Communicate statelessly
Impact of REST
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.
Distributed Computing APIs
JINI: distributed services
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 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.
JINI: Peer-to-Peer Networking
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.
An example of JINI in use
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.
Summary
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.
What Should You Remember?
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