Lecture 10

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

2. Topics • Java Server Pages. • Distributed Objects. • Frameworks for Distributed Objects Architectures. • Remote Method Invocation.

3. Java Server Pages (JSP) • Used when there is more non java code embedded than java code. Otherwise Servlets should be used (when the code is mostly java). • A JSP file contains some java code and some HTML or DHTML or XML code. • Therefore it is a mixture of scripts with Java code. • The file has a .jsp extension. • It is like script file. No compilation is needed.

4. Java Server Pages (JSP) • It is similar in concept to Microsoft’ s approach to ASP (Active Server Pages). • It is preferable for static content although it offers the dynamic capabilities of servlets.

5. Java Server Pages • A JSP page services requests as a servlet. • The web container translates the java code in the JSP file to servlet code and compiles it automatically. The first time the JSP file is called. • Any updates to the JSP file are recognized and the code gets recompiled. • The conversation to a servlet is called the Translation stage. • JSP files are located in the same directory level as HTML files and applets (under the root context folder). • Changes can be made in a JSP file like in a HTML file. It is not necessary to deploy and redeploy the application!! • To avoid the delay in having to update the corresponding servlet when changes are made we can pre-compile the JSP into a servlet outside the web container. • It can be done with a developing environment that supports this functionality

6. JSP TAGS • JSP uses different types of tags to encapsulate Java code: • Directive Tags: • 3 types of directive tags: page: used to define the attributes of the web application via keywords like: language, contentType, import include: used to specify an external file to be inserted. taglib: used to specify a custom tag library to be used. • <%@ % > is the symbol i.e. <%@ page language=“java” contentType=“text/html” %> or <%@ include file=“MyFile.html” %> or <%@ forward file=“MyFile.class” %> or <%@ taglib uri=“MyTagLib” %> or <%@ page import=“ java.util.Vector” import =“java.text.DecimalFormat” %>

7. JSP TAGS • Declaration Tags: used in expressions or scriptlets • <%! %> i.e. <%! int count; %> or <%! Date today=new Date(); %> • Expression Tags: used to specify Java expressions. • <%= %> <%= price*(1+taxRate) %> or <% ! today.getMonth() %> • Scriptlets: used to denote blocks general Java code. • <% %> <% total=0; for(int i=0; i<=myarray.length-1; i++) total+ = myarray[i]; %>

8. JSP TAGS • Actions:used to perform various functions that extend the standard capabilities of JSP i.e. using JavaBeans. • <jsp: useBean id=“manager” class=“staff.Personel” scope=“session” /> Notice the / . <jsp:plugin /> used to provide a browser specific markup for activating an applet. <jsp:setProperty /> used to set properties of a JavaBean <jsp:getProperty /> used to obatian a JavaBean’s property • Comments: used for commenting the code. • <% -- enter the comment -- %> (notice the two dashes after and before %)

9. JSP Implicit Objects • A number of Implicit Objects are made available by the server to the JSP file (regardless if they are used or not). • Implicit objects: • pageContext: provides access to other objects within the web application such as : • serveltContext: The servlets and JSP context object. • session: The session object for the client. • request: The request object that triggers the JSP file interpretation. • response: The response object returned by the JSP. • application: allows access to the servlet context by invoking getServletContext method • config: allows acess to getRervletConfig method.

10. JSP Implicit Objects • out: it represents the JspWriter object similar to obtaining the PrintWriter in servlets ( PrintWriter out=response.getPrintWriter in servlets--- you get this automatically in JSP). • There are other implicit objects that are explained in the Servlet/JSP API.

11. Unified Expression Language • A new feature was added in JSP to accommodate Java Server Faces (to be discussed later in the course). • EL is the unified expression language which is a union of the tags used by JSP and the tags understood by JSF (Java Server Faces). • JSP has a life cycle that is based on a request and response concept. • JSF features supports the UI component model MVC (Model View Controller) which allows: • Conversion and validation of component data. • Propagation of component data to objects. • Handling of component events. • Components can b e JavaBeans or Enterprise Java Beans. • JSF can present a client with its own custom presentation layer data.

