J2EE Technologies and Distributed Multi-Tiered Application Development

1. J2EE Technologies and Distributed Multi-Tiered Application Development Presented by Steven Reagan, Jijun Lu, Marwan Sleiman, Wangang Xie Semester Project CSE333 – Distributed Component Systems (Spring 2004) Instructor Prof. Steven A. Demurjian Department of Computer Science and Engineering University of Connecticut Steven.Reagan@uconn.edu Jijun.Lu@uconn.edu marwan@engr.uconn.edu xiewg@engr.uconn.edu

2. Organization of presentation • Introduction and Motivation (Marwan) • Java Sockets (Marwan) • Middle-tier architecture (Steven) • Java Servlets (Steven) • Java Message Service (JMS) (Jijun) • Java Database Connectivity (Wangang) • Comparison of the four methods (Wangang) • Conclusion

3. Introduction • Java is widely used in academia as well as in industry. • Developers are more concerned about the speed & security of their applications as they are deployed over the internet, J2EE provides the necessary tools and technologies to facilitate their work. • The J2EE platform offers a multi-tiered distributed application model. • We will present J2EE as a multi-tier solution for applications. A database application will be studied. • Different alternatives in our prototype will be compared.

4. Why J2EE? • Java is free. • Java is portable: Platform independent and enables compressible executable jar files. • Java is reusable: using past code in current problems is time saving. • J2EE has powerful technologies: • Java Server Pages (JSPs) • Java Servlet • JDBC • Enterprise JavaBeans (EJBs) • Java Messaging Server (JMS) • Java Secure Socket Extension (JSSE)

5. Motivation – Why Multi-Tier? Benefits of Multi-Tier Deployment. • Portable and platform independent. • Better flexibility for scaling-up and scaling-out. • Lower deployment cost on a controlled server than deploying software on all the user terminals. • Possibility of securing deployments using firewalls and/or secure connections. • Easier to troubleshoot and localize errors. • Filters overload (undesired traffic) from the clients on the servers. • Filters abnormal access to the server.

6. Our Prototype architecture Direct JDBC Middle Tier HTTP Server Sockets JDBC HTTP JDBC Database Servlet JMS JDBC JMS Client (Application/Browser) J2EE Middle Tier

7. Organization of presentation • Introduction and Motivation (Marwan) • Java Sockets (Marwan) • Middle-tier architecture (Steven) • Java Servlets (Steven) • Java Message Service (JMS) (Jijun) • Java Database Connectivity (Wangang) • Comparison of the four methods (Wangang) • Conclusion

8. Sockets (API) host or server host or server process process socket socket TCP with buffers, variables TCP with buffers, variables • A socket is an interface between app layer and transport layer • process sends/receives messages to/from its socket • socket analogous to door • sending process shoves message out door • sending process assumes transport infrastructure on other side of door which brings message to socket at receiving process controlled by app developer Internet controlled by OS • API: (1) choice of transport protocol; (2) ability to implement encryption.

9. The Socket Technology • We implemented the socket programming with TCP because it is connection oriented and provides a reliable point-to-point communication channel that client-server applications can use to communicate with each other. • TCP socket connections are setup in the following way: • A server has a server socket, bound to a specific port number to listen for any client willing to make a connection. • Knowing the hostname and port number, the client sends a connection request to the server. • The server accepts the connection and gets a new socket bound to a new port. • A socket is created on the client and communication begins.

10. Patterns - Tiers • Client Tier Requests different sizes of files from the database ( 1k to 8M ) Contains TCP Client Socket Connects with the middle-tier Communicates the database request and result via HashMap over the Socket Calculates the response time for each file request • Middle – Tier Contains the Server Socket Gets the database command from the Client Socket Connects to the MySQL databse server. Returns the SQL results to the client. Handles multiple Client connection by using multithreading. • Database Tier Contains the MySQL server.

11. Experiments done • Different sizes of database files: 1k to 8M • Different numbers of clients.

12. Graph: Average Response Time (ms)

