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_at_uconn.edu Jijun.Lu_at_uconn.edu marwan_at_
engr.uconn.edu xiewg_at_engr.uconn.edu
2
Organization of presentation

1. Introduction and Motivation (Marwan)
2. Java Sockets (Marwan)
3. Middle-tier architecture (Steven)
4. Java Servlets (Steven)
5. Java Message Service (JMS) (Jijun)
6. Java Database Connectivity (Wangang)
7. Comparison of the four methods (Wangang)
8. 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
JDBC
Sockets
HTTP
JDBC
Database
Servlet
JMS
JDBC
JMS
Client (Application/Browser)
J2EE Middle Tier
7
Organization of presentation

1. Introduction and Motivation (Marwan)
2. Java Sockets (Marwan)
3. Middle-tier architecture (Steven)
4. Java Servlets (Steven)
5. Java Message Service (JMS) (Jijun)
6. Java Database Connectivity (Wangang)
7. Comparison of the four methods (Wangang)
8. Conclusion

8
Sockets (API)

• 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.

Data 1 Client 5 Clients 10 Clients 20 Clients 30 Clients
1K 141 251 254 224 320
2K 120 151 129 149 142
8K 191 140 132 157 151
16K 190 179 135 168 143
32K 201 188 138 176 170
256K 240 244 267 341 200
512K, 262 481 570 661 649
1M 400 790 895 1443 2121
4M 971 2914 4481 7172 9563
8M 1682 5320 5876 Out of Memory Out of Memory
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

1. Introduction and Motivation (Marwan).
2. Java Sockets (Marwan).
3. Middle-tier architecture (Steven)
4. Java Servlets (Steven).
5. Java Message Service (JMS) (Jijun).
6. Java Database Connectivity (Wangang).
7. Comparison of the four methods (Wangang).
8. 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 (contd)

• 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 (contd)

• 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 (contd)
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.g
et(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

1. Introduction and Motivation (Marwan)
2. Java Sockets (Marwan).
3. Middle-tier architecture (Steven)
4. Java Servlets (Steven)
5. Java Message Service (JMS) (Jijun)
6. Java Database Connectivity (Wangang)
7. Comparison of the four methods (Wangang)
8. 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 (contd)

• 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 Servlets 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 (contd)

• 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()
"ltbrgt")
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 Tiers
  set of API methods.
• Java Desktop Applications.
• HTML documents.
• Java Web Services.

28
Middle Tier (contd)
Client (Browser)
HTTP
Client (Application)
JDBC
HTTP
Database
Java Servlet
Web Service
HTTP
29
Middle Tier (contd)

• 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
Database
Java Servlet
Tier 1
Tier 2
Tier 3
31
Performance (contd)

• Average Response Times

One Client
Five Clients
Ten Clients
Twenty Clients
Thirty Clients
32
Performance (contd)

• Average Response Times

33
Organization of presentation

1. Introduction and Motivation (Marwan)
2. Java Sockets (Marwan)
3. Middle-tier architecture (Steven)
4. Java Servlets (Steven)
5. Java Message Service (JMS) (Jijun)
6. Java Database Connectivity (Wangang)
7. Comparison of the four methods (Wangang)
8. 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 (contd)
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
Client2
Topic
Msg
Client1
delivers
publishes
subscribes
Client3
delivers
39
JMS API Programming Model
Connection Factory
creates
Connection
Message Consumer
Message Producer
creates
creates
Session
receives from
sends to
creates
Destination
Destination
Msg
40
Producer Sample

• Setting up connections and sessions
• // Obtain a JNDI connection
• InitialContext jndiContextnew InitialContext()
• //look up for the connection factory
• ConnectionFactory cfjndiContext.lookup(connection
  factoryname)
