Enterprise applications

Enterprise Applications
Functional requirements of enterprise applications often include extensive access to a varied array of data sources, and accessibility from a wide array of user interfaces.
Enterprise applications also usually have more demanding non-functional requirements including
Availability
Scalability
Security
Maintainability.

Availability – Refers to an application’s capability to process client requests. Enterprises collect and process information using a distributed environment consisting of clients and servers. Enterprise applications include server-based components that desire to provide constant availability to client requests.
Scalability – refers to the capability of an application to support a wide range of number of users. This includes effectively supporting just a handful of users to millions of users by merely changing the deployment environment.
Maintainability – involves the management of software complexity.
Security – Application servers restrict the free use of resourses (such as threads) and prevent an application from starving a server and preventing clients from accessing needed services.

JAVA2 Enterprise Edition (J2EE)
J2EE is a collection of several different technologies, each of which helps developers meet the requirements of enterprise applications.
Java2 Enterprise Edition IIOP/JRMP HTTP/HTTPS RMI JMS JTA Java 2 Servlets & JSP EJB JAAS JNDI JDBC J2EECA LDAP RDBMS EIS

The foundation starts with the standard Java2 environment. This provides a base environment that is cross-platform, and fully supports the Java2 language and features.
A set of technologies is added to this with each technology is composed of an application programming interface (API), and a contract for behavior.

J2EE Technologies
Each j2EE technology focuses on a set of functionality needed by server based applications. These technologies address the enterprise application demands of availability and scalability through the use of clustering.
Clustering is the configuration of multiple servers each identical in the service provided and enabling client access to the effectively distributed across many servers rather than one large server. This provides effective availability and scalability.
Application maintenance is enhanced by using object-oriented and component-based framework development. Also important to J2EE development is multi-tiered development and the separation of technologies.

Remote Method Invocation – (RMI) – RMI provides a way to access distributes Java objects running on a remote server on the network. It can use the Java Remote Method Protocol (JRMP), which supports RMI, or the Internet Inter-Orb protocol (IIOP), which supports both RMI and CORBA distributed method calls.
Java Database Connectivity (JDBC) – JDBC provides a Java based, standardized API for executing SQL-92 queries and statements on database servers from different vendors.
Java Naming and directory Interface (JNDI) – This provides a uniform and standardized Java-based naming and directory services interface for accessing various types of naming providers such as LDAP and DNS.
Java Authorisation and Authentication Services (JAAS) :- JAAS provides a uniform interface for managing enterprise-wide security.

Java Transaction API (JTA) :- JTA is a standard Java interface for supporting local and distributed transactions.
Java Management Extension (JMX) :- JMX is a framework for managing Java-based services supporting web and external tool integration.
Java Messaging Service (JMS) :- JMS is an interface that allows standardized access to Message Oriented Middleware servers that can provide asynchronous messaging, through reliable point-to-point and publish-and-subscribe messaging models.
Enterprise JavaBeans :- A container-based component model that allows for distributed and container managed Java components. A developer creates Java components, called beans, which are placed in an EJB server that provides life-cycle management and services to the bean, such as security, transaction, and object pooling.

Servlets and JSPs :- A model for container managed components that process client requests to a server. They are commonly used for handling HTTP and HTTPS web requests.
JavaMail and JavaBeans Activation Framework (JAF) :- An API that enables the sending of email from Java applicatios.
JAVAIDL :- An API that enables J2EE application components to invoke external CORBA objects via the IIOP protocol.
J2EE Connector Architecture (J2EECA) :-This is a standard Java-Based architecture for connecting transactional J2EE applications to existing Enterprise Information Systems.

Three Tiered Model
Enterprise applications are characterized by their distributed and scalable nature.
These applications encompass both client and server components, and include web applications and services.
The explosion of the Internet has led to the need to access and manage large amounts of information within these enterprise applications.
Meeting the requirements of modern enterprise application requires not only robust technologies but effective architectural patterns and recommended guidelines for most effectively these technologies.
This has identified the need to separate business logic from the technologies used within these applications.
Sun has provided a guideline for building J2EE applications called the J2EE Blueprint.
The blueprint organize enterprise applications into multiple tiers to manage the complexity.

The first tier includes enterprise information systems and databases.
Second tier includes the business logic and functionality required by the application sits above the base tier.
The third tier includes user interface consists of Java clients such as Java-Based applications or applets as well as web clients supported through servlets and JSPs.
These tiers separate the aspects of an enterprise application as well as the business logic so that each tier can change at its own rate while minimizing the change to the entire application.

JAVA SERVLET

Servlet
Servlet provide the best mechanism for J2EE applications to provide a web inferface.
A servlet can be thought of as a server-side applet. Servlets are loaded and executed by a web server in the same manner that applets are loaded and executed by a Web browser.
A servlet accepts requests from a client (via the web server), performs some task, and returns the results.

SERVLET WEB BROWSER WEB SERVER HTTP REQUEST HTTP RESPONSE

Flow when using Servlet
The client (most likely a Web Browser) makes a request via HTTP.
The web server receives the request and forwards it to the servlet. If the servlet has not yet been loaded, the Web server will load it into the JVM and execute it
The servlet will receive the HTTP request and perform some type of process.
The servlet will return a response back to the Web server.
The Web server will forward the response to the client.

Why use servlet?
Servlets are a great replacement for Common Gateway Interface (CGI) scripts. CGI scripts are typically written in Perl of C and are usually ties to a particular server platform. Since servlets are written in Java, they are immediately platform independent.
Servlets are fast. Since servlets only need to be loaded once, they offer much better performance over their CGI counterparts.
Servlets are platform independent.
Servlets are extensible. Java is robust, object-oriented programming language, which easily can be extended to suit your needs.