13. Evaluation of the results. • We remark that, for small file sizes (1k to 8k), the response time decreases as the file size increases. This unusual behavior is the result of the overhead of the initial handshaking when the connection is established. • System limitations on the middle-tier/server sides caused the program to crash: • A typical Dell workstation (P4, 2.6 GHz, 1GB RAM) was unable to support more than 30 concurrent socket connections. • As we increased the memory size of the machines used, bigger files we exchanged without memory overflow.

14. Socket Security consideration • JSSE provides us with SSLSocket , and SSLServer Socket classes, which are extensions to the classical Socket , and Server Socket.They add a layer of security protections over the underlying TCP network transport protocol. • Those protections include: • Integrity Protection. SSL protects against modification of messages by intruders. • Authentication. In most modes, SSL provides peer authentication. • Confidentiality (Privacy Protection). In most modes, SSL encrypts the data sent between client and server.

15. Socket Security consideration • SSL protocol overview: TCP/IP Protocol Stack With SSL TCP/IP Layer Protocol Application Layer      HTTP, NNTP, Telnet, FTP, etc. Secure Sockets Layer      SSL Transport Layer TCP Internet Layer IP • The SSL Process/Handshaking: • Negotiate the cipher suite. • Authenticate identity (optional). • Establish information security by agreeing on encryption mechanisms

16. Organization of presentation • Introduction and Motivation (Marwan). • Java Sockets (Marwan). • Middle-tier architecture (Steven) • Java Servlets (Steven). • Java Message Service (JMS) (Jijun). • Java Database Connectivity (Wangang). • Comparison of the four methods (Wangang). • Conclusion.

17. Middle Tier Communication • A Middle Tier Application defines a public API accessible to all Clients. • A Client application remotely access any available public method. The Client must be able communicate: • The remote method to invoke. • The arguments for the remote method. • The return value(s) expected. • Thus, we need an interface to facilitate this notion of remote method invocation. • RMI does this already! However, it is typically only used for communication between standalone client and server applications. • Separate plugin required for each client to communicate with a Servlet Middle Tier.

18. Middle Tier Communication (cont’d) • We established a simple interface for Client/Middle Tier communication. • Used for each Middle Tier implementation for consistency. • A Table (Object) is always transmitted between the Client and Middle Tier Applications. • Client to Middle Tier • Table Contains: • String – Remote Method Name. • Object[] – Remote Method Parameters. • Middle Tier to Client • Table Contains: • Object – Return Value. • Exception – Any Exception thrown by the Middle Tier or Remote Method. • Method Invoked using the Java Reflection API: • Method method = this.getClass().getDeclaredMethod(name, types); • Object result = method.invoke(this, args);

19. Middle Tier Communication (cont’d) • A consistent model has been chosen for our Middle Tier architecture. Conceptually, each implementation consists of four files. • Client Side: • Client.java – Test Program. • Constant for each implementation (Does not change). • Database.java – “Artificial Database”. • Appears to Client programmers as the Database. • Handles communication to and from the Middle Tier. • Specific for each Middle Tier choice (Sockets, HTTP). • Server Side: • MiddleTier.java – Middle Tier Application. • Handles communication from and to the Client. • Specific for each implementation. • Database.java – JDBC Wrapper. • Constant for each implementation (Does not change).