• //create a connection
• Connection connectioncf.createConnection()
• //create a session
• Session sessionconnection.createSession(false,Ses
  sion.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 (contd)

• Creating producer
• MessageProducer producersession.createProducer(d
  est1)
• Send a message
• Message msession.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 listenernew 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 (contd)

• Average Response Times

47
Performance (contd)

• 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

1. Introduction and Motivation (Marwan)
2. Java Sockets (Marwan)
3. Middle-tier architecture (Steven)
4. Java Servlets (Steven)
5. Java Message Service (JMS) (Jijun)
6. Java Database Connectivity (Wangang)
7. Comparison of the four methods (Wangang)
8. 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

51

JDBC-Architecture

• Two-tier architecture
• The top level visible to application programs
• The lower level consists of drivers for
  individual engines

52
JDBC- Classes and Interface
Connection
createStatement
prepareCall
prepareStatement
subclasses
subclasses
CallableStatement
PreparedStatement
Statement
Input/Output of CallableStatement
Input to PreparedStatement
Data types
getMoreResults / getResultSet
executeQuery
executeQuery
executeQuery
getXXX
ResultSet
53

JDBC Connect with MySQL

• MySQL Connector/J an implementation of JDBC 3.0
  API for the MySQL relational database server
• public class Connect
• public static void main (String args)
  
• Connection conn null 
• try
• String userName "testuser"
• String password "testpass"
• String url "jdbcmysql//localho
  st/test"
• Class.forName ("com.mysql.jdbc.Dri
  ver").newInstance ()
• conn DriverManager.getConnection
  (url, userName, password)
• System.out.println ("Database
  connection established")
• catch (Exception e)
• System.err.println ("Cannot
  connect to database server")
• finally
• if (conn ! null)
• try

54
JDBC Connect with MySQL

• Response time

55
JDBC Connect with MySQL

• Response time

56
JDBC- Security consideration

• JDBC and untrusted applets
• assume that normal unsigned applets are
  untrustworthy
• not allow untrusted applets access to local
  database data
• avoid making use of local credentials when
  connecting to remote database servers
• JDBC and Java applications
• driver should only be used with code loaded from
  that same source
• Network security
• the network protocols used for database access
  fixed by the DBMS vendor or connectivity vendor
• Security Responsibilities of Drivers
• Sharing TCP connections
• Check all local file access

57
Organization of presentation

1. Introduction and Motivation (Marwan)
2. Java Sockets (Marwan)
3. Middle-tier architecture (Steven)
4. Java Servlets (Steven)
5. Java Message Service (JMS) (Jijun)
6. Java Database Connectivity (Wangang)
7. Comparison of the four methods (Wangang)
8. Conclusion

58
Comparison of the four methods

• Speed
• Naturally, the exclusion of a Middle Tier results
  in
• faster request/response times.
• Ease of programming
• Addition of a Middle Tier means a more
  complicated
• design and evolving issues
• A Server program or web server must be deployed.
• New technologies must be learned (Servlet
  Programming, Socket Programming, Java Messaging).
• A Communication interface needs to be developed
  and tested.
• Security
• Allowing a Client direct access to a database
  puts the
• most critical resource (information) at risk.
• Passwords remain unencrypted in the clients
  program files.
• Available to any slightly skilled
  user/programmer.
• A Middle Tier Application hides data from the
  (un-
• trusted) Client users.

59
Performance

• Average Response Times

60
Performance

• Average Response Times

61
Performance

• Average Response Times

62
Performance

• Average Response Times

63
Performance

• Average Response Times

64
Organization of presentation

1. Introduction and Motivation (Marwan)
2. Java Sockets (Marwan)
3. Middle-tier architecture (Steven)
4. Java Servlets (Steven)
5. Java Message Service (JMS) (Jijun)
6. Java Database Connectivity (Wangang)
7. Comparison of the four methods (Wangang)
8. Conclusion

65
Conclusions

• Direct access to the database consistently yields
  faster request/response times.
• How important is Speed?
• How important is the Data Set?
• Remember, Middle Tier hides database from user.
• In practice, any Client to Database communication
  will be facilitated by a Middle Tier.
• Data almost always more important than the
  slightly better request/response times.
• It was expected that Socket communication would
  be faster than HTTP. because it operates at a
  lower level. However, results indicated
  otherwise. Reasons
• We use the TCP Socket, which is connection
  oriented and provides a reliable point-to-point
  communication channel. UDP communication would
  have been faster, however unreliable.
• In, Servlets, multithreading is done by J2EE,
  while in the socket method, we wrote the code by
  hand.

66
Conclusions (contd)

• JMS provide a loosely coupled communication with
  asynchronous and reliable messaging services.
• More complicated and costly.
• Time Money.
• Difficult to use in a system that is inherently
  synchronous.
• JMS messaging is more appropriate for Middle Tier
  to Component/Java Bean communication.
• Servlets hold a deployment advantage over JMS and
  Socket Servers.
• Web container is responsible for creating
  Servlet processes.
• Socket Server applications must be started and
  stopped manually.