Why use servlet?
Servlets are secure. The only way to invoke a servlet from the outside world is through a Web server.
Servlets can be used with a variety of clients.

What do you need to write servlets?
JSDK – Java Servlets Development Kit.
Included in the JSDK is the Java servlet API, which is a standard Java extension API.
This means that while it is not part of the core Java framework (which must always be part of all products bearing the Java brand), it will be made available by vendors as add-on packages.
The servlet API is found in the javax.servlet package.

What do you need to run servlets?
All that is required to run servlet is a Java Web server that supports the servlet API.
Need some type of client application that invokes the servlet.

The Java Web Server
The Java Web Server is provided by java soft.
The Java Web Server is an implementation of the JavaServer architecture, which defines a generic server and service framework.

The JavaServer Architecture
The service Framework
The server Framework
The servlet Framework

The Service Framework-I SERVICE WEB SERVER REQUEST SERVER SOCKET JAVA SERVER HANDLER THREAD

The Service Framework-II
The service framework defines a set of interfaces for implementing services that interact with clients using multiple handler threads.
A service is defined as an implementation of an individual protocol, such as HTTP or FTP.
The core service classes provided by the JavaServer architecture include administration, thread management, connection management, session management, and security.

The Service Framework-III
When a service is initiated, it will acquire a specific server socket.
After acquiring a server socket, the service will create a pool of handler threads; each thread will sit idle waiting for a connection request.
Once a connection request has been received, a handler thread will perform all protocol interactions on that connection.

Server Framework
A server is one instance of a Java virtual machine.
One server can support multiple concurrent services, which are configured to start when the server process is initiated .
ADMINSTRATIVE SERVICE HTTP SERVICE WEB PROXY SERVICE SERVER SERVER SOCKET

The Servlet Framework-I ADMINISTRATIVE SERVICE HTTP SERVICE WEB PROXY SERVICE SERVLET SERVLET SERVLET SERVER SOCKET SERVER

The Servlet Framework-II
A servlet is a Java object that conforms to a specific interface, as defined by the JavaServer architecture.
Servlets are loaded and invoked by services, and a service can utilize multiple servlets.
You can think of servelts as an easy way to extend the functionality of a server either with internal servlets, which are provided with her server, or with user-written servlets, which function as add-ons.

Basic Flow of a servlet HTTP SERVICE FILE SERVLET INVOKER SERVLET USER SERVLET HTML FILE LOAD HTML PAGE HTML POST WEB BROWSER JAVA SERVER

How a web server handles HTTP Requests
The browser establishes a TCP/IP (Transmission Control Protocol / Internet Protocol) connection to the server represented by java.sun.com.
The browser sends a request message for the page represented by jsp/simplepage.html to the server.
The server sends a response message that includes either the text of that page or an error report.
The TCP/IP connection is closed.

Request Message Contents
The request message from browser to web server starts with one or more text lines terminated carriage return-line feed. The first line specifies a method, a uniform Resource Identifier (URL) and an indicator of the HTTP version being used.
The standard methods in the HTTP 1.1 protocol are Options, Get, Head, Post, Delete, Trace and Connect.

The GET method
The GET Method is used to request a resource, such as an HTML page.
A GET request can include some additional information appended to the URL string as a query string.
Server process this query string
Because of restrictions on the size of the request header that servers can handle, the total of URL and query string should be less than 240 characters.

The setContentType method sets the type of the response that will be sent to the browser.
The getWriter method returns a PrintWriter object named out so that we can output plain text.
The various calls to out.println send text creating the HTML page to the output stream.
The call out.close flushes the output stream buffer and then terminates the sending of the response.

Response Message Contents
The response message from web server to browser always starts with a status line composed of the protocol being used, a numeric status code and a text version of the status code.
The HttpServletResponse object takes care of creating theses lines, but the servlet has control over the values that are returned.
The response continues with the data that were written to the output stream by the servlet.

Post Method
When the method specified in a request is post, the request can contain any amount of information because it is sent as lines of text, and the URL contains only the name of the servlet to process the request.

Inner Working of a Servlet Engine
The servlet engine performs many tasks that greatly simplify the programmer’s job. Here are stages of the lifecycle of a servlet that uses the standard threading model:
Servlet instance creation
Instance initialization.
Request handling
Thread management
Other services
Instance destruction

Servlet instance creation :- The servlet engine loads the Java classes to create a servlet instance either when the engine is started, or when the first request for a particular servlet arrives. When this happens depends on settings for the particular servlet. Typically, the engine creates only a single copy of the servlet object and reuses the object for every request, even if more than one request is being processed at the same time.
Instance initialization :- The engine calls the servlet’s init() method. With this method, you would typically set up parameters that are going to be constant for the life of the servlet, such as paths to files or a pool of database connections.

Request handling :- Each request that an engine gets is handled by a separate Java Thread. The engine may create a new Thread, or it may assign one from a pool. The thread creates request and response objects and then calls the servlet’s service() method. The service method is responsible for deciding for how to handle the request.
Thread management :- Any number of threads may be executing the methods of an object at the same time, each with its own request and response objects.
Other services :- A typical service provided by an engine is session tracking. This provides a method by which your program can keep track of data belonging ti a particular user.

Instance destruction :- When the servlet engine needs to shut down completely, or just to recover memory, it calls the servlet’s destroy() method. At this point, the servlet can close files and otherwise shut down gracefully.

SERVLET CHAINING SERVLET 1 SERVLET 2 CHAINING HTTP REQUEST HTTP RESPONSE

