Download 15.Distribute Objects

Survey
yes no Was this document useful for you?
   Thank you for your participation!

* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project

Document related concepts
no text concepts found
Transcript
Distributed Objects

Distributed Objects (Background)
The message-passing paradigm is a natural model for distributed computing, in the
sense that it mimics inter-human communications. It is an appropriate paradigm
for network services where processes interact with each other through the
exchanges of messages.
 However, the abstraction provided by this paradigm does not meet the needs of
the complexity of sophisticated network applications.
 Message passing requires the participating processes to be tightly-coupled
throughout their interaction and the processes must be in direct communication
with each other.
 The message-passing paradigm is data-oriented.



Each message contains data marshalled in a mutually agreed upon format, and is
interpreted as a request or response according to the protocol.
The receiving of each message triggers an action in the receiving process.
This is inadequate for complex applications involving a large mix of requests and
responses (can become too difficult to manage and is overwhelming).
1
Distributed Objects

The Distributed Object Paradigm




The distributed object paradigm is a paradigm that provides abstractions beyond
those of the message-passing model.
As its name implies, the paradigm is based on objects that exist in a distributed
system.
In object-oriented programming, supported by an object-oriented programming
language such as Java, objects are used to represent an entity significant to an
application. Each object encapsulates:
 the state or data of the entity (in Java, such data is contained in the instance
variables of each object);
 the operations of the entity, through which the state of the entity can be
accessed or updated.
This abstraction model allows us to hide some complexity and interact with
entities that are at a higher level and hence somewhat closer to the real world.
2
Distributed Objects

Object Representation (Example)
public class DatagramMessage { // class to use during UDP based communication
private String message;
private InetAddress senderAddress;
private int senderPort;
public void putVal(String message, InetAddress addr, int port) {
this.message = message;
this.senderAddress = addr;
Each object instantiated from this class contains three state
this.senderPort = port;
data items:
}
public String getMessage( ) {
return this.message;
}
public InetAddress getAddress( ) {
return this.senderAddress;
}
public int getPort( ) {
return this.senderPort;
}
} // end class
a message,
the sender’s address,
and the sender’s port number.
In addition, each object contains three operations:
a method putVal, which allows the values of these
data items to be modified,
a getMessage method, which allows the current value
of the message to be retrieved, and
a getAddress method, which allows the sender’s
address to be retrieved.
3
Distributed Objects

Local Objects vs. Distributed Objects



Local objects are those whose methods can only be invoked by a local process,
a process that runs on the same computer on which the object exists.
A distributed object is one whose methods can be invoked by a remote process,
a process running on a computer connected via a network to the computer on
which the object exists.
Message Passing versus Distributed Objects


Compared to the message-passing paradigm, which is data-oriented, the
distributed objects paradigm is action-oriented:
 The focus is on the invocation of the operations, while the data passed
takes on a secondary role.
Although less intuitive to human-beings, the distributed-object paradigm is
more natural to object-oriented software development.
4
Distributed Objects

The Distributed Object Paradigm



In a distributed object paradigm, network resources are represented by
distributed objects.
To request service from a network resource, a process invokes one of its
operations or methods, passing data as parameters to the method.
The method is executed on the remote host, and the response is sent back to the
requesting process as a return value.
A process running in host A makes a method
Host A
Host B
client process
method call
object state data item
object operation
call to a distributed object residing on host B,
passing with the call data for the parameters, if
any.
The method call invokes an action performed
by the method on host B, and a return value, if
any, is passed from host B to host A.
A process which makes use of a distributed
object is said to be a client process of that
object, and the methods of the object are called
remote methods (as opposed to local methods,
or methods belonging to a local object) to the
client process.
a distributed object
5
Distributed Objects

