1 Lecture 11 George Koutsogiannakis / Summer 2011 CS441 CURRENT TOPICS IN PROGRAMMING LANGUAGES

1

Lecture 11

George Koutsogiannakis / Summer 2011

CS441

CURRENT TOPICS IN PROGRAMMING LANGUAGES

Topics

• REVIEW OF DEPLOYMENT ON TOMCAT

• RMI Callback

• RMI Over IIOP

• CORBA

• JAVA MESSAGING SERVICES

2

REVIEW OF DEPLOYMENT ON TOMCAT

• When your web application is ready for deployment, you need to package it for distribution.

• Archive the web application: jar cvf MyWebSite.war . (go to the directory where your folder MyWebSite exists, assuming that you develop the web site outside of Tomcat-- don't forget the dot at the end!)

• Deploy from Manager site of Tomcat. At the bottom of the manager site where it says "War File to Deploy" Browse to where your war file is located in your directory structure and then press deploy. A O.K. message and an entry onto thE list of deployed webapps means successful deployment.

• Test by calling the web application from a Browser instance.

3

RMI Callback

• In RMI Callback:– The client acts as a client needing the services of an

RMI server. It also provides and registers a remote object for a service that it provides to the server (thus acting as a server itself).

– The server has a remote service registered that the client can invoke. In addition, as part of its response to the client, when its service is invoked, the server can ask the client to invoke the client’s remote service and send a response back to the server.

4

RMI Callback

5

• RMI CALLBACK

stub

Remote objectimplementation

Object registry

Access to remote object requestedby name. Reference is returned.

Object ‘s methodis invoked

stub

Remote objectimplementation

Object registry

Client with a remoteService node

Server node

RMI Callback -sequence of communications

1. Server node registers a remote object for its service.

2. Client node registers a remote object for its service.

3. Client contacts registry and asks for server’ s remote object’ s refernce.

4. Registry responds to client with the reference

5. Client sends a message to server invoking the service.

6. Server prepares the message packets with required data from the execution of the service (if any).

1. In addition as part of the response to the client, the server contacts the registry and ask’s for a reference to the remote object that represents the client’ s service.

2. The registry responds with the reference to the server.

3. The server asks the client for the invocation of its service.

4. Therefore both the data from the execution of the server’s service an d the request for the client to execute its service for the server are sent out as part of the response to step 5.

7. The client receives the data that it requested and also executes its service to satisfy the server’s request.

8. The client sends any data to the server in its response to the server’s request.6

RMI Callback• Example code:

• Server registers a Payroll service (where Payroll is the name of the interface):

1. String ro = "//localhost/money";

2. PayrollImpl p = new PayrollImpl();

3. Naming.rebind(ro, p);

Where statement 1 is the name of the object to be registered (money).

Statement 2 is the server object.

Statement 3 is the registration of the object “money” with the registry.

7

RMI Callback

• Payroll service has a method called earnings implemented: by the server

public double earnings (int id, double hours)

This method receives an int and a double data types from the client when it makes a request to the server to invoke earnings.

It returns a double as part of the response to the client (the data).

• Inside the code for earnings method we generate the data to be

returned as a double to the client.– In addition, the code to invoke the service PayrollMessage (that is

the interface on the client side) on the client side is included:

8

RMI Callback

PayrollMessage pm =

(PayrollMessage) Naming.lookup("rmi://localhost:1099/message");

pm.message("I am ready to sent the payroll amount");

This code is the look up to the registry to create a reference for a remote object called message. The reference is captured with object pm.

Therefore we assume that the client has an interface called PayrollMessage and a remote name called “message” registered with the registry.

Next the server (from within earnings) invokes the client’s service called message:

pm.message("I am ready to sent the payroll amount");

Message does not return any data to the server (return is void).

9

RMI Callback

• The client can send a request to invoke the service Payroll (method earnings) as follows:

1. Payroll p = (Payroll)Naming.lookup("rmi://localhost:1099/money");

2. double m = p.earnings(id,d); where id is an int type

In statement 1 the client does a lookup on the registry requesting a reference to remote object money that represents the server’s service.

In statement 2 the client uses the reference it received (which is the object p) to invoke the server’ s method called earnings. It passes to the method an int and a double data type.

Successful response from the server is captured by the variable m (double type as expected from the method earnings)

10

RMI Callback

• The client has also implemented the service PayrollMessage that has method :

public void message(String str)

• Notice that message returns void as pointed out in slide 7.

• A response is sent anyway to the server (verifying that the method was executed) but no data is returned.

• SEE CALLBACK EXAMPLE ON THE COURSE’ S WEB SITE FOR DETAILED CODE

11

RMI Callback

• Notice that the distribution of the files are shown below:

12

Client Server

Client application programClient’ s interface: PayrollMessageClient’s stubServer ‘s stubServer’s interface: Payroll

Server application programServer’ s interface: PayrollServer’s stubClient ‘s stubClient’s interface: PayrollMessage

RMI Over IIOP

• The RMI over IIOP Framework allows communication between Java applications and Non Java applications.

• It generates automatically IDL (Interface Definition Language) code that acts as the intermediary data types between the client and the server applications (even if both are written in Java).– It frees the developer from having to know another language (IDL)

• It is slower, in general, than a similar RMI implementation.

13

RMI Over IIOP

• RMI Over IIOP IDL usage:

14

Client request- Client application could be Java

Java Data Types are converted to IDL data types and sent to server

IDL Data Types are converted to server’ s language data types

Server executes its service and returns any data

Server’ s language Data Types are converted to IDL data types

IDL Data Types are converted to client ’ s language data types (Java)

Client

RMI Over IIOP

• Sequence of communications remains the same as in RMI over IIOP.

• The registry, however, is different than the RMI registry and it called name server

Start the Name server on a DOS window:

> tnameserv –ORBInitialPort

It starts on default port 900 (unless we want a different port to be created).

15

Communication Layers

• Slightly different than RMI’ s since the transport protocol is IIOP.

16

Server Application

Tie(Presentation layer)

IIOP (Transport Layer)

Client Application

ORB – Object Request Broker(Session Layer)

Stub (Presentation layer)

IIOP(Transport Layer)

ORB – Object Request Broker(Session Layer)

TCP/IP TCP/IP


• IIOP is part of the GIOP protocol defined in CORBA.– GIOP defines various transport protocols working over various network protocols.

• The ORB is a layer that can be implemented by various vendors.

Sun ha sits own implementation in RMI over IIOP.

• RMI over IIOP is of particular interest to Enterprise Java Beans since the remote object model for EJBs is based on the RMI over IIOP model.

• The server class has to extend PortableRemoteObject. That inheritance sets up the IIOP protocol as the transport protocol.

• In IIOP each client request gets its own thread.

• Notice that a stub and a tie file is produced when the server program is compiled with a special compiler

17


• When a client processes a lookup on the name server, it receives from the name server a IOR (Inter Operable Object Reference).

• The ORB layer receives the IOR adds something called Tagged Profile and sets up the TCP connection with the server. It then marshals the invocation to the server.

• The ORB is also responsible for generating the Context Information (i.e. the data types to be transformed etc.)

• The transport protocol creates the IDL.

18

Differences Between RMI and RMI over IIOP

• CODING DIFFERENCES:– RMI INTERFACE:

import java.rmi.Remote;

import java.rmi.RemoteException;

public interface Payroll extends Remote

{

public double earnings (int id, double hours) throws RemoteException;

}

– RMI OVER IIOP INTERFACE:

import java.rmi.Remote;

import java.rmi.RemoteException;

public interface Payroll extends Remote

{

public double earnings (int id, double hours) throws RemoteException;

}

THEREFORE NO DIFFRENCE!!

19


– RMI SERVER IMPORT STATEMENTS:import java.rmi.*;

import java.rmi.server.*;

– RMI OVER IIOP IMPORT STATEMENTS:import java.rmi.*;

import java.rmi.server.*;

import javax.naming.InitialContext;

import javax.naming.Context;

import javax.naming.NamingException;

import javax.rmi.PortableRemoteObject;

– RMI SERVER:public class PayrollImpl extends UnicastRemoteObject implements Payroll

{

– RMI OVER IIOP SERVER:public class PayrollImpl extends PortableRemoteObject implements Payroll

{

20


– RMI REGISTRATION OF REMOTE OBJECT:String ro = "//localhost/money";

PayrollImpl p = new PayrollImpl();

Naming.rebind(ro, p);

– RMI OVER IIOP REGISTRATION OF REMOTE OBJECT:

String ro = "money";

PayrollImpl p = new PayrollImpl();

Context initialNamingContext=new InitialContext();

initialNamingContext.rebind(ro, p);

– RMI CLIENT IMPORT STATEMENTS: import java.rmi.*;

import java.rmi.registry.*;

21


– RMI OVER IIOP IMPORT STATEMENTS:import java.rmi.RemoteException;

import java.rmi.NotBoundException;

import javax.rmi.*;

import javax.naming.NamingException;

import javax.naming.InitialContext;

import javax.naming.Context;

– RMI CLIENT REGISTRY LOOKUP:

Payroll p = (Payroll)Naming.lookup("rmi://localhost:1099/money");

– RMI OVER IIOP CLIENT REGISTRY LOOKUP:

Context ic = new InitialContext();

Object objref = ic.lookup("money");

Payroll p= (Payroll) PortableRemoteObject.narrow(objref,Payroll.class);

22


– RMI CLIENT INVOCATION OF REMOTE SERVICE:

double m = p.earnings(id,d);

– RMI OVER IIOP CLIENT INVOCATION OF REMOTE SERVICE:

double m = p.earnings(id,d);

23


• COMPILATION– RMI COMPILE INTERFACE:

>javac Payroll.java– RMI OVER IIOP COMPILE INTERFACE:

>javac Payroll.java – RMI COMPILE SERVER:

>javac PayrollImpl.java

>rmic –v1.2 PayrollImpl– RMI OVER IIOP COMPILE SERVER:

>javac PayrollImpl.java

>rmic –iiop PayrollImpl– RMI COMPILE CLIENT

>javac PayrollClient,java– RMI OVER IIOP COMPILE CLIENT:

>javac PayrollClient

24


• EXECUTION DIFFERENCES:– RMI START REGISTRY:

ON ITS OWN DOS WINDOW: >rmiregistry

– RMI OVER IIOP REGISTRY:

ON ITS OWN DOD WINDOW: >tnameserv –ORBInitialPort

– RMI START THE SERVER:

>java PayrollImpl

– RMI OVER IIOP START THE SERVER

java -Djava.naming.factory.initial = com.sun.jndi.cosnaming.CNCtxFactory -Djava.naming.provider.url=iiop://localhost:900 PayrollImpl

//Assumes that the naming service was started at default port 900.25


– RMI START CLIENT:

>java PayrollClient

– RMI OVER IIOP START CLIENT:

java -Djava.naming.factory.initial = com.sun.jndi.cosnaming.CNCtxFactory

-Djava.naming.provider.url=iiop://localhost:900 PayrollClient

26

Placement Of Files

• IIOP SERVER:

Payroll.class ( the interface file)

PayrollImpl.class (the server file)

_PayrollImpl_Tie.class (tie file)

• IIOP CLIENT:

PayrollClient.class (client application)


PayrollImpl_stub.class (the stub file).

27

Placement Of Files

• Notice that in case of Callback from the server to the client additional files are needed:

• The client acts a server also. Therefore it will have to be compiled with the iiop version of rmic compiler to generate a stub and a tie file for the client as if it were a server.

• IIOP SERVER:


PayrollImpl.class (the server file)

_PayrollImpl_Tie.class (tie file of server)

PayrollMessage.class (the interface file of the client)

PayrollImplClient_stub.class (the stub class of the client)28

Placement Of Files

• IIOP CLIENT:

PayrollClientImpl.class (client application)


PayrollImpl_stub.class (the stub file of the server).

PayrollMessage.class (the interface file of the client)

PayrollClientImpl_Tie.class (the tie file of the client)

29

Placement Of Files

• A SIMILAR ARRANGEMENT OF FILES IS REQUIRED IF THE CALLBACK TECHIQUE WAS USED WITH A RMI ARCHITECTURE.

• THE CLIENT IS ALSO A SERVER AND THEREFORE IT GENERATES ITS OWN STUB AND INTERFACE FILES WHICH HAVE TO BE COPIED ON THE SERVER SIDE.

30

CORBA

• CORBA is a specification. Vendors can implement it.– CORBA stands for Common Object Request

Broker Architecture.– It is also used for creating a distribute dsystem

of nodes that offer services.– Java has an implementation of CORBA as part

of the Standard Edition of the jdk (The API is called Java IDL)

31

CORBA

• Using CORBA is more complex than RMI or RMI over IIOP.

• It requires the knowledge of another language called IDL (Interface Definition Language)

• IDL acts as the intermediary between services in various nodes, written in different languages.

32

COMPARING CORBA TO RMI AND RMI OVER IIOP

• Keep in mind that in the case of RMI over IIOP IDL interfaces are generated automatically by the compiler (the programmer does not need IDL to use RMI over IIOP).

• Also, in both RMI and RMI over IIOP Java’ s serialization protocol is used automatically to serialize objects that need to be part of the request/response packets. Serialization may have to be externalize din CORBA (created).

33


• Network connections are done by the RMI or RMI over IIOP Frameworks (run time systems). In CORBA explicit programming for the sockets is needed.

• The big advantage of CORBA is that CORBA objects can interoperate with objects on other platforms. Thus– A Java client can work with a C++ server and vice

versa for example.

34


• RMI only allows Java to Java communications (both the client and the server have to be written in Java)

• RMI over IIOP allows interoperability between different languages for the Client and the Server because of the IIOP transport protocol included in RMI over IIOP – IIPO stands for Inter Operable Internet Protocol

Object35

CORBA AND IDL

• The first step in developing a CORBA application is to define the interfaces to the objects required in your distributed system. To define these interfaces, you use CORBA IDL.

• You can implement IDL interfaces using any programming language for which an IDL mapping is available.

• Java has specifications that specify a IDL to Java and A Java to IDL data types translation.

36

CORBA AND ORB

37

CORBA and ORB

• In distributed computing, an object request broker (ORB) is a piece of middleware software that allows programmers to make program calls from one computer to another via a network.

• ORBs promote interoperability of distributed object systems because they enable users to build systems by piecing together objects- from different vendors- that communicate with each other via the ORB.

38

CORBA and ORB

39

CORBA and ORB

• Object Services -- These are domain-independent interfaces that are used by many distributed object programs. For example, a service providing for the discovery of other available services is almost always necessary regardless of the application domain.

40

CORBA and ORB

• Common Facilities -- Like Object Service interfaces, these interfaces are also horizontally-oriented, but unlike Object Services they are oriented towards end-user applications. An example of such a facility is the Distributed Document Component Facility (DDCF), a compound document Common Facility based on OpenDoc. DDCF allows for the presentation and interchange of objects based on a document model, for example, facilitating the linking of a spreadsheet object into a report document.

41

CORBA and ORB

• Domain Interfaces -- These interfaces fill roles similar to Object Services and Common Facilities but are oriented towards specific application domains. For example, one of the first OMG RFPs issued for Domain Interfaces is for Product Data Management (PDM) Enablers for the manufacturing domain. Other OMG RFPs will soon be issued in the telecommunications, medical, and financial domains.

42

CORBA and ORB

• Application Interfaces - These are interfaces developed specifically for a given application. Because they are application-specific, and because the OMG does not develop applications (only specifications), these interfaces are not standardized. However, if over time it appears that certain broadly useful services emerge out of a particular application domain, they might become candidates for future OMG standardization.

43

CORBA and ORB

44

Study Guide

• Read RMI over IIOP examples from the course’s web site.

45

Documents

1 Lecture 11 George Koutsogiannakis / Summer 2011 CS441 CURRENT TOPICS IN PROGRAMMING LANGUAGES