Servlet Chaining
Similar to piping UNIX or DOS commands, you can chain multiple servlets together in a particular order.
The output from one servlet is passed as input to the next servlet in the chain; the output from the last servlet in the chain is returned to the browser.

Servlet Reloading
If you placed the properties servlet in the “<home>/servlet” directory where HOME is the home directory of the servlet engine) and had to make modifications to the servlet, the servlet was automatically reloaded.
This magical feature is called Servlet Reloading and is accomplished by a custom class loader implemented by the servlet engine.
Most Java class loaders will cache each class as it is loaded, as a performance enhancement; servlet engine class loaders do quite the opposite by checking the timestamp of the servlet for each request and performing a reload if it has changed.
It greatly decrease the time needed to develop and test a servlet engine, since you do not have to stop and start the servlet engine every a servlet is changed.

Servlet API package
The Java servlet library is elegantly simple, considering how much power it gives the programmer.

Javax.servlet package-I
The javax.servlet package contains a number of interface definition that provide the basic structure of the entire API.
Servlet- This interface defines the methods that all servlets must implement.
servletRequest :- All information about a client request is accessed through an object implementing this interface.
servletResponse:- An object implementing this interface must be created by the servlet engine and passed to the servlet’s service method to be used for output of the body to the client.

Javax.servlet package-II
Javax.servlet package has the following utility interface :-
Filer – to modify request before the request is sent to resources such as servlets or JSP pages.
FilerChain – Multiple filers can be chained together to perform different operations on a request or response.
FilerConfig – Provides initialization and configuration information for the filter.
RequestDispatcher – permits you to forward a request from the current servlet to another servlet.

Javax.servlet package-III
ServletConfig – used to hold information used during servlet initialization.
ServletContext – let a servlet locate information about the servlet engine it is running in and its web application, which is composed of the related servlets and JSP pages for this project.
ServletContextAttributeListener – A programmer would implement this interface in an object that needs to be notified when attributes are added, removed, or replaced from the ServletContext.
ServletThreadModel – It is a market that forces the servlet engine to ensure tha tonly one Thread executes an instance of the servlet at one time.

Javax.servlet package-IV
Javax.servlet package has the following classes :-
GenericServlet – Provides bare minimum functionality for any type of servlet.
ServletContextAttributeEvent – Event object passed to a ServletContextAttributeListener.
ServletInputStream – A class for reading a stream of binary data from the request.
ServletOutputStream – A class for writing a stream of binary data as part of a response.
ServletRequestWrapper – A subclass of ServletRequest that allows the wrapping of modified functionality around a servletRequest.
ServletResponseWrapper – A subclass of ServletResponse that allows the wrapping of modified functionality around a ServletReponse.

Javax.servlet package-V
Javax.servlet package has the following exceptions :-
ServletException – A general purpose exception used through out the servlet API.
UnavailableException – This exception is to be thrown when a servlet needs to indicate that it is temporarily or permanently unavailable.

SESSION TRACKING
HTTP is a “stateless” protocol: each time a client retrieves a Web page, the client opens a separate connection to the Web server and the server does not automatically maintain contextual information about the client.
Even with servers that support persistent (keep-alive) HTTP connections and keep sockets open for multiple client requests that occur in rapid succession, there is no built-in support for maintaining contextual information.
This lack of context causes a number of difficulties.
For example, when clients at an online store add an item to their shopping carts, how does the server know what’s already in the carts? Similarly, when clients decide to proceed to checkout, how can the server determine which previously created shopping carts are theirs?

SESSION TRACKING
There are three typical solutions to this problem:
Cookies
URL rewriting
hidden form fields.

Working with Cookies
Cookies were introduced by Netscape to store a limited amount of information on the user’s system so that it can be returned to the server in subsequent transactions.
The cookies mechanism will return cookie information to only the host that originated it, subject to various restrictions.
The javax.servlet.http.cookie API provides methods for setting and getting all these properties.
A cookie is always constructed with a name and value String and is then modified as necessary.

Properties of cookies
Version – Only two values are possible, version “0” is the original Netscape style, and version “1” is defined in RFC2109.
Domain – The domain controls the range of servers to which the cookie is sent.
Max-age- This numeric property should be used to avoid clogging up a browser with outdated information.
Path – This variable restricts the paths on the server to which the cookie is returned.
Secure – If the Secure attribute is present, the browser should send the cookie only if the communication channel is secure.
Name – All cookies must have a name.
Value – This is the text that is returned to the server.

URL Rewriting
With this approach, the client appends some extra data on the end of each URL.
That data identifies the session, and the server associates that identifier with user-specific data it has stored.
For example, with http://host/path/file.html;jsessionid=a1234, the session identifier is attached as jsessionid=a1234, so a1234 is the ID that uniquely identifies the table of data associated with that user.
URL rewriting is a moderately good solution for session tracking and even has the advantage that it works when browsers don’t support cookies or when the user has disabled them.

Hidden Form Fields
<INPUT TYPE="HIDDEN" NAME="session" VALUE="a1234">
This entry means that, when the form is submitted, the specified name and value are automatically included in the GET or POST data.
This hidden field can be used to store information about the session

Session Tracking in Servlets
Servlets provide an outstanding session-tracking solution: the HttpSession API.
This high-level interface is built on top of cookies or URL rewriting.
All servers are required to support session tracking with cookies, and most have a setting by which you can globally switch to URL rewriting.
Either way, the servlet author doesn’t need to bother with many of the implementation details, doesn’t have to explicitly manipulate cookies or information appended to the URL, and is automatically given a convenient place to store arbitrary objects that are associated with each session.