12. Unified Expression Language • Unified EL supports: • Immediate evaluation of an expression: JSP engine evaluates the expression and returns the result immediately when the page is first rendered. Uses syntax ${ } • Deferred evaluation of an expression: JSP engines waits unto an event (s) take place before the final evaluation. Uses syntax #{ }

13. Example of Simple JSP • <html> <head> <title> Display Server Time</title> </head> <body> <p> Welcome to JSP: <% @ page import=“java.util.Calendar” %> <% Calendar now=Calendar.getInstance(); int hour=now.get(Calendar.HOUR_OF_DAY); int minute=now.get(Calendar.MINUTE); if(hour<12) out.println(“Good Morning the time is:” + “ ”+hour+ “ “ + minute); else out.println(“It is past noon”); %> </p> </body></html>

14. Example of Simple JSP • The previous script can be saved as some_name.jsp and be placed in the proper web application folder of the web server. • The JSP engine of the web server will separate the java code from the rest of the script, create a servlet out of that code and compile it.

15. Another JSP Example • In the following example we have a HTML table in some file i.e myjsp.jsp . In the cell <td> of the table we display the date and time. <table> <tr><td> <p> <% java.util.Locals locate=request.getLocale(); java.text.DateFormat.getDateTimeInstance(java.text.DateFormat.Long, java.text.DateFormat.Long, locals); %> // output the date <%>=dateFormat.format(new java.util.Date()) %> </p></td></tr>

16. JSP calling Other Resources • Notice that other resources can be called just like with servlets. • i.e You can have jsp code calling another jsp file or calling another servlet . • <jsp:forward> • It is an Action that calls another resource <jsp;forward page=“myanotherjsp.jsp”> <jsp:param name=“date” value=“<%=new java.util.Date() %>” /> </jsp:forward> Passes to resource myanotherjsp.jsp file the parameter name whose value is a Date object.

17. JSP calling Other Resources • Keep in mind that we can also use the <jsp: include> Action. • The difference between forward and include is the same as in servlets. • Forward has the called resource take over the response. Does not return to the calling jsp • Include transfers execution to the called resource and returns to the calling jsp to finish and form the response.

18. JSP Library files • In addition to the servlet library classes there are specific classes and interfaces libraries: • javax.servlet.jsp • javax.servlet.jsp.tagext • The above classes and their super classes can be used to generate custom tags

19. Custom Tag Libraries • The jsp API allows the creation of custom tags. • The functionality of the custom tags is defined in Java classes that implement interface Tag (package javax.servlet.jsp.tagext) • A custom tag will encapsulate some functionality that we want to make available to other programmers who possibly don’t know Java. They can use our tag in their scripts. • To create a custom tag we use more advanced concepts. We will return to it later on in the course.

20. Distributed Objects and RMI • In this section we want to introduce Remote Method Invocation and some other Java tools that allow the creation of Distributed Systems.

21. Distributed Objects • Distributed Systems: • A collection of independent computers that appears to its users as a single coherent system. • The computers are also called the nodes of the system. • Differences between the nodes are hidden from the user (i.e. different Operating Systems in each node, or different hardware architectures). • Notice that the services could had been written in different languages (each node used a different language to implement the service) • These systems are easy to expand by adding new nodes. • Each node can offer a different service to the user.

22. Distributed Objects • In a distributed objects system everything is treated as an object. • Services are accessible to clients via objects. • Distribution transparency is maintained by the fact that the user does not know where the object that represents the service is located. • Objects encapsulate data which is called the state of the object. • Objects have operations represented by methods that can be invoked by the object. • Operations (methods) are available via interfaces • The operations are defined in interfaces that have to be available to the clients.