An Archetypal Distributed Objects System
object
registry
object client
object server
client
proxy
server
proxy
runtime
support
runtime
support
network
support
network
support
physical data path
logical data path
A distributed object is provided, or exported,
by a process, here called the object server.
A facility, here called an object registry,
must be present in the system architecture for
the distributed object to be registered.
To access a distributed object, a process –an
object client – looks up the object registry
for a reference[1] to the object. This
reference is used by the object client to make
calls to the methods.
Logically, the object client makes a call
directly to a remote method.
In reality, the call is handled by a software
component, called a client proxy, which
interacts which the software on the client host
that provides the runtime support for the
distributed object system.
[1]A reference is a “handle” for an object; it
is a representation through which an object
can be located in the computer where the
6
object resides.
Distributed Objects

Distributed Object Activity (Server Side)

The runtime support is responsible for the inter-process communication
needed to transmit the call to the remote host, including the marshalling of
the argument data that needs to be transmitted to the remote object.

A similar architecture is required on the server side (to that of the client
side), where the runtime support for the distributed object system handles
the receiving of messages and the un-marshalling of data, and forwards the
call to a software component called the server proxy.

The server proxy interfaces with the distributed object to invoke the method
call locally, passing in the un-marshalled data for the arguments.

The method call results in the performance of some tasks on the server host.
The outcome of the execution of the method, including the marshalled data
for the return value, is forwarded by the server proxy to the client proxy, via
the runtime support and network support on both sides.
7
Distributed Objects

Distributed Object Systems/Protocols

The distributed object paradigm has been widely adopted in distributed
applications, for which a large number of mechanisms based on the paradigm
are available. Among the most well known of such mechanisms are:






Java Remote Method Invocation (RMI),
Common Object Request Broker Architecture (CORBA) systems,
Distributed Component Object Model (DCOM)/.NET/WCF
Mechanisms that support the Simple Object Access Protocol (SOAP).
Remote Method Invocation (RMI) is a Java object-oriented implementation of
the Remote Procedure Call model. Using RMI, an object server exports a
remote object and registers it with a directory service. The object provides
remote methods, which can be invoked in client programs.
Syntactically:



A remote object is declared with a remote interface
The remote interface is implemented by the object server.
An object client accesses the object by invoking the remote methods associated
with the objects using syntax provided for remote method invocations.
8
Distributed Objects

Directory service
The Java RMI Architecture
object
client
object
server
stub
skeleton
supports the interface with
the application program
maps the platform-independent stub/skeleton
layer to the platform-dependent transport
layer; carries out remote reference protocols
remote reference layer
remote reference layer
transport layer
transport layer
sets up, maintains, and shuts down
connections; and carries out the
transport protocol
logical data path
physical data path
9
Distributed Objects

Java Remote Method Invocation(RMI)


Java provides a form of RPC called Remote Method Invocation(RMI), that
allows objects to communicate via their methods regardless of their location.
Data transfer is handled by object streams automatically.




To create a class that will be remotely accessible, you must define an interface
which declares those methods that you wish to make public.
A stub and skeleton are then generated automatically using Java reflection.
The final setup involved in using RMI is that the remote object must be registered
with the Object Registry (naming service) that allows clients to access them.
When a client wishes to make calls to a remote object, it must first look up the
object in the Object Registry.

This returns a remote reference to the object which immediately informs the object
that it has a remote client.
Once the client has the stub, it has all
the information necessary to invoke
methods of the remote object.
The skeleton then makes the actual
method call on the remote object; the
return value is finally sent back from
the skeleton to the stub, which then
returns the result to the client.
10
Distributed Objects

Defining the Java RMI remote Interface

An interface must be written for the remote object, defining all methods that
should be public. The interface must extend java.rmi.remote (an interface which
identifies that a reference is to a remote object). For example:
import java.rmi.*;
public interface MyRemote extends Remote {
public Object myMethod (String s) throws RemoteException;
}

Implementing the Java RMI RemoteObject