20. Middle Tier Communication (cont’d) Client.java Database db = new Database(); File = db.getFile(“filename”); Database.java … public void addFile(String filename, byte[] data) throws SQLException { … } Public File getFile(String filename) throws SQLException { table.put(“name”, “getFile”); table.put(“args”, new Object[] {filename}); sendRequestToMiddleTier(table); } Client Side MiddleTier.java … public requestMade(Table table) { Method method = this.getClass().getDeclaredMethod(table.get(“name”), table.get(“argTypes”); Object result = method.invoke(this, args); sendResponse(result); } public File getFile(String filename) throws SQLException { return database.getFile(filename); } Server Side Database.java … public File getFile(String filename) throws SQLException { PreparedStatement ps = connection.prepareStatemnt(“SELECT Data FROM file WHERE Name = ?”); … return file; }

21. Organization of presentation • Introduction and Motivation (Marwan) • Java Sockets (Marwan). • Middle-tier architecture (Steven) • Java Servlets (Steven) • Java Message Service (JMS) (Jijun) • Java Database Connectivity (Wangang) • Comparison of the four methods (Wangang) • Conclusion

22. Servlets • Java program that runs within a web server (Apache Tomcat, Sun One Server, JBoss, …) • Typically small in size. • Receive/Respond to requests made from web clients over HTTP (Hyper Text Transfer Protocol). • Dynamic User-Oriented Content. • Server-Side. • Middle Tier Solutions. • Many benefits.

23. Servlet (cont’d) • Four Methods Commonly Implemented. • doGet – HTTP GET. • doPost – HTTP Post. • init – Beginning of Servlet Life Cycle. • destroy – End of Servlet Life Cycle. • Life Cycle • Controlled by the web container where the Servlet was deployed. • Upon request the following steps are performed: • 1. If the Servlet instance does not exists, the web container: • Loads the Servlet class and creates an instance.. • Initializes the Servlet (init method). • 2. Invokes the service method passing in request/response objects. • If the web container needs to remove the Servlet, the Servlet’s destroy method is called.

24. Dynamic Content • Earliest Attempts: • Applets: • Focused on Client platform for dynamic experience. • Advantages: • Rich User Interfaces. • Disadvantages: • Must be downloaded by the Client. • Slow! • CGI scripts: • Dynamic Content generated on Server Side. • Advantages: • May be written in many languages (C, C++, Perl, …) • Faster than applets (Server Side). • Disadvantages: • Platform Dependence.

25. Dynamic Content (cont’d) • Benefits of the Servlet: • Portable. • Run on any J2EE supported Server. • Simplified Deployment. • Standard Packaging. • Single Web Application Archive (WAR) file. • Fast. • Server Side. • Servlet instances persist across client requests. • No need for the Server to constantly be spawning new processes.

26. Example Todays Date: protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException { response.setContentType("text/html"); PrintWriter out = response.getWriter(); out.println("Todays Date: " + new Date() + "<br>"); }

27. Middle Tier • By definition, a Middle Tier Implements a request/response programming model. • Servlets fit the request/response paradigm! • Natural choice for web service developers. • Requests and Responses are made over HTTP. • Any Serializeable object may be sent or received via HTTP. • Thus, any Client or Web Service that can communicate over HTTP may access a Middle Tier’s set of API methods. • Java Desktop Applications. • HTML documents. • Java Web Services.

28. Middle Tier (cont’d) Client (Browser) HTTP Client (Application) JDBC HTTP JavaServlet Database Web Service HTTP

29. Middle Tier (cont’d) • Benefits: • Servlet is a Java Program written in the Java Programming language. • Access to entire set of Java APIs. • Portable (Write Once Run Anywhere). • Java VM manages Servlets. • Little Concern about Memory Leaks or Garbage Collection. • Resource pooling (Database connections). • Simplified Deployment. • Run on any J2EE enable web server. • Standard Packaging. • Single Web Application Archive (WAR) file. • Servlet instances can persist Across multiple clients. • Minimal external processes.

30. Performance • Three Tier Architecture: • Tier 1: Client Tier. • Tier 2: Servlet Middle Tier. • Tier 3: Database Backend. • Request Response Times: • Single Client. • Retrieval of files ranging from 1k to 8M. • Multiple Clients. • Retrieval of files ranging from 1k to 8M. Client (Application) HTTP JDBC JavaServlet Database Tier 1 Tier 2 Tier 3

31. Performance (cont’d) • Average Response Times: One Client Five Clients Ten Clients Twenty Clients Thirty Clients

32. Performance (cont’d) • Average Response Times:

33. Organization of presentation • Introduction and Motivation (Marwan) • Java Sockets (Marwan) • Middle-tier architecture (Steven) • Java Servlets (Steven) • Java Message Service (JMS) (Jijun) • Java Database Connectivity (Wangang) • Comparison of the four methods (Wangang) • Conclusion

34. Java Message Service(JMS) • A specification that describes a common way for Java programs to create, send, receive and read distributed enterprise messages • loosely coupled communication • Asynchronous messaging • Reliable delivery • A message is guaranteed to be delivered once and only once. • Outside the specification • Security services • Management services

35. A JMS Application • JMS Clients • Java programs that send/receive messages • Messages • Administered Objects • preconfigured JMS objects created by an admin for the use of clients • ConnectionFactory, Destination (queue or topic) • JMS Provider • messaging system that implements JMS and administrative functionality • SunONE (SUN) • WebSphere (IBM) • WebLogic (BEA)

36. A JMS Application (cont’d) Administrative Tool Bind JNDI Namespace Lookup JMS Provider JMS Client Logical Connection

37. JMS Messaging Domains • Point-to-Point (PTP) • built around the concept of message queues • each message has only one consumer Msg Msg consumes Client1 Client2 Queue sends acknowledges

38. JMS Messaging Domains • Publish-Subscribe systems • uses a “topic” to send and receive messages • each message has multiple consumers subscribes Topic Client2 Msg Client1 delivers publishes subscribes Client3 delivers

39. JMS API Programming Model Connection Factory creates Connection Message Producer Message Consumer creates creates Session receives from sends to creates Destination Destination Msg

40. Producer Sample • Setting up connections and sessions // Obtain a JNDI connection InitialContext jndiContext=new InitialContext(); //look up for the connection factory ConnectionFactory cf=jndiContext.lookup(connectionfactoryname); //create a connection Connection connection=cf.createConnection(); //create a session Session session=connection.createSession(false,Session.AUTO_ACKNOWLEDGE); //create a destination object Destination dest1=(Queue) jndiContext.lookup(“/jms/myQueue”); //for PointToPoint Destination dest2=(Topic)jndiContext.lookup(“/jms/myTopic”); //for publish-subscribe

41. Producer Sample (cont’d) • Creating producer MessageProducer producer=session.createProducer(dest1); • Send a message Message m=session.createTextMessage(); m.setText(“just another message”); producer.send(m); • Closing the connection connection.close();

42. Consumer Sample (Asynchronous) • Setup the connection, create a session • Create consumer • Registering the listener // registering the listener MessageListener listener=new myListener(); consumer.setMessageListener(listener); • myListener should have onMessage() // onMessage() method public void onMessage(Message msg){ // read the massage and do something // see next slides }

43. Listener Example public void onMessage(Message message) { TextMessage msg = null; try { if (message instanceof TextMessage) { msg = (TextMessage) message; System.out.println("Reading message: " + msg.getText()); } else { System.out.println("Message of wrong type: " + message.getClass().getName()); } } catch (JMSException e) { System.out.println("JMSException in onMessage(): " + e.toString()); } catch (Throwable t) { System.out.println("Exception in onMessage():" + t.getMessage()); } }

44. JMS in Our Application • Three Tier Architecture: • Tier 1: JMS Client Tier. • Tier 2: JMS Middle Tier. • Tier 3: Database Backend. • In our project, we do not enable multi clients. • No “multi thread support” in this JMS middle tier. JMS Messaging JMS Middle Tier JDBC Database Tier 1 Tier 2 Tier 3

45. Performance • Average Response Times (for one client): One Client

46. Performance (cont’d) • Average Response Times:

47. Performance (cont’d) • Pros: • Loosely coupled • Asynchronous • Reliable • Scalable • Cons: • JMS is complicated: management, server monitoring, and security issues • Differences exist between various implementations.

48. Organization of presentation • Introduction and Motivation (Marwan) • Java Sockets (Marwan) • Middle-tier architecture (Steven) • Java Servlets (Steven) • Java Message Service (JMS) (Jijun) • Java Database Connectivity (Wangang) • Comparison of the four methods (Wangang) • Conclusion

49. JDBC- Java Database Connectivity • A Java API for connecting programs written in Java to relational databases • Data Access Interface • Access many data sources • Database access • Spreadsheets • Flat Files • Performs common task like • Connection pooling • Batch updates • Transaction management

50. JDBC- Java Database Connectivity • General steps: • Importing Packages • Registering the JDBC drivers • Opening a Connection to a Database • Creating a Statement Object • Executing a Query and Returning a Results Set Object • Processing the Result Set • Closing the Result Set and Statement Objects • Closing the Connection