23. Distributed Objects • Distributed Objects can be supported by languages such as C++, Java or other OOP languages. • A distributed object can be: • Persistent: this means that its state is independent of the server that executes the service that represents the object. Therefore its state (data) has been stored in a secondary storage area outside of its server. • Transient: this means that the state of the object exists only as long as the server that represents the object exists (is alive in a runtime state).

24. Example of Distributed Object • Assume that a client located in New York City wants to access Payroll and Employee services each located in servers in Chicago and Los Angeles respectively. Node B Node A Payroll service Client Node C Employee Service

25. Example of Distributed Object • In the previous slide Node A acted as a client requesting service (data) from Nodes B and C. • Node A, however, can be a node that offers a service to the other nodes also. • Therefore the concept of client and server is mixed. At some time later Node B could be requesting services from Nodes A and C. Thus node A is a client at that time while nodes A and C act as servers. • Remember that each service could had used a different programming language to implement itself.

26. Frameworks for Creating Distributed Objects Systems • Java has the following 4 Frameworks: • RMI (Remote Method Invocation) • It is available in Java SE. • Use its own proprietary transport protocol called RMIP • RMI over IIOP (RMI over Internet Inter Operability Protocol). • Its is available in Java SE. • An implementation of CORBA called Java IDL • It is available in Java SE • CORBA (Common Object Request Broker Architecture) is a specification that can be implemented by various vendors (languages) • JAVA Messaging Service API. • Available in Java EE

27. Remote Method Invocation (RMI) • 1.0 DEFINITION • THE REMOTE METHOD INVOCATION API ENABLES CLIENT AND SERVER COMMUNICATIONS OVER THE NET • RMI ALLOWS JAVA (ONLY) OBJECTS , RESIDING ON THE SAME OR DIFFERENT COMPUTERS ,TO COMMUNICATE WITH ONE ANOTHER VIA REMOTE METHOD CALLS OVER THE NETWORK. • THEREFORE ONLY JAVA TO JAVA COMMUNICATIONS ARE ALLOWED • RMI PROVIDES FOR TRANSFER OF OBJECTS VIA OBJECT SERIALIZATION. • SERIALIZATION ALLOWS OBJECTS TO CARRY ALL THEIR ATTRIBUTES (FIELDS) WITH THEM OVER THE NETWORK

28. Remote Method Invocation (RMI) • OBJECT SERIALIZATION IS USED TO SEND THE ARGUMENTS (PROPERTIES) OF A METHOD INVOCATION FROM THE CLIENT OBJECT TO THE REMOTE OBJECT • OBJECT SERIALIZATION IS ALSO USED TO RETURN THE VALUES FROM THE SERVER OBJECT BACK TO THE CLIENT OBJECT. • OBJECTS ARE CONVERTED INTO A STREAM OF BYTES THAT CAN BE TRASMITTED OVER THE NETWORK BY USING THE ObjectOutputStream CLASS. • OBJECTS ARE RECONSTRUCTED AFTER TRANSMISSION BY USING THE ObjectInputStream CLASS.

29. Remote Method Invocation (RMI) • THE SERIALIZATION USED BY RMI IS TRANSPARENT TO THE CLIENT AND SERVER OBJECTS. • APPLICATIONS USING TCP SOCKETS ARE RESPONSIBLE FOR SERIALIZING AND DESERIALIZING OBJECTS VIA INPUT AND OUTPUT STREAMS. • SECURITY IS AN ISSUE. • JAVA OFFERS SECURITY VIA THE SECURITY PACKAGE. • OPERATIONS THAT CAN BE INVOKED BY A REMOTE OBJECT ARE DEFINED IN AN INTERFACE • THE IMPLEMENTATION OF THE INTERFACE METHOD AT THE SERVER HAS TO IMPLEMENT THE SERIALIZABLE INTERFACE.