Session Tracking Basics
Using sessions in servlets is straightforward and involves four basic steps. Here is a summary; details follow.
Accessing the session object associated with the current request. Call request.getSession to get an HttpSession object, which is a simple hash table for storing user-specific data.
Looking up information associated with a session. Call getAttribute on the HttpSession object, cast the return value to the appropriate type, and check whether the result is null.
Storing information in a session. Use setAttribute with a key and a value.
Discarding session data. Call removeAttribute to discard a specific value. Call invalidate to discard an entire session. Call logout to log the client out of the Web server and invalidate all sessions associated with that user.

Networking

Networking Basics
A socket identifies an endpoint in a network.
Sockets are at the foundation of modern networking because a socket allows a single computer to serve many different clients at once, as well as to serve many different types of information.
This is accomplish through the port, which is a numbered socket on a particular machine.
A server process is said to “listen” to a port until a client connects to it.
A server is allowed to accept multiple clients connected to the same port number, although each session is unique.

Socket communication takes place via a protocol.
Internet protocol (IP) is a low-level routing protocol that breaks data into small packets and send them to an address across a network, which does not guarantee to deliver said packets to destination.
Transmission control protocol (TCP) is a higher-level protocol that managers to robustly string together these packets, sorting and retransmitting them as necessary to reliably transmit data.
User Datagram Protocol (UDP) – can be used directly to support fast, connectionless, unreliable transport of packets.

InetAddress
The InetAddress class is used to encapsulate both the numerical IP address and the domain name for that address.
You can interact with this clas by using the name of an IP host, which is more convenient and understandable that its IP address.
Commonly used InetAddress factory method is :-
Static InetAdress getLocalHost() throws UnknownHostException.

Inet4address and Inet6address
Inet4address represents a transitional-style IPv4 address.
Inet6Address represents a new style IPv6 address.

TCP/IP Socket
TCP/IP sockets are used to implement reliable, bidirectional persistent, point-to-point, stream-based connections between hosts on the Internet.
A socket can be used to connect Java’s I/O system to other programs that may reside either on the local machine or on any other machine on the Internet.
There are two kinds of TCP sockets in Java.
The ServerSocket clas is designed to be a “listener”, which waits for clients to connect before doing anything. ServerSocket is for servers.
The socket class is for clients. It is designed to connect to server sockets and initiate protocol exchanges.
The creation of a socket object implicitly establishes a connection between the client and server.

TCP/IP ServerSockets
ServerSockets are quite different from normal sockets.
When you create a ServerSocket, it will register itself with the system as having an interest in client connections.
ServerSocket has a method called accept() which is a blocking call that will wait for a client to initiate communications and then return with a normal with a Socket that is then used for communication with the client.

Datagrams
TCP/IP style networking is appropriate for most networking needs. It provides a serialized, predictable, reliable stream of packet data.
TCP includes many complicated algorithms for dealing with congestion control on crowded networks, as well as pessimistic expectations about packet loss.
This leads to somewhat inefficient way to transport data.
Datagram provide an alternative.
Datagrams are bundles of information passed between machines.
Java implements datagrams on top of the UDP protocol by using classes:
DatagramPacket :- is the data container.
DatagramSocket :- is the mechanism used to send or receive the DatagramPackets.

DatagramSocket
DatagramSocket() throws SocketException
DatagramSocket(int port) throws SocketException
DatagramSocket(int port, InetAddress ipaddress) throws SocketException
DatagramSocket(SocketAddress address) throws SocketException
The First creates a DatagramSocket bound to any unused port on the local computer.
The second creates a DatagramSocket bound to the port specified by port.
The third constructs a DatagramSocket bound to the specified port and InetAddress.
The fourth constructs a DatagramSocket bound to the specified SocketAddress.
DatagramSocket defines many methods. Two of the most important are send() and receive().
The send() method sends packet to the port specified by packet.
The receive method waits for a packet to be received from the port specified by packet and return the result

DatagramPacket()
DatagramPacket(byte data[], int size ) – Specifies a buffer that will receive data and the size of a packet.
DatagramPacket(byte data[], int offset , int size ) – Specify an offset into the buffer at which data will be stored.
DatagramPacket(byte data[], int size , IndetAddress ipaddress , int port ) – Specifies a target address and port, which are used by a DatagramSocket to determine where the data in the packet will be sent.
DatagramPacket(byte data[], int offset , int size , InetAddress ipaddress , int port ) – Transmits packets beginning at the specified offset into the data.

RMI
Remote Method Invocation
Java’s RMI feature enables a program in one JVM to make method calls on an object located in a different JVM, which could be running on a remote machine.
The RMI feature gives Java programmers the ability to distribute computing across a networked environment.
Object oriented design requires that every task be executed by the object most appropriate to that task. RMI takes this concept one step further by allowing a task to be performed on the machine most appropriate to the task.

RMI defines a remote interface that can be used to create remote objects.
A client can invoke the methods of a remote object with the same syntax that it used to invoke methods on a local object.
The RMI API provides classes and methods that handle all of the underlying communication and parameter referencing requirements of accessing remote methods.
RMI also handles the serialisation of objects that are passed as arguments to methods of remote objects.

Object Persistence and RMI
When a Java program used RMI, method parameters must be transmitted to the server and a return value must be sent back to the client. Primitive values can be simply sent byte by byte; however, passing objects, either as parameters or return values, requires a more sophisticated solution.
The remote object instance needs access to the entire graph of objects referenced by a parameter passed to its method.
The remote method might construct and return a complicated object that holds references to other objects.
So any object passed to or returned from a remote method must implement either the serializable insterface.

RMI Client Stubs Remote reference Layer Transport Layer Application RMI Server skeleton Remote reference Layer Transport Layer Virtual connection Network connection Application RMI Architecture

