Local Objects vs. Distributed Objects                                                                      Local objects a...
An Archetypal Distributed Objects System                               Distributed Object System - 2                      ...
Distributed Object Systems/Protocols                          Static vs dynamic remote method invocationsThe distributed o...
Remote Method Invocation                                                                                          Object R...
The API for the Java RMI                                       A sample remote interface                                  ...
The Server-side Software                                                              UML diagram for the SomeImpl class  ...
The stub file for the object                                                    The Object Server - 2                     ...
The RMI Registry                                                                        The Object Server - 5A server expo...
The Client-side Software - 2                                       Invoking the Remote Methodimport java.rmi.*;….public cl...
Developing the server-side software                                                 Placement of files for a RMI applicati...
Comparison of the RMI and the socket APIs                          Diagrams for the Hello applicationThe remote method inv...
HelloImpl.java                                                       Running the Client  import java.rmi.*;  import java.r...
public static void main(String args[ ]) {       InputStreamReader is = new InputStreamReader(System.in);       BufferedRea...
Polling vs. Callback                                                                     In the absence of callback, a cli...
RMI Callbacks                                                                                                            C...
The Hello Application with Callback                                                                                       ...
Alogorithm for building an RMIHelloServer, with callback                                                  Callback Applica...
HelloClient, with callback    HelloClient() { // constructor         System.setSecurityManager(new RMISecurityManager()); ...
CORBA vs. Java RMI                                          The Basic Architecture CORBA differs from the architecture of ...
Cross-language CORBA application                                                 Inter-ORB Protocols                      ...
ORB products                                        CORBA Object References There are a large number of proprietary as    ...
Interoperable Object Reference                                                           CORBA Naming Service(IOR) An IOR ...
CORBA Naming Service                                                           A CORBA object name To be as general as pos...
Interoperable Naming Service                                               Object Adapters The Interoperable Naming Servic...
The Portable Object Adapter                       The CORBA Interface file Hello.idl There are different types of CORBA   ...
Lec7
Lec7
Lec7
Lec7
Lec7
Lec7
Upcoming SlideShare
Loading in …5
×

Lec7

271 views

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
271
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
4
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Lec7

  1. 1. 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 Distributed Object-Based Systems computer on which the object exists. Tanenbaum, Ch. 10 remote local C E invocation invocation local invocation remote invocation F A B local invocation D 1 3The Distributed Object Paradigm - 1 The Distributed Object Paradigm - 2 A process running in host A makes a method call to a The distributed object paradigm is a paradigm that distributed object residing on host B, passing with the call provides abstractions beyond those of the message- data for the parameters, if any. passing model. The method call invokes an action performed by the In object-oriented programming, objects are used to method on host A, and a return value, if any, is passed represent an entity significant to an application. Each from host A to host B. object encapsulates: A process which makes use of a distributed object is said to be a client process of that object, and the methods of the state or data of the entity: in Java, such data is contained the object are called remote methods (as opposed to local in the instance variables of each object; methods, or methods belonging to a local object) to the the operations of the entity, through which the state of the client process. entity can be accessed or updated. 2 4 1
  2. 2. An Archetypal Distributed Objects System Distributed Object System - 2 A similar architecture is required on the server side, where the object runtime support for the distributed object system handles the registry receiving of messages and the unmarshalling of data, and forwards the call to a software component called the server object client object server proxy. client server The server proxy interfaces with the distributed object to invoke proxy proxy the method call locally, passing in the unmarshalled data for the runtime runtime arguments. support support The method call results in the performance of some tasks on the network network server host. The outcome of the execution of the method, support support including the marshalled data for the return value, is forwarded by the server proxy to the client proxy, via the runtime support physical data path and network support on both sides. logical data path 5 7Distributed Object System Distributed Object System - 3 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 2-16 distributed object system. Common organization of a remote object with client-side proxy. The runtime support is responsible for the interprocess 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. 6 8 2
  3. 3. Distributed Object Systems/Protocols Static vs dynamic remote method invocationsThe distributed object paradigm has been widely adopted Typical way for writing code that uses RMI is similar in distributed applications, for which a large number to the process for writing RPC declare the interface in IDL, compile the IDL file to generate of mechanisms based on the paradigm are available. client and server stubs, link them with client and server side Among the most well known of such mechanisms are: code to generate the client and the server executables ~ Java Remote Method Invocation (RMI), referred to as static invocation ~ the Common Object Request Broker Architecture (CORBA) requires the object interface to be known when the client is being developed systems, Dynamic invocation ~ the Distributed Component Object Model (DCOM), the method invocation is composed at run-time ~ mechanisms that support the Simple Object Access Protocol invoke(object, method, input_parameters, output_parameters) (SOAP). useful for applications where object interfaces areOf these, the most straightforward is the Java RMI discovered at run-time, e.g. object browser, batch processing systems for object invocations, “agents” 9 11 Persistent vs transient objects Persistent objects continue to exist even if they are not contained in the address space of a server process The “state” of a persistent object has to be stored Java Remote Method Invocation on a persistent store, i.e., secondary storage Invocation requests result in an instance of the object being created in the address space of a running process many policies possible for object instantiation and (de)instantiation Transient objects only exist as long as their container server processes are running 10 12 3
  4. 4. Remote Method Invocation Object Registry Remote Method Invocation (RMI) is an object-oriented The RMI API allows a number of directory services to be used implementation of the Remote Procedure Call model. It is an for registering a distributed object. One such service is the API for Java programs only. Java Naming and Directory Interface (JNDI), which is more Using RMI, an object server exports a remote object and general than the RMI registry, in the sense that it can be used registers it with a directory service. The object provides by applications that do not use the RMI API. remote methods, which can be invoked in client programs. We will use a simple directory service called the RMI registry, Syntactically: rmiregistry, which is provided with the Java Software A remote object is declared with a remote interface, an extension of the Development Kit (SDK). The RMI Registry is a service whose Java interface. server, when active, runs on the object server’s host The remote interface is implemented by the object server. machine, by convention and by default on the TCP port 1099. An object client accesses the object by invoking the remote methods associated with the objects using syntax provided for remote method invocations. 13 15 The Java RMI Architecture The interaction between the stub and the skeleton Directory service A time-event diagram describing the interaction between object object the stub and the skeleton: client server supports the interface with stub skeleton Remote the application program Method time marshal parameters; send Requestmaps the platform-independent stub/skeleton stub skeleton unmarshal parameterslayer to the platform-dependent transport Invoke methodlayer; carries out remote reference protocols remote reference layer remote reference layer execute code transport layer transport layer and return a sets up, maintains, and shuts down value receive return value connections; and carries out the marshal reply transport protocol send reply logical data path unmarshall reply; return value physical data path (based on http://java.sun.com.marketing/collateral/javarim.html) 14 16 4
  5. 5. The API for the Java RMI A sample remote interface // file: SomeInterface.javaThe Remote Interface // to be implemented by a Java RMI server class.The Server-side Software import java.rmi.* The Remote Interface Implementation public interface SomeInterface extends Remote { // signature of first remote method Stub and Skeleton Generations public String someMethod1( ) The Object Server throws java.rmi.RemoteException; // signature of second remote methodThe Client-side Software public int someMethod2( float ) throws java.rmi.RemoteException; // signature of other remote methods may follow } // end interface 17 19 The Remote Interface A sample remote interface - 2A Java interface is a class that serves as a template for The java.rmi.Remote exception must be listed in theother classes: it contains declarations or signatures of throw clause of each method signature.methods whose implementations are to be supplied by This exception is raised when errors occur during theclasses that implements the interface. processing of a remote method call, and the exceptionA java remote interface is an interface that inherits is required to be caught in the method caller’s program.from the Java Remote class, which allows the interface Causes of such exceptions include exceptions that mayto be implemented using RMI syntax. Other than the occur during interprocess communications, such asRemote extension and the Remote exception that must access failures and connection failures, as well asbe specified with each method signature, a remote problems unique to remote method invocations,interface has the same syntax as a regular or local Java including errors resulting from the object, the stub, orinterface. the skeleton not being found. 18 20 5
  6. 6. The Server-side Software UML diagram for the SomeImpl class An object server is an object that provides the SomeInterface methods of and the interface to a distributed object. UnicastRemoteObject Method1 Method2 Each object server must ... implement each of the remote methods specified in the interface, register an object which contains the implementation with SomeImpl a directory service. Method1 It is recommended that the two parts be provided as Method2 separate classes. ... UMLDiagram for SomeImpl 21 23 The Remote Interface Implementation Stub and Skeleton GenerationsA class which implements the remote interface should be provided. The syntax issimilar to a class that implements a local interface. In RMI, each distributed object requires a proxy each for the object server and the object client, knowns as the object’s skeleton and stub respectively. import java.rmi.*; These proxies are generated from the implementation of a remote interface import java.rmi.server.*; using a tool provided with the Java SDK: the RMI compiler rmic. /** rmic <class name of the remote interface implementation> * This class implements the remote interface SomeInterface. */ For example: public class SomeImpl extends UnicastRemoteObject rmic SomeImpl implements SomeInterface { public SomeImpl() throws RemoteException { As a result of the compilation, two proxy files will be generated, each super( ); prefixed with the implementation class name: } SomeImpl_skel.class public String someMethod1( ) throws RemoteException { SomeImpl_stub.class. // code to be supplied } public int someMethod2( ) throws RemoteException { // code to be supplied } } // end class 22 24 6
  7. 7. The stub file for the object The Object Server - 2 // This method starts a RMI registry on the local host, if itThe stub file for the object, as well as the remote // does not already exists at the specified port number. private static void startRegistry(int RMIPortNum)interface file, must be shared with each object client – throws RemoteException{ try {these file are required for the client program to Registry registry= LocateRegistry.getRegistry(RMIPortNum); registry.list( );compile. // The above call will throw an exception // if the registry does not already existA copy of each file may be provided to the object } catch (RemoteException ex) {client by hand. In addition, the Java RMI has a feature // No valid registry at that port. System.out.println(called “stub downloading” which allows a stub file to "RMI registry cannot be located at port " + RMIPortNum); Registry registry= LocateRegistry.createRegistry(RMIPortNum);be obtained by a client dynamically. System.out.println( "RMI registry created at port " + RMIPortNum); } } // end startRegistry 25 27 The Object Server The Object Server - 3The object server class is a class whose code instantiates and exports an In our object server template, the code for exporting an object is as follows:object of the remote interface implementation. Figure 10 shows a template // register the object under the name “some”for the object server class. registryURL = "rmi://localhost:" + portNum + import java.rmi.*; …… "/some"; public class SomeServer { Naming.rebind(registryURL, exportedObj); public static void main(String args[]) { The Naming class provides methods for storing and obtaining references from the registry. In try{ particular, the rebind method allow an object reference to be stored in the registry with a URL // code for port number value to be supplied in the form of SomeImpl exportedObj = new SomeImpl(); rmi://<host name>:<port number>/<reference name> startRegistry(RMIPortNum); The rebind method will overwrite any reference in the registry bound with the given reference // register the object under the name “some” name. If the overwriting is not desirable, there is also a bind method. registryURL = "rmi://localhost:" + portNum + "/some"; Naming.rebind(registryURL, exportedObj); The host name should be the name of the server, or simply “localhost”. The reference name is a name of your choice, and should be unique in the registry. System.out.println("Some Server ready."); }// end try } // end main 26 28 7
  8. 8. The RMI Registry The Object Server - 5A server exports an object by registering it by a symbolic name with a server known asthe RMI registry. When an object server is executed, the exporting of the // Create an object of the Interface distributed object causes the server process to begin to SomeInterfacel obj = new SomeInterface(“Server1”); // Register the object; rebind will overwrite existing listen and wait for clients to connect and request the // registration by same name – bind( ) will not. service of the object. Naming.rebind(“Server1”, obj);A server, called the RMI Registry, is required to run on the host of the server which An RMI object server is a concurrent server: eachexports remote objects. request from an object client is serviced using aThe RMIRegistry is a server located at port 1099 by defaultIt can be invoked dynamically in the server class: separate thread of the server. Note that if a client import java.rmi.registry.LocateRegistry; process invokes multiple remote method calls, these … LocateRegistry.createRegistry ( 1099 ); calls will be executed concurrently unless provisions … are made in the client process to synchronize the calls. 29 31 The RMI Registry - 2 The Client-side SoftwareAlternatively, an RMI registry can be activated by The program for the client class is like any other Javahand using the rmiregistry utility which comes with the class.Java Software Development Kit (SDK), as follows: The syntax needed for RMI involves rmiregistry <port number> locating the RMI Registry in the server host,where the port number is a TCP port number. If no andport number is specified, port number 1099 is assumed. looking up the remote reference for the server object; theThe registry will run continuously until it is shut down reference can then be cast to the remote interface class and(via CTRL-C, for example) the remote methods invoked. 30 32 8
  9. 9. The Client-side Software - 2 Invoking the Remote Methodimport java.rmi.*;….public class SomeClient { The remote interface reference can be used to invoke public static void main(String args[]) { any of the methods in the remote interface, as in the try { String registryURL = example: "rmi://localhost:" + portNum + "/some"; SomeInterface h = String message = h.method1(); (SomeInterface)Naming.lookup(registryURL); System.out.println(message); // invoke the remote method(s) String message = h.method1(); Note that the syntax for the invocation of the remote System.out.println(message); // method2 can be invoked similarly methods is the same as for local methods. } // end try catch (Exception e) { It is a common mistake to cast the object retrieved System.out.println("Exception in SomeClient: " + e); from the registry to the interface implementation class } } //end main or the server object class . Instead it should be cast as // Definition for other methods of the class, if any.}//end class the interface class. 33 35 Looking up the remote objectThe lookup method of the Naming class is used toretrieve the object reference, if any, previously storedin the registry by the object server. Note that theretrieved reference must be cast to the remote Steps for building an RMI applicationinterface (not its implementation) class. String registryURL = "rmi://localhost:" + portNum + "/some"; SomeInterface h = (SomeInterface)Naming.lookup(registryURL); 34 36 9
  10. 10. Developing the server-side software Placement of files for a RMI application1. Open a directory for all the files to be generated for this application.2. Specify and compile the remote-server interface in SomeInterface.java3. Implement and compile the interface in SomeImpl.java Object Client host Object Server host4. Use the RMI compiler rmic to process the implementation class and generate the stub file and skelton file for the remote object: object server directory rmic SomeImpl object client directory SomeInterface.class The files generated can be found in the directory as SomeImpl_Skel.class and SomeImpl_Stub.class. SomeInterface.class SomeServer.class Steps 3 and 4 must be repeated each time that a change is made to the SomeImpl.class interface implementation. SomeClient.class5. Create and compile the object server program SomeServer.java. SomeImpl_Skel.class SomeImpl_Stub.class6. Activate the object server java SomeServer 37 39 Developing the client-side software Testing and Debugging an RMI Application1. Open a directory for all the files to be generated for this application. 1. Build a template for a minimal RMI program. Start with a remote interface2. Obtain a copy of the remote interface class file. Alternatively, obtain a with a single signature, its implementation using a stub, a server program copy of the source file for the remote interface, and compile it using javac which exports the object, and a client program which invokes the remote to generate the interface class file. method. Test the template programs on one host until the remote method can3. Obtain a copy of the stub file for the implementation of the interface: be made successfully. SomeImpl_Stub.class. 2. Add one signature at a time to the interface. With each addition, modify the4. Develop the client program SomeClient.java, and compile it to generate client program to invoke the added method. the client class. 3. Fill in the definition of each remote method, one at a time. Test and5. Activate the client. thoroughly debug each newly added method before proceeding with the next one. java SomeClient 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. 38 40 10
  11. 11. Comparison of the RMI and the socket APIs Diagrams for the Hello applicationThe remote method invocation API is an efficient toolfor building network applications. It can be used in HelloInterfacelieu of the socket API in a network application. Someof the tradeoffs between the RMI API and the socket UnicastRemoteObject sayHello( )API are as follows: HelloServer HelloImpl The socket API is closely related to the operating system, HelloClient and hence has less execution overhead. For applications listRegistry( ) which require high performance, this may be a consideration. startRegistry( ) UML diagram The RMI API provides the abstraction which eases the task client registry server of software development. Programs developed with a higher rebind( ) level of abstraction are more comprehensible and hence look up( ) easier to debug. sayHello( ) sequence diagram 41 43 HelloInterface.java import java.rmi.*; public interface HelloInterface The HelloWorld Sample extends Remote { public String sayHello(String name) throws java.rmi.RemoteException; } 42 44 11
  12. 12. HelloImpl.java Running the Client import java.rmi.*; import java.rmi.server.*; % java HelloClient Enter the RMIRegistry host number: public class HelloImpl extends UnicastRemoteObject localhost implements HelloInterface { Enter the RMIRegistry port number: 3232 public HelloImpl() throws RemoteException { Lookup completed super(); HelloClient: Hello, World! Daffy Duck } % public String sayHello(String name) throws RemoteException { return "Hello, World! " + name; } } 45 47import java.io.*; import java.rmi.*; HelloServer.java import java.rmi.server.*;import java.rmi.*; HelloClient.java import java.rmi.registry.Registry; (overall structure)public class HelloClient { import java.rmi.registry.LocateRegistry; public static void main(String args[ ]) { import java.net.*; try { int RMIPort; import java.io.*; String hostName; InputStreamReader is = new InputStreamReader(System.in); public class HelloServer { BufferedReader br = new BufferedReader(is); public static void main(String args[ ]) { System.out.println("Enter the RMIRegistry host number: "); hostName = br.readLine(); … System.out.println("Enter the RMIRegistry port number: "); } String portNum = br.readLine(); private static void startRegistry(int RMIPortNum) RMIPort = Integer.parseInt(portNum); throws RemoteException { String registryURL = "rmi://"+hostName+":"+portNum+"/hello"; … HelloInterface h = (HelloInterface)Naming.lookup(registryURL); System.out.println("Lookup completed "); } String message = h.sayHello("Daffy Duck"); private static void listRegistry(String registryURL) System.out.println("HelloClient: " + message); } throws RemoteException, MalformedURLException catch (Exception e) { { System.out.println("Exception in HelloClient: " + e); … } } }} } 46 48 12
  13. 13. public static void main(String args[ ]) { InputStreamReader is = new InputStreamReader(System.in); BufferedReader br = new BufferedReader(is); String portNum, registryURL; private static void listRegistry(String registryURL) try{ System.out.println("Enter the RMIregistry port throws RemoteException, MalformedURLException number:"); { portNum = (br.readLine()).trim(); System.out.println("Registry " + registryURL + " int RMIPortNum = Integer.parseInt(portNum); contains:"); startRegistry(RMIPortNum); String[] names = Naming.list(registryURL); HelloImpl exportedObj = new HelloImpl(); for (int i =0;i< names.length;i++) registryURL = "rmi://localhost:" + portNum + "/hello"; Naming.rebind(registryURL,exportedObj); System.out.println(names[i]); System.out.println("Server registered. Registry } currently contains:"); listRegistry(registryURL); System.out.println("Hello Server ready."); } //end try catch (Exception re) { HelloServer.java System.out.println("Exception in HelloServer.main: " + re); (listRegistry) } } HelloServer.java (main) 49 51// This method starts an RMI registry at port RMIPortNum if Running the Server// it does not already exist. private static void startRegistry(int RMIPortNum) throws RemoteException { % java HelloServer try { Enter the RMIregistry port number: Registry registry = LocateRegistry.getRegistry(RMIPortNum); registry.list(); 3232 } RMI registry cannot be located at port 3232 catch (RemoteException e) { RMI registry created at port 3232 System.out.println("RMI registry cannot be located at port Server registered. Registry currently contains: " + RMIPortNum); Registry rmi://localhost:3232/hello contains: Registry registry = //localhost:3232/hello LocateRegistry.createRegistry(RMIPortNum); Hello Server ready. System.out.println("RMI registry created at port " + RMIPortNum); HelloServer.java (startRegistry) 50 52 13
  14. 14. Polling vs. Callback In the absence of callback, a client will have to poll a passive server repeatedly if it needs to be notified that an event has occurred at the server end.RMI Callbacks Polling Callback Server Server ... Client Client A client registers itself with the A client issues a request to the server, and wait until the server server repeatedly until the calls back. desired response is obtained. a remote method call 53 55Introduction Two-way communications Some applications require that both sides may initiate IPC. In the client server model, the server is passive: the IPC Using sockets, duplex communication can be achieved by using is initiated by the client; the server waits for the arrival two sockets on either side. of requests and provides responses. With connection-oriented sockets, each side acts as both a client and Some applications require the server to initiate communication upon certain events. Examples applications a server. are: Process 1 Process 1 • monitoring • games request • auctioning response • voting/polling • chat-toom • message/bulletin board request • groupware response 54 56 14
  15. 15. RMI Callbacks Callback application files A callback client registers itself with an RMI server. Object client host Object server host The server makes a callback to each registered client upon the occurrence of a certain event. object client directory object server directory Server Clients Client.class Server.class C1 ClientInterface.class S erverInterface.class The callback list S erverInterface.class ClientInterface.class C2 ClientImpl.class ServerImpl.class RMI calls C3 callback S erverImpl_S tub.class ClientImpl_S tub.class C4 ClientImpl_skel.class S erverImpl_skel.class C5 57 59Callback Client-Server Interactions RMI Callback file placements Server host Client host 1 Client.class 2 RMI registry Client host Server host SomeInterface_stub.class client directory server directory 3,4 SomeClient.class SomeServer.class SomeInterface_skel.class CallbackInterface_skel.class SomeInterface_stub.class X SomeServer.class SomeInterface.Skeleton.class java.policy CallbackInterface_skel.class 5 CallbackInterface_stub.class CallbackInterface_stub.class 1. Client looks up the interface object in the RMIregistry on the server host. java.polcy 2. The RMIRegistry returns a remote reference to the interface object. 3. Via the server stub, the client process invokes a remote method to register itself for callback, passing a remote reference to itself to the server. The server saves the reference in its callback list. HTTP Server 4. Via the server stub, the client process interacts with the skeleton of the interface object to access the methods in the interface object. SomeInterface_stub.class 5. When the anticipated event takes place, the server makes a callback to each registered client via the callback interface stub on the server side and the callback interface skeleton on the client side. 58 60 15
  16. 16. The Hello Application with Callback Remote Interface for Server CallbackClient HelloInterface public interface HelloInterface extends Remote { Interface UnicastRemoteObject sayHello( ) notifyMe( ) UnicastRemoteObject // remote method public String sayHello() throws java.rmi.RemoteException; HelloServer HelloImpl C al lbackClie nt C allbackC lie nt mpl // method to be invoked by a client to add itself to the callback list public void addCallback( listRegistry( ) startRegistry( ) UML diagram HelloCallbackInterface CallbackObject) client registry server throws java.rmi.RemoteException; } rebind( ) look up( ) sayHello( ) addCallback ( ) notifyMe( ) sequence diagram 61 63 Remote Interface for CallbackRMI Callback Interface Client The server provides a remote method which allows a // an interface specifying a callback method client to register itself for callbacks. public interface HelloCallbackInterface extends java.rmi.Remote A Remote interface for the callback is needed, in { addition to the server-side interface. // method to be called by the server on callback The interface specifies a method for accepting a callback public void callMe ( from the server. String message The client program is a subclass of RemoteObject and ) throws java.rmi.RemoteException; implements the callback interface, including the callback } method. The client registers itself for callback in its main method. The server invokes the client’s remote method upon the occurrence of the anticipated event. 62 64 16
  17. 17. Alogorithm for building an RMIHelloServer, with callback Callback Applicationpublic class HelloServer extends UnicastRemoteObject implements Server side: HelloInterface { 1. Open a directory for all the files to be generated for this static int RMIPort; application. // vector for store list of callback objects 2. Specify the remote-server interface, and compile it to generate private static Vector callbackObjects; the interface class file. 3. Build the remote server class by implementing the interface, and public HelloServer() throws RemoteException { compile it using javac. super(); 4. Use rmic to process the server class to generate a stub.class file // instantiate a Vector object for storing callback objects and a skelton.class file: rmic SomeServer callbackObjects = new Vector(); 5. If stub downloading is desired, copy the stub file to an } appropriate directory on the HTTP host. // method for client to call to add itself to its callback 6. Activate the RMIRegistry, if it has not already been activated. public void addCallback( HelloCallbackInterface CallbackObject) { // store the callback object into the vector 7. Set up a java.policy file. System.out.println("Server got an addCallback call."); 8. Activate the server, specifying (i) the codebase if stub callbackObjects.addElement (CallbackObject); downloading is desired, (ii) the server host name, and (iii) the } security policy file. 9. Obtain the CallbackInterface. Compile it with javac, then use 65 rmic to generate the stub file for the callback. 67 Alogorithm for building an RMI HelloServer, with callback - 2 Callback Applicationpublic static void main(String args[]) { Client side: … 1. Open a directory for all the files to be generated for registry = LocateRegistry.createRegistry(RMIPort); this application. … callback( ); 2. Implement the client program or applet, and compile it … to generate the client class. } // end main 3. If stub downloading is not in effect, copy the server private static void callback( ) { interface stub class file by hand. … 4. Implement the callback interface. Compile it using for (int i = 0; i < callbackObjects.size(); i++) { javac, then using rmic to generate a stub class and a System.out.println("Now performing the "+ i +"th callbackn"); skeleton class for it. // convert the vector object to a callback object 5. Set up a java.policy file. HelloCallbackInterface client = (HelloCallbackInterface) callbackObjects.elementAt(i); 6. Activate the client, specifying (i) the server host … name, and (ii) the security policy file. client.callMe ( "Server calling back to client " + i); … 66 68 17
  18. 18. HelloClient, with callback HelloClient() { // constructor System.setSecurityManager(new RMISecurityManager()); // export this object as a remote object UnicastRemoteObject.exportObject(this); // … Registry registry = LocateRegistry.getRegistry("localhost", RMIPort); h = (HelloInterface) registry.lookup("helloLiu"); h.addCallback(this); // … The Common Object Request Broker } // end constructor // call back method - this displays the message sent by the server public void callMe (String message) { } System.out.println( "Call back received: " + message ); public static void main(String args[]) { // … Architecture (CORBA) HelloClient client = new HelloClient(); // … while (true){ ; } // end while } // end main} // end HelloClient class 69 71HelloServer, HelloClient CORBA UnicastRemoteObject HelloInterface UnicastRemoteObject CallbackInterface The Common Object Request Broker Architecture (CORBA) is a standard sayHello sayHello HelloServer HelloClient RMIPort architecture for a distributed objects system. RMIPort sayHello sayHello addCallback callMe Class Diagram for HelloServer Class Diagram for HelloClient CORBA is designed to allow distributed HelloClient RMIregistry HelloServer objects to interoperate in a heterogenous getRegistry environment, where objects can be sayHello implemented in different programming language and/or deployed on different addCallback platforms callMe Event diagram for the Hello application 70 72 18
  19. 19. CORBA vs. Java RMI The Basic Architecture CORBA differs from the architecture of naming lookup Java RMI in one significant aspect: object naming service object client implementation RMI is a proprietary facility developed by Sun MicroSystems, Inc., and supports objects stub skeleton written in the Java programming langugage only. ORB ORB CORBA is an architecture that was developed by the Object Management Group (OMG), an network network industrial consortium. operating operating system system logical data flow physical data flow 73 75CORBA CORBA Object Interface A distributed object is defined using a software file similar to CORBA is not in inself a distributed objects the remote interface file in Java RMI. facility; instead, it is a set of protocols. Since CORBA is language independent, the interface is defined using a universal language with a distinct syntax, known as the A distributed object facility which adhere to CORBA Interface Definition Language (IDL). these protocols is said to be CORBA-compliant, The syntax of CORBA IDL is similar to Java and C++. However, and the distributed objects that the facility object defined in a CORBA IDL file can be implemented in a large number of diverse programming languages, including C, C++, support can interoperate with objects supported Java, COBOL, Smalltalk, Ada, Lisp, Python, and IDLScript. by other CORBA-compliant facilities. For each of these languages, OMG has a standardized mapping CORBA is a very rich set of protocols. We will from CORBA IDL to the programming language, so that a compiler can be used to process a CORBA interface to generate instead focus on the key concepts of CORBA the proxy files needed to interface with an object related to the distributed objects paradigm. We implementation or an object client written in any of the CORBA- will also study a facility based on CORBA: the Java compatible languages. IDL. 74 76 19
  20. 20. Cross-language CORBA application Inter-ORB Protocols The IIOP specification includes the following elements: 1. Transport management requirements: specifies the connection and disconnection requirements, and the roles for the object client and object server in making and unmaking object implementation written object client written in Java connections. in C++ 2. Definition of common data representation: a coding scheme skeleton in C ++ ge ne rate d by for marshalling and unmarshalling data of each IDL data type.stub in Java generated by compiling the C O RBA obje ct inte rface compiling the C O RBA obje ct 3. Message formats: different types of message format are inte rface defined. The messages allow clients to send requests to object servers and receive replies. A client uses a Request message to ORB written in Java ORB written in C++ invoke a method declared in a CORBA interface for an object and receives a reply message from the server. 77 79Inter-ORB Protocols Object Bus An ORB which adheres to the specifications of the IIOP To allow ORBs to be interoperable, the OMG may interoperate with any other IIOP-compliant ORBs over the Internet. This gives rise to the term “object bus”, specified a protocol known as the General where the Internet is seen as a bus that interconnects Inter-ORB Protocol (GIOP), a specification CORBA objects which “provides a general framework for CORBA CORBA CORBA protocols to be built on top of specific object object object transport layers.” A special case of the protocol is the Inter- ORB ORB ... ORB ORB Protocol (IIOP), which is the GIOP applied to the TCP/IP transport layer. The Internet 78 80 20
  21. 21. ORB products CORBA Object References There are a large number of proprietary as As in Java RMI, a CORBA distributed well as experimental ORBs available: object is located using an object (See CORBA Product Profiles, reference. Since CORBA is language- http://www.puder.org/corba/matrix/) independent, a CORBA object reference is Orbix IONA an abstract entity mapped to a language- Borland Visibroker specific object reference by an ORB, in a PrismTech’s OpenFusion representation chosen by the developer of Web Logic Enterprise from BEA the ORB. Ada Broker from ENST For interoperability, OMG specifies a Free ORBs protocol for the abstract CORBA object reference object, known as the Interoperable Object Reference (IOR) 81 protocol. 83Object Servers and Object Interoperable Object ReferenceClients (IOR) As in Java RMI, a CORBA distributed For interoperability, OMG specifies a object is exported by an object server, protocol for the abstract CORBA object similar to the object server in RMI. reference object, known as the An object client retrieves a reference to a Interoperable Object Reference (IOR) distributed object from a naming or protocol. directory service, to be described, and An ORB compatible with the IOR protocol invokes the methods of the distributed will allow an object reference to be object. registered with and retrieved from any IOR-compliant directory service. CORBA object references represented in this protocol are called Interoperable Object 82 References (IORs). 84 21
  22. 22. Interoperable Object Reference CORBA Naming Service(IOR) An IOR is a string that contains encoding for CORBA specifies a generic directory service. The the following information: Naming Service serves as a directory for CORBA objects, and, as such, is platform independent and The type of the object. programming language independent. The host where the object can be found. The Naming Service permits ORB-based clients to The port number of the server for that object. obtain references to objects they wish to use. It An object key, a string of bytes identifying the allows names to be associated with object object. references. Clients may query a naming service The object key is used by an object server to using a predetermined name to obtain the associated locate the object. object reference. 85 87Interoperable Object Reference CORBA Naming Service(IOR) The following is an example of the string To export a distributed object, a CORBA object representation of an IOR [5]: server contacts a Naming Service to bind a IOR:000000000000000d49444c3a677269643a312e3000000 symbolic name to the object The Naming Service 00000000001000000000000004c0001000000000015756c74 maintains a database of names and the objects 72612e6475626c696e2e696f6e612e6965000009630000002 associated with them. 83a5c756c7472612e6475626c696e2e696f6e612e69653a67 To obtain a reference to the object, an object 7269643a303a3a49523a67726964003a client requests the Naming Service to look up the The representation consists of the character object associated with the name (This is known as prefix “IOR:” followed by a series of resolving the object name.) hexadecimal numeric characters, each The API for the Naming Service is specified in character representing 4 bits of binary data in interfaces defined in IDL, and includes methods that allow servers to bind names to objects and the IOR. clients to resolve those names. 86 88 22
  23. 23. CORBA Naming Service A CORBA object name To be as general as possible, the CORBA object naming scheme is necessary complex. Since the name space is universal, a standard naming hierarchy is defined in a manner The syntax for an object name is as follows: similar to the naming hierarchy in a file directory <naming context > …<naming context><object name> naming context1 where the sequence of naming contexts leads to the object name. naming context1 ... naming context2 ... naming context1 ... naming context1 ... object object name 1 name n 89 91A Naming Context Example of a naming hierarchy A naming context correspond to a folder or As shown, an object representing the directory in a file hierarchy, while object names corresponds to a file. men’s clothing department is named The full name of an object, including all the store.clothing.men, where store and associated naming contexts, is known as a clothing are naming contexts, and men is an compound name. The first component of a object name. store compound name gives the name of a naming context, in which the second component is accessed. This process continues until the last ... component of the compound name has been clothing Appliances reached. Naming contexts and name bindings are created ... using methods provided in the Naming Service women men television interface. 90 92 23
  24. 24. Interoperable Naming Service Object Adapters The Interoperable Naming Service (INS) is a In the basic architecture of CORBA, the implementation of a distributed object interfaces with the skeleton to interact URL-based naming system based on the CORBA with the stub on the object client side. As the architecture Naming Service, it allows applications to share a evolved, a software component in addition to the skeleton common initial naming context and provide a URL was needed on the server side: an object adapter. to access a CORBA object. distributed object implementation object adapter ORB 93 95CORBA Object Services Object Adapter CORBA specify services commonly needed in distributed An object adapter simplifies the applications, some of which are: Naming Service: responsibilities of an ORB by assisting an Concurrency Service: ORB in delivering a client request to an Event Service: for event synchronization; object implementation. Logging Service: for event logging; Scheduling Service: for event scheduling; When an ORB receives a client’s request, it Security Service: for security management; locates the object adapter associated with Trading Service: for locating a service by the type (instead of the object and forwards the request to by name); Time Service: a service for time-related events; the adapter. Notification Service: for events notification; The adapter interacts with the object Object Transaction Service: for transactional processing. implementation’s skeleton, which performs Each service is defined in a standard IDL that can be implemented by a developer of the service object, and whose data marshalling and invoke the appropriate methods can be invoked by a CORBA client. method in the object. 94 96 24
  25. 25. The Portable Object Adapter The CORBA Interface file Hello.idl There are different types of CORBA 01. module HelloApp object adapters. 02. { The Portable Object Adapter, or POA, is a 03. interface Hello particular type of object adapter that is 04. { defined by the CORBA specification. An 05. string sayHello(); object adapter that is a POA allows an 06. oneway void shutdown(); object implementation to function with 07. }; different ORBs, hence the word portable. 08. }; 97 99 Compiling the IDL file (using Java 1.4) The IDL file should be placed in a directory dedicated to the application. The file is compiled using the compiler idlj using a command as follows:A Java IDL application example idlj -fall Hello.idl The –fall command option is necessary for the compiler to generate all the files needed. In general, the files can be found in a subdirectory named <some name>App when an interface file named <some name>.idl is compiled. If the compilation is successful, the following files can be found in a HelloApp subdirectory: HelloOperations.java Hello.java HelloHelper.java HelloHolder.java _HelloStub.java HelloPOA.java These files require no modifications. 98 100 25

×