30. Remote Method Invocation (RMI) • LOCAL OBJECTS ARE OBJECTS THAT EXECUTE ON A PARTICULAR HOST. • REMOTE OBJECTSARE OBJECTS THAT EXECUTE ON ALL OTHER HOSTS. • REMOTE OBJECTS HAVE TO BE EXPORTED. • AN OBJECT EXPORTS ITSELF BY REGISTERING WITH A REMOTE REGISTRY SERVER. (ALSO REFERRED TO AS NAMING SERVICE) • A REMOTE OBJECT THEN CAN INVOKE THE SERVER THAT HAS IMPLEMENTED THE OPERATIONS FOR TH E OBJECT (WE WILL REFER IT SIMPLY AS THE SERVER APPLICATION) • RMI MAKES USE OF STUBS • A STUB IS A LOCAL OBJECT THAT ACTS AS A PROXY FOR A REMOTE OBJECT

31. Remote Method Invocation (RMI) • THE STUB PROVIDES THE SAME METHODS AS THE REMOTE OBJECT (THE METHODS THAT THE REMOTE OBJECT CAN OPERATE). • LOCAL METHODS INVOKE THE METHODS OF THE STUB AS IF THEY WERE METHODS OF THE REMOTE OBJECT.

32. Remote Method Invocation (RMI) • RMI AVOIDS THE NEED FOR PROGRAMMERS TO LEARN A SEPARATE IDL (INTERFACE DEFINITION LANGUAGE) SINCE ONLY JAVA TO JAVA COMMUNICATIONS ARE ALLOWED. • IDL IS A LANGUAGE USED AS A INTERMEDIARY DATA TYPES BETWEEN TWO DIFFERENT LANGUAGES WITH DIFFERENT DATA TYPES .

33. Server Access to remote object requested by name. Reference is returned. Client Object registry stub Object ‘s method is invoked Remote object implementation Remote Method Invocation (RMI) • HOW RMI WORKS Default port 1099 Remote object registers its name stub Messages Exchanged in RMI

34. Remote Method Invocation (RMI) • BEFORE THE CLIENT IS STARTED THE RMI REGISTRY HAS TO BE STARTED. • RMI REGISTRY IS A SERVER SIDE NAMING REPOSITORY THAT ALLOWS REMOTE CLIENTS TO GET A REFERENCE TO A REMOTE SERVER OBJECT. • ALSO THE SERVER PROGRAM HAS TO BE STARTED BEFORE THE CLIENT.

35. RMI Communications • The server application registers the remote object with the rmiregistry. • The client contacts the registry and requests information about the remote object. • The registry returns a reference to the remote object. That means that information is sent on: • IP address of server. • Port that the server uses for the service (server application). • An object ID number that this client can use. • The name of the service (method(s)) that can be invoked. • Other information. • Notice that the registry does not have to be on the same machine as the server application. • The registry listens on a default port 1099 that can be changed to a different port number.

36. RMI Communications • The client uses the information from the registry to send a request to the server to execute the service invoked by the object . • The client also sends information about itself such as its IP address and its port number. • The server executes the service and returns the data to the client. • Notice that sometimes no data is returned but the response packets are sent with other information anyway. • Sometimes the server sends as part of its response a request back to the client to execute a remote service that the client has. That is called callback. The server expects a response from the client.

37. RMI Communications • Communication Layers Client Server Client Application Server Application Stub (Presentation layer) Stub (Presentation layer) Remote Reference (Session Layer) Remote Reference (Session Layer) RMIP (Transport Layer) RMIP (Transport Layer) TCP/IP (Network Layer) TCP/IP (Network Layer)

38. Remote Method Invocation (RMI) • RMI IS IMPLEMENTED BY 5 PACKAGES: • java.rmi PROVIDES THE REMOTE INTERFACE, A CLASS FOR ACCESSING REMOTE OBJECTS AND SECURITY MANAGER FOR RMI. • Java.rmi.registry PROVIDES CLASSES AND INTERFACES THAT ARE USED BY THE REMOTE REGISTRY. • java.rmi.server PROVIDES CLASSES AND INTERFACES USED TO IMPLEMENT REMOTE OBJECTS AND STUBS AND TO SUPPORT RMI COMMUNICATIONS. • java.rmi.activation SUPPORTS PERSISTENT OBJECT REFERENCES AND REMOTE OBJECT ACTIVATION • java.rmi.dgc SUPPORTS RMI DISTRIBUTED GARBAGE COLLECTOR.