The RMI architecture consists of three layers: the stubs/skeleton layer, the remote reference layer, and the transport layer.
The java.rmi and java.rmi.server package contain the interfaces and classes that define building blocks for creating server-side objects and client-side object stubs.
A stub is a local representation of a remote object.
The client makes call to the stub, which automatically communicates with the server.
When a client invokes a remote method, the request starts at the top with the stub on the client side. The client references the stub as a proxy for the object on the remote machine.
The stub code is generated with the rmic compiler and uses the remote reference layer (RRL) to pass method invocation requests to the server object.

Stubs
The stub is a client-side proxy representing the remote object. Stub defines all of the interfaces that the remote object implementation supports.
The stub is referenced like any other local object by a program running on the client machine. It is a object on the client side; it also maintains a connection to the server-side object.
The RRL on the client side returns a marshal stream to the stub. The marshal stream is used by the RRL to communicate to the RRL on the server side.

Skeleton
The skeleton is the server-side construct that interfaces with the server-side RRL.
The skeleton receives method invocation requests from the client-side RRL. The server-side RRL must unmarshal any arguments that are sent to remote method.
The skeleton then makes a call to the actual object implementation on the server side.
The skeleton is also responsible for receiving any return values from the remote object and marshaling them onto the marshal stream.

The RRL
The RRL is responsible for maintaining an independent reference protocol that is not specific to any stub or skeleton model.
The RRL deals with the lower-level transport interface and is responsible for providing a stream to the stubs and skeleton layers.
The RRL uses a server-side and client-side component to communicate via the transport layer.

The transport layer
The transport layer is responsible for creating and maintaining connections between the client and server.
The transport layer sets up connections, manages existing connections, and handles remote objects residing in its address space.
When the transport layer receives a request from the client-side RRL it establishes a connection to the server. The transport layer then passes the established connection to the client-side RRL, and adds a reference to the remote object to an internal table. At this point the client is connected to the server.
The transport layer monitors the “liveness” of the connection.

Creating stub and skeleton
After implementation classes are complied, the next step is to create the stub and skeleton class files that are used to access the implementation classes.
The rmic command automatically creates stub and skeleton code from the interface and implementation class definitions.
Rmic serverimpl

Starting the registry and server application
The rmiregistry is an application that provides a simple naming lookup service.
When the program calls rebind(), it is the registry that maintains the binding.
The registry can be run as an independent program, or it can be created by calling the java.rmi.registry.locateregistry.crateregistery method. And it must be running before the server-side application is invoked.The program resides in the jdk/bin directory.

JavaBean

JavaBeans
You can use JavaBeans to package functions, processing, value, database access, and anything else you can dream up in java code that another developer can use from inside a JSP page, a servlet, another JavaBean, an applet, or an application.

What is JDBC
JDBC stands for Java Database Connectivity.
It is an API specification that defines the following :-
How to interact with corporate data sources from Java Applets, applications and servlets.
How to use JDBC drivers
How to write JDBC drivers.

Interoperability: The key to JDBC
It means that by using the JDBC API for database access you can change the underlying database driver (or engine) without having to modify your application. Taking this one step further you do not need to be aware of the features of a particular database system when you are developing your application; you write to the standard JDBC API specification and plug in the appropriate JDBC driver for the database. All the database implementation details of interfacing to a particular database system are left to the JDBC driver vendors.
1

JAVA APPLICATION, APPLET OR SERVELET JDBC API JDBC DRIVER MANAGER JDBC DRIVER JDBC DRIVER JDBC DRIVER ODBC ORACLE SYBASE 2

JDBC-ODBC Bridge
The JDBC-ODBC bridge is a JDBC driver that uses native (c language) libraries that makes calls to an existing ODBC driver to access a database engine.

JDBC Driver Types
The JDBC-ODBC Bridge
The Java to Native API
Java to Proprietary Network Protocol
Java to native Database Protocol.

The JDBC-ODBC Bridge
Quick System Prototyping
Database systems that provide an ODBC driver but no JDBC driver.
Low-Cost database solution where you already have an ODBC driver.
1

JAVA APPLICATION, APPLET, SERVLET JDBC ODBC BRIDGE JDBC-ODBC LIBRARY ODBC DRIVER DATABASE 2 JDBC ODBC BRIDGE

JAVA TO NATIVE API
The Java to native APT driver makes use of local native libraries provides by a vendor to communicate directly to the database.
1

JAVA APPLICATION, APPLET, SERVLET JAVA TO NATIVE API DRIVER NATIVE DATABASE LIBRARY DATABASE JAVA TO NATIVE API 2

Java to Proprietary Network Protocol
This type of JDBC driver is by far the most flexible. It is typically used in a three-tier solution and can be deployed over the internet. Type 3 driver are pure Java and communicate with some type of middle tier via a proprietary network protocol created by the driver vendor. This middle tier will most likely reside on a Web or database server and in turn communicates with the database.
1

JAVA APPLICATION, APPLET, SERVLET JAVA TO PROPRIETARY NETWORK PROTOCOL JAVA MIDDLEWARE JDBC DRIVER DATABASE INTERNET JAVA TO PROPRIETARY NETWORK PROTOCOL 2

Java to Native Database Protocol
This type of drivers are pure Java drivers that communicate directly with the database engine via its native protocol. The advantage that are no layers of native code or middle-tier software between the client and the database engine.
1

2 JAVA APPLICATION, APPLET, SERVLET JAVA TO NATIVE DATABASE PROTOCOL DATABASE ENGINE DATABASE INTERNET JAVA TO NATIVE DATABASE PROTOCOL

Callable Statement
Enables you to execute stored procedure that have out parameters.