The remote object must implement any of the remote interfaces that it wishes to
Java Reflection is used to created the
support. For example
stubs dynamically at run time.
public class MyRemoteImpl implements MyRemote{
When an object registers itself with the
public MyRemoteImpl () {
registry, it specifies a name by which it
public Object myMethod (String s) {
is to be referenced. Remote clients can
return s;
contact the registry and locate the
object based on this name.
}
}
Java Reflection
makes it possible to inspect classes, interfaces,
fields and methods at runtime, without knowing the names of the
classes, methods etc. at compile time. It is also possible to
instantiate new objects, invoke methods and get/set field values
using reflection.
11
Distributed Objects

Testing and Debugging an RMI Application





1.Build a template for a minimal RMI program.
 Start with a remote interface with a single signature, its implementation
using a stub, a server program which exports the object, and a client
program which invokes the remote method. Test the template programs on
one host until the remote method can be made successfully.
2.Add one signature at a time to the interface.
 With each addition, modify the client program to invoke the added method.
3.Fill in the definition of each remote method, one at a time.
 Test and debug each newly added method before proceeding with the next
one.
4.After all remote methods have been thoroughly tested, develop the client
application using an incremental approach.
 With each increment, test and debug the programs.
Note. All this can be done on your own local machine before running it across
the network.
12
Distributed Objects

Comparison of the RMI and the Socket APIs
 The remote method invocation API is an efficient tool for building
network applications.
 It can be used in lieu of the socket API in a network application.
 Some of the tradeoffs between the RMI API and the socket API are as
follows:


The socket API is closely related to the operating system, and hence has
less execution overhead.
 For applications which require high performance, this may be a
consideration.
The RMI API provides the abstraction which eases the task of software
development.
 Programs developed with a higher level of abstraction are more
comprehensible and hence easier to debug.
13
Distributed Objects

XML-RPC

XML-RPC is a spec and a set of implementations that allow software running
on disparate operating systems, running in different environments to make
procedure calls over the Internet



XML-RPC is designed to be as simple as possible, while allowing complex data
structures to be transmitted, processed and returned


Languages include:
C/C++, Java, Perl, Python, Frontier, Lisp, PHP, Microsoft .NET,
It's remote procedure calling uses HTTP as the transport and XML as the encoding.
Uses existing protocols (HTTP) and a well established framework (XML).
XML-RPC is a protocol that works over the Internet.



An XML-RPC message is an HTTP-POST request.
The body of the request is in XML.
A procedure executes on the server and the value it returns is also formatted in
XML.
14
Distributed Objects

XML-RPC Request (Example)
•
POST /RPC2 HTTP/1.0
User-Agent: Frontier/5.1.2 (WinNT)
Host: erne.dyndns.com
•
Content-Type: text/xml
Content-length: 144
<?xml version="1.0"?>
<methodCall>
<methodName>examples.name</methodName>
<params>
<param>
•
<value><i4>41</i4></value>
</param>
</params>
</methodCall>
•
The payload is in XML, a single <methodCall>
structure.
The <methodCall> must contain a <methodName>
sub-item, a string, containing the name of the
method to be called. The string may only contain
identifier characters, upper and lower-case A-Z, the
numeric characters, 0-9, underscore, dot, colon and
slash. It's entirely up to the server to decide how to
interpret the characters in a methodName.
For example, the methodName could be the name of
a file containing a script that executes on an
incoming request. It could be the name of a cell in a
database table. Or it could be a path to a file
contained within a hierarchy of folders and files.
If the procedure call has parameters, the
<methodCall> must contain a <params> sub-item.
The <params> sub-item can contain any number of
<param>s, each of which has a <value>.
15
Distributed Objects

Summary






The distributed objects paradigm is at a higher level of abstraction than the
message-passing paradigm.
Using the paradigm, a process invokes methods of a remote object, passing in
data as arguments and receiving a return value with each call, using syntax
similar to local method calls.
In a distributed object system, an object server provides a distributed object
whose methods can be invoked by an object client.
Each side requires a proxy which interacts with the system’s runtime support to
perform the necessary IPC.
Among the best-known distributed object system protocols are the Java Remote
Method Invocation (RMI), .NET/WCF, Common Object Request Broker
Architecture (CORBA) , XML-RPC and Simple Object Access Protocol
(SOAP).
An even higher architectural layer of software abstraction (encapsulating
distributed objects) can be constructed using Service Component Architecture
(SCA) or Service Oriented Architecture (SOA).
16