39. Remote Method Invocation (RMI) • The following steps are needed in order to implement an RMI distributed application: • Write the interface that defines the method(s) that can be invoked by the remote object. Compile it. • Write the server that implements the interface’ s method(s). Compile it using the rmic compiler and the regular compiler. The rmic compiler creates a stub. Notice that the server must extend UnicastRemoteObject and implement the interface. UnicastRemoteObject is the library class responsible for setting up all network communications under the hood (without the developer having to write any extra code for that) • Write the client program and compile it. • Place files as shown in the following diagram.

40. Remote Method Invocation (RMI) • Place files as shown. Client Node Server InterfaceFile.class ServerProgram.class stub ClientProgram.class InterfaceFile.class stub

41. Remote Method Invocation (RMI) • EXAMPLE OF AN RMI APPLICATION (TemperatureServerImpl) • LET US DEVELOP AN APPLICATION THAT WILL MONITOR THE WEATHER INFORMATION OVER THE INTERNET FROM THE WEATHER BUREAU’ S WEB SITE TWICE A DAY. • THE APPLICATION , FOR THE SHAKE OF THE PRESENTATION, WILL RUN LOCALLY (COPY THE PAGE Traveler.html --or an index.htl--OF THE WEATHER BUREAU’ S SITE TO THE ROOT CONTEXT DIRECTORY OF TOMCAT THAT YOU CREATED). • IT IS ASSUMED THAT WE HAVE A LOCAL NETWORK. THE SERVER GETS THE WEATHER INFORMATION FROM THE INTERNET AND THE CLIENTS OF THE LOCAL NETWORK CAN ACCESS THE INFORMATION FROM THE SERVER VIA REMOTE METHOD INVOCATION (NOTE: THE COD EFOR THIS EXAMPLE IS AVAILABLE ON THE COURSE’ S WEB SITE AS WELL AS OTHER RMI EXAMPLES).

42. //host:port/RemoteObjectName client internet Remote server Web server Aquire information from weather forecast site and store it Weather forecast site Info from server retrieved whenever client wishes rmi http Unicast (point-point) communications between objects via method calls. • Info is stored in an array of objects • Info is downloaded when • server program starts and gets repeated twice a day. Remote Method Invocation (RMI) • SUMMARY OF TEMPERATURESERVER EXAMPLE:

43. Remote Method Invocation (RMI) • IMPLEMENTING THE RMI APPLICATION • AT THE SERVER SIDE: • REMOTE OBJECTS ARE REFERENCED VIA INTERFACES. YOU CREATE AN INTERFACE FOR EACH OBJECT. • THE INTERFACE MUST BE PUBLIC AND MUST EXTEND INTERFACE Remote . • DEFINE THE REMOTE METHODS THAT YOU WANT TO INVOKE WITHIN THE INTERFACE. THE METHODS MUST THROW RemoteException . • IN OUR EXAMPLE THERE THE INTERFACE is: • public interface TemperatureServer extends Remote { public WeatherInfo [] getWeatherInfo() ; }

44. Remote Method Invocation(RMI) • The CLIENT will invoke method getWeatherInfo() which returns an array of objects type WeatherInfo. • Extending the interface Remote implies that our objects can be remotely accessed by any JVM that has network connection to the server and the appropriate stubs. • CREATE A CLASS THAT IMPLEMENTS THE INTERFACE (TemperatureServerImpl). Notice that by convention the server uses the name of the interface appended by Impl • THE CLASS EXTENDS UnicastRemoteObject CLASS (SUBCLASS OF RemoteServer CLASS). (public classTemperatureServerImpl extends UnicastRemoteObject implements TemperatureServer) • UnicastRemoteObject CLASS ALLOWS THE REMOTE OBJECT TO WAIT FOR A CLIENT CONNECTION ON AN ANONYMOUS PORT NUMBER.

45. Remote Method Invocation (RMI) • THE CLASS SHOULD HAVE A CONSTRUCTOR THAT CREATES , INITIALIZES THE REMOTE OBJECT • IT SHOULD IMPLEMENT ALL THE METHODS DEFINED IN THE REMOTE INTERFACE (public WeatherInfo[] getWeatherInfo () ) • IT SHOULD HAVE A main METHOD THAT CAN BE EXECUTED AS A REMOTE CLASS. • IT SHOULD REGISTER A NAME BY WHICH IT CAN BE REMOTELY REFERENCED WITH THE REMOTE REGISTRY. ( String serverObjectName= “//localhost/TempServer”; ) • THE NAME OF THE OBJECT USED BY THE MAIN SHOULD BE BOUND TO THE NAME USED BY THE CLIENT. ( Naming.rebind ( serverObjectName, temp) ). • WHERE temp IS AN INSTANCE OF THE SERVER (I.E. TemperatureServerImpl temp = new TemperatureServerIMpl();)

46. Remote Method Invocation (RMI) • CREATE A CLASS WeatherInfo that creates WeatherInfo objects. • USE rmic COMPILER TO CREATE A STUB AT THE SERVER AFTER YOU COMPILE THE SERVER WITH THE NORMAL javac COMPILER: • rmic -v1.2 TemperatureServerImpl. • THIS COMMAND GENERATED THE FILE TemperatureServerImp_stub.class • THE stub FILE MUST BE PRESENT IN BOTH THE SERVER DIRECTORY AND THE CLIENT DIRECTORY IF YOU ARE DOING THE EXAMPLE LOCALHOST.

47. Remote Method Invocation (RMI) • START THE REMOTE REGISTRY SERVER. THIS PROGRAM LISTENS ON THE DEFAULT PORT 1099 FOR INCOMING REQUESTS TO ACCESS NAMED OBJECTS. ON THE COMMAND WINDOW TYPE: • > start rmiregistry • LEAVE REGISTRY SERVER RUNNING AND MINIMIZE THE DOS WINDOW . • START THE SERVER. BOUND REMOTE SERVER OBJECT TO THE REGISTER. RUN THE COMPILED OBJECT IMPLEMENTATION CLASS ON ANOTHER DOS WINDOW • >java TemperatureServerImpl • This is a server and should be left running. Minimize the window.

48. Remote Method Invocation (RMI) • AT THE CLIENT • WRITE A CLIENT PROGRAM THAT WILL CALL THE REMOTE OBJECT ( THE IMPLEMENTATION OF THE INTERFACE). • THE IP ADDRESS OF THE MACHINE THAT THE REMOTE OBJECT RESIDES SHOULD BE USED (OR THE REMOTE HOST’S NAME). • Naming.lookup ( serverObjectName) IS USED TO INTERACT WITH THE RMI REGISTRY TO HELP THE CLIENT OBTAIN A REFERENCE TO THE REMOTE OBJECT. • A COPY OF THE INTERFACE STUB SHOULD BE COPIED TO THE SAME DIRECTORY AS THE CLIENT PROGRAM. • Start the client pr0gram by calling: • >java TemperatureClient

49. Remote Method Invocation (RMI) • CLASSES USED: SERVER CLIENT TemperatureServer.class TemperatureServerImpl.class WeatherInfo.class TemperatureServerImpl_Stub.class TemperatureClient.class TemperatureServer.class TemperatureServerImpl_Stub.class WeatherInfo.class Where TemperatureServer.class is the interface

50. STUDY GUIDE • WEB BASED APPLICATION DEVELOPMENT text Chapter 7 • Read examples on RMI posted on the course’ s web site.