ResultSetMetaData
An interface that provides information on a result set returned from the database.
Provides various methods for getting information about the data that was returned into a ResultSet object.

getCatalogName :- Returns a string containing the catalog name of the specified column’s table.
getColumnCount :- Returns an integer containing the number of columns that are in the current resultset object.
getColumnDisplaySize :- Returns an integer containing the maximum number of characters that the specified column’s data requires.
getColumnName :- returns a string containing the label that should be used when displaying the column to the user.

getColumnName :- Returns a string containing the name of the specified column.
getColumnType :- Returns an integer that identifies the type of the specified column.
getColumnTypeName :- Returns the specified column’s type as the current database identifies it.
getPrecision :- Returns an integer containing the decimal precision of the specified column.
getScale :- Returns an integer containing the decimal scale for the specified column.

getSchemaName :- Returns a string containing the database schema for the specified column’s table.
getTableName :- Returns a string containing the table name of the specified column.
isAutoIncrement :- Returns a Boolean value describing whether or not the specified column is an AutoIncrement column.
isCaseSensitive :- Returns a Boolean value describing whether or not the specified column is significant.
isCurrency :- Returns a Boolean value describing whether or not the specified column is a monetary value.

isdefinitelyWritable :- Returns a Boolean value describing whether or not the specified column can accpet updates.
isNULLable :- Returns a Boolean value describing whether or not the specified column is can accpet SQL null.
isReadOnly:- Returns a Boolean value describing whether or not the specified column can be updatable.
isSearchable :- Returns a Boolean value describing whether or not the specified column can be used to determine the criteria of a SQL select statement.
isSigned :- Returns a Boolean value describing whether or not the specified column is a signed data type.
isWritable :- Returns a Boolean value describing whether or not the specified column can be updatable.

Introduction
JavaServer Pages (JSP) are a critical J2EE technology for creating web content.
Although servlets are ideal for many tasks, JSP pages offer a much better alternative for generating dynamic content.
As web servers have expanded into application servers over the last few years, there has been a great interest in special scripting languages that add functionality to plain web pages.
Many proprietary languages, such as Microsoft’s ASP (Active server pages) and Netscape’s Server-Side JavaScript, have been created.
With JSP and other languages, the intent for scripting in web pages is to permit the separation of presentation from content generation, thus giving web designer great flexibility while minimizing the need for involving a programmer with presentation design issues.

The Need for JSP
Servlets have the following deficiencies when it comes to generating the output:
It is hard to write and maintain the HTML. :- you have to use parentheses and semicolons, have to insert backslashes in front of embedded double quotes, and have to use string concatenation to put the content together.
it simply does not look like HTML, so it is harder to visualize.
You cannot use standard HTML tools
The HTML is inaccessible to non-Java developers. If the HTML is embedded within Java code, a Web development expert who does not know the Java programming language will have trouble reviewing and changing the HTML.

JSP provides the following benefits over servlets alone - 1
JSP provides the following benefits over servlets alone:
It is easier to write and maintain the HTML. Your static code is ordinary HTML: no extra backslashes, no double quotes, and no lurking Java syntax.
You can use standard Web-site development tools. For example, we use Macromedia Dreamweaver for most of the JSP pages in the book.
The Java programmers can work on the dynamic code. The Web developers can concentrate on the presentation layer.

HTML Text
Description:
HTML content to be passed unchanged to the client
Example:
<H1>Blah</H1>

HTML Comments
Description:
HTML comment that is sent to the client but not displayed by the browser
Example:

JSP Comment
Description:
Developer comment that is not sent to the client
Example:
<%-- Blah --%>

JSP Expression
Description:
Expression that is evaluated and sent to the client each time the page is requested
Example:
<%= Java Value %>
Current time: <%= new java.util.Date() %>
Predefined Variables :- To simplify these expressions, you can use a number of predefined variables (or “ implicit objects ”).
Request :- The HttpServletRequest.
Response :- The HttpServletResponse.
Session :- The HttpSession associated with the request
Out :- The Writer (a buffered version of type JspWriter) used to send output to the client.
Application :- The ServletContext. This is a data structure shared by all servlets and JSP pages in the Web application and is good for storing shared data.

Implicit Variables
Every JSP page contains references variable pointing to objects, called “Implicit objects” that are always defined. You can use implicit variables inside your code.
Request :- Represents the user’s request.
Response :- Creates the output response.
Session :- Contains arbitrary variables attached to this user’s session.
Out :- The Writer (a buffered version of type JspWriter) used to send output to the client.
Application :- This is a data structure shared by all servlets and JSP pages in the Web application and is good for storing shared data.

Implicit Variables
pageContext :- Contains attributes of this page.
Congfig :- Contains servlet initialization para,eter name value pairs and the ServletContext object.
Page :- An object reference pointing to this. The current servlet object.
Exception :- Only page designated as error pages in the page directive have this object.

JSP Scriptlet
Description:
Statement or statements that are executed each time the page is requested
Example:
<% Java Statement %>
If you want to do something more complex than output the value of a simple expression, JSP scriptlets let you insert arbitrary code into the servlet’s _jspService method (which is called by service).
<%
String queryData = request.getQueryString();
out.println("Attached GET data: " + queryData);
%>

Declaration Example
<%! private int accessCount = 0; %>
Accesses to page since server reboot:
<%= ++accessCount %>

JSP Declaration
Description:
Field or method that becomes part of class definition when page is translated into a servlet
Examples:
<%! Field Definition %>
<%! Method Definition %>

JSP Directive
There are three kinds of directives :
Page
Include
taglib
Page:- High-level information about the structure of the servlet code.
Include :- Code that is included at page-translation time.
Taglib :- Custom tag libraries used.
Example:
<%@ directive att =" val " %>

Page Directive
The page directive defines attributes that apply to an entire JSP page.
A typical use would be :-
<%@ page language=“java” import=“java.util.*, java.io.*” %>
Which informs the JSP processor that the language of the code on the page will be Java, as well as declaring the packages that will be imported.

Attributes appearing in the page directive - 1
Language :- Defines the language used in code fragments.
Extends :- Defines the parent of the resulting servlet.
Import :- Defines a list of classes to be imported separated by commas.
Session :- Determines whether a session object will have to be defined.
Buffer :- Controls the size of the response output buffer.

Attributes appearing in the page directive - 2
autoFlush :- If set “false” an overview of th buffer causes an exception. If set “true” the buffer will be flushed to the output stream when full. The default value is “true”
IsThreadSafe :- When set “false” the JSP container must allow only one request to be processed at a time. When set “true” more than one request Thread can run at the same time.
Info :- Defines a string value that can be accessed in the code using the getServletInfor() method.

Attributes appearing in the page directive -3
errorPage :- If present, the value defines a URL of a resource that will be sent any exception or error object that is not caught in the Java code of this page.
IsErrorPage :- If set “true” the current page is the target of another page’s errorPage URL.
contentType :- This value gives the MIME content type and character encoding of the page as used in the ServletResponse setContentType method.

Include Directive
The include directive tells the engine to include text or output from a specified resource.
For eg :-
<%@ include file=“/jspbook/copyright.txt” %>
When this tag is encountered, the text in the file will be read and processed.
It can be anything that can legally appear in a JSP page.
Its main advantage is that it is powerful: the included code can contain JSP constructs such as field definitions and content-type settings that affect the main page as a whole.
Its main disadvantage is that it is hard to maintain: you have to update the main page whenever any of the included pages change.

Taglib Directive
The taglib directive allows you to define a library of custom action tags thatwill be used in the page.
This is a powerful concept that will enable you to use specialized toolkits as easily as you use the standard tags.
Custom tags use interfaces and classes in the javax.servlet.jsp.tagext package.

JSP Action Include
The jsp:include action lets you include the output of a page at request time.
Its main advantage is that it saves you from changing the main page when the included pages change.
Its main disadvantage is that since it includes the output of the secondary page, not the secondary page’s actual code as with the include directive, the included pages cannot use any JSP constructs that affect the main page as a whole.
Example:
<jsp:include page="bios/cheng-yinghua.jsp" />
<jsp:include page="/templates/footer.jsp" />

JSP Expression Language Element
Description:
Shorthand JSP expression
Example:
${ EL Expression }

Need For MVC - 1
Servlets are great when your application requires a lot of real programming to accomplish its task.
servlets can manipulate HTTP status codes and headers, use cookies, track sessions, save information between requests, compress pages, access databases, generate JPEG images on-the-fly, and perform many other tasks flexibly and efficiently.
But, generating HTML with servlets can be tedious and can yield a result that is hard to modify.

That’s where JSP comes in:
JSP lets you separate much of the presentation from the dynamic content.
That way, you can write the HTML in the normal manner, even using HTML-specific tools and putting your Web content developers to work on your JSP documents.
JSP expressions, scriptlets, and declarations let you insert simple Java code into the servlet that results from the JSP page, and directives let you control the overall layout of the page.
But there are some limitations :-
What if you want to give totally different results depending on the data that you receive?
limitation that the JSP page defines is a relatively fixed, top-level page appearance.
Need For MVC - 2

The solution is to use both servlets and JavaServer Pages. In this approach, known as the Model View Controller (MVC) or Model 2 architecture, you let each technology concentrate on what it excels at.
The original request is handled by a servlet.
The servlet invokes the business-logic and data-access code and creates beans to represent the results (that’s the model ).
Then, the servlet decides which JSP page is appropriate to present those particular results and forwards the request there (the JSP page is the view ).
The servlet decides what business logic code applies and which JSP page should present the results (the servlet is the controller ).
Need For MVC - 3

MVC Frameworks
The key motivation behind the MVC approach is the desire to separate the code that creates and manipulates the data from the code that presents the data.
The basic tools needed to implement this presentation-layer separation are standard in the servlet API.
However, in very complex applications, a more elaborate MVC framework is sometimes beneficial. The most popular of these frameworks is Apache Struts

Implementing MVC with RequestDispatcher
The most important point about MVC is the idea of separating the business logic and data access layers from the presentation layer.
Here is a quick summary of the required steps
Define beans to represent the data. :- Your first step is define beans to represent the results that will be presented to the user.
Use a servlet to handle requests. :- In most cases, the servlet reads request parameters.
Populate the beans :- The results are placed in the beans that were defined in step 1.
Store the bean in the request, session, or servlet context.
Forward the request to a JSP page.
Extract the data from the beans

INTRODUCTION
Many J2EE applications needs to communicate with a variety of systems in other environments; therefore, J2EE needs a powerful mechanism for communicating in heterogeneous environments.
Java CORBA provide a solution to this requirement.
CORBA is a distributed framework designed to support heterogeneous architectures.
With CORBA it is possible to connect two systems that may be running on different machines, and also may be running on different operating systems and written in different programming language.

An Overview of CORBA - 1
Several years ago, a group of engineers decided to form a consortium of their respective companies and design a reusable “system” that would enable multiple programming and operating system environments to work together.
These engineers formed the Object Management Group (OMG).
Working together, the OMG members have developed several hundred pages of specification that define a framework of reusable components.
The specification covers the architectural elements that are required to allow one hardware and software system to communicate with another.
CORBA is the framework that is the result of their work.

An Overview of CORBA - 2
The CORBA framework is designed to make communication between remote address spaces easier to implement.
The primary goal of CORBA is to provide software developers with a means for developing systems that do not rely on a single operating system, programming language, or even hardware architecture.
CORBA by itself is not a product that you can buy from a store.
The CORBA standard defines how companies can create implementations of the standard. You can purchase implementations from companies such as lona Technologies etc.

CORBA implementation
A CORBA implementation is composed of several pieces, depending on the vendor’s individual application of each standard.
A typical CORBA vendor will supply the following components :
An Object Request Broker (ORB) implementation
An interface Definition Language (IDL) compiler.
One or more implementations of Common Object Service (COS) also known as CORBAServices.
Common Frameworks, also known as CORBAFacilities.

Object Request Broker ORB ORB Object Bus Client Server

Object Request Broker
The primary mechanism for connecting objects in different address spaces is a function of the ORB.
ORB is an object bus or object pathway.
When two CORBA systems wish to communicate between different address spaces, the CORBA takes care of making sure that regardless of the hardware, operating system, and software development language used, the remote object invocations will succeed.
Typically an ORB is implemented in one of two ways :
As a “library” of objects that form an extension of the CORBA runtime.
As a daemon process.
In either case the ORB is responsible for establishing communications with the remote system, marshaling parameters to make remote calls, and managing concurrency of simultaneous requests from multiple clients.

Common Object Services (COS)
The ORB does not make up the entire CORBA implementation.
Common Object services are specified to assist the ORB.
These services include :-
Naming service
Event service
Security service
Transaction Service

Naming service
Provides a way for CORBA clients to find objects on the network.
An implementation server registers an object with a Naming Service using a hierarchical representation similar to a path used by a filename.
Client can request a reference to the object by name, using the Naming Service.

Event Service
Allows a client or server to send a message in the form of an event object to one or more receivers.
Objects can request to listen to a specific event channel, and the Event Service will notify them of an event on that channel.

Security Service
Provides a means to authenticate messages, authorise access to objects, and provide secure communications.

Transaction Service
Defines a means to control an action against a database or other subsystem.
The Transaction Service allows clients and servers to commit or roll back a transaction, even when the transaction affects multiple databases.

IDL
IDL provides a programming-language neutral way to define how a service is implemented.

What are EJB ?
Enterprise Java Beans (EJBs) are a business component model for building distributed business for development in J2EE application servers.
EJBs are defines within the J2EE specification.
The EJB 1.1 specification has become widely popular with the introduction of persistent components called entity beans.
EJBs are a model and environment for business components.
EJBs are server-bound components as well as EJBs as distributed objects and the impact this has on business coponents.

Business Components
One of primary objectives of EJBs is to provide a component model for business objects.
Business objects are defined as objects that effectively organize the information-processing behavior of the business running the software system.
Tp accomplish this effectively, business objects strive to separate tehchnology from the business rules that govern the management of information.
Many business rules are specific to a given business, and therefore require the building and management of custom EJBs.
Enterprise Java Beans provide various types of building blocks for enterprise applications.

Types of EJB’s
Session Beans
Stateless session beans
Stateful session beans
Entity beans
Message driven beans

Session Beans

Session Beans
One way to think about the application logic layer (middle tier) is a set of objects that, together, implement the business logic of an application.
Session beans are the construct in EJBs designed for this purpose.
In the diagram we see that that there may be multiple session beans in an application and each handles a subset of the application’s business logic.
A session bean tends to be responsible for a group of related functionality.
For example, an application for an educational institution might have a session bean whose methods contain logic for handling student records.
Another session bean might contain logic that maintains the lists of courses and programs available at that institution.

Two types of session bean,
Stateless —These beans do not declare any instance (class-level) variables so that the methods contained within can only act upon any local parameters. There is no way to maintain state across method calls.
Stateful —These beans can hold client state across method invocations. This is possible with the use of instance variables declared in the class definition. The client will then set the values for these variables and then use these values in other method calls.

Entity Beans - 1
Before object orientation became popular, programs were usually written in procedural languages and often employed relational databases to hold the data.
Because of the strengths and maturity of relational database technology, it is now often advantageous to develop object-oriented applications that use relational databases.
The problem with this approach is that there is an inherent difference between object-oriented and relational database technologies, making it less than natural for them to coexist in one application.
The use of entity beans is one way to get the best of both of these worlds, because:
Entity beans are objects, and they can be designed using object-oriented principles and utilized in applications as objects.
The data in these entity bean objects are usually persisted in relational databases. All of the benefits of relational technologies, including maturity of products, speed, reliability, ability to recover, and ease of querying, can be leveraged.

In a typical EJB scenario, when a session bean needs to access data it calls the methods of an entity bean.
Entity beans represent the persistent data in an EJB application.
For example, an application for an educational institution might have an entity bean named Student that has one instance for every student that is enrolled in an institution.
Entity beans, often “backed” by a relational database, read and write to tables in the database.
Because of this, they provide an object-oriented abstraction to a relational database.
Entity Beans - 2

Message-Driven Beans
When an EJB-based application needs to receive asynchronous messages from other systems, it can leverage the power and convenience of message-driven beans .
Asynchronous messages between systems can be analogous to the events that are fired from a UI component to an event handler in the same JVM.
One example application that could use message-driven beans is in the business to business (B2B) domain: a wholesaler could have an EJB application that uses message-driven beans to listen for purchase orders issued electronically from retailers.

Enterprise applications

by Sumit Tambe on Nov 20, 2010

Accessibility

Categories

Upload Details

Usage Rights

Statistics

Enterprise applications Presentation Transcript