White Papers

Application Servers and Enterprise Application Development

Introduction

What Are Application Servers?

Application servers are software that help enterprises develop, deploy and manage large numbers of applications that are mostly distributed in nature.

The Application servers market has been identified as one of the hottest growing areas in internet technology currently. The total size of the market is expected to go up from $400 million last year to $2billion in the year 2001. This has seen many medium sized players getting into the market. Quite a few application servers exist in the marketplace today: more than 25 by one study. The major vendors are IBM, Microsoft, Sun, Oracle, Netscape, BEA and SilverStream.

From a developer's point of view, the central difference that an application server brings about is the separation of business logic from the presentation logic and the database logic. Essentially, application servers help us build true 3-tier applications where the database is logically separated (sometimes physically separated too) from the business logic.

Developing a server involves dealing with many complicated issues like concurrency, providing access to all possible production databases, network connection management, database connection pooling, legacy database support, designing a management console, clustering support, load balancing, failover, extensibility of your development frame work and performance.

An application server can simplify your development process. Application servers usually take care of most, if not all the involved technical issues and allow developers to concentrate on the reason why the project came about in the first place - the business need. This allows one to budget for much larger and much more useful systems.

While application servers like BEA Weblogic, IBM Websphere or Microsoft Backoffice Server give you a great head-start in web and line-of-business application building, they are nonetheless very advanced and complicated products. Their application building frameworks are meant for use by advanced developers. The time involved in learning the essential technologies involved in the framework can be considerable

For example, consider the Microsoft BackOffice Server. Application building using Microsoft BackOffice Server would involve expertise in technologies like DCOM, ODBC/OLE-DB, Microsoft Transaction Server, Microsoft Message Queue server and ASP. Each of these is a fairly well developed and involved technology. The training time involved in getting up to speed in these technologies can range from two to six months.

Features In Application Servers :

At this point, it might be appropriate to take a look at the features that one should typically expect from an application server.

The common features that should be on any application server are

Support for business and application logic. Typically this is achieved through component technologies like COM, CORBA and the Java-specific RMI - applied in a framework like Microsoft Windows DNA or Enterprise JavaBeans.
Multithreaded access and Database connection pooling - These are two major design issues that developers have to deal with in developing applications from the ground-up. Make sure that the application server lets you forget about designing for concurrency.
Creation of COM and/or CORBA objects. This is probably a feature you should insist on, unless your organization has already made a decision on standardizing development around a single component model.
Clustering support, load balancing and failover features.
Transaction Integrity.
Connectivity to legacy systems like mainframes and older transaction and database systems.
Secure transactions and support for SSL/HTTPS.

While the above is a good minimum set of features one could expect, there are others that you might be interested in.

Ability to deploy on the web and serve users over the Internet, Intranet and Extranet.
Transaction processing monitors. These are available in the high end systems that are available from vendors like BEA Systems and IBM.
Transaction processing and performance oriented features.
Support for working with other application servers.
Integration with development tools and features oriented towards accelerating development.
Integration with Enterprise resource planning packages like SAP/R3 and Peoplesoft.

Many domain specific features can be expected as application servers mature and age. However, the chances are that most of the important advantages you might expect are listed above.

The Java Application Server

A Java application server is a server that is built using Java that lets you easily deploy and manage distributed Java applications on the internet, intranet or extranet.

The Java application server seems to be a ubiquitous phenomenon. This undoubtedly due to the platform independence offered by Java and the ease of learning of Java.

In our opinion, application development using a Java Application server would be easier and far more linear than development using the primary competing framework - the Microsoft BackOffice products.

Apart from the two major benefits of platform independence and ease of learning of the language, here are some other aspects that are quite standard in Java application servers.

Support CORBA and COM in most cases through the Enterprise Javabeans specification.
Feature Servlet support - implies that business logic need not be centralized at the server. You can have a number of servlets - mini applications that are spawned by the application server - handle your processing in different machines. Your databases could exist on entirely different machines.

Typical Technical Issues In Enterprise Application Development

What are the technical problems that you typically face in an enterprise application development effort? What are the Java APIs that are relevant in each situation, given a generic application server framework? Here is a list we have for you


Requirement/Need	Technology
Design and implementation for Reusability	Enterprise JavaBeans, Javabeans
Transaction Control	Enterprise JavaBeans,Java Transaction Service
Database access to various databases	JDBC
Transferring files to and from the server in your application	Java IO and net classes
HTML/HTTP based access	HTTP Servlets
Client to Server security and encryption	Security and Cryptography APIs
Client-Server processing tradeoffs(Thin and Fat Clients)	RMI, Corba, Java IDL
Business events	Java Message API
Access to directory services	JNDI
Access over firewalls	HTTP servlets
Corba components	Java IDL

Please remember that this list is not meant to be comprehensive. It provides a very broad mapping between the Java APIs and an enterprise application development situation. For example, if you need to develop Corba components in your application, take a look at the Java IDL API. If you are interested in developing reusable objects, make sure someone in your team knows all about Enterprise Javabeans and Javabeans.

Buying yourself a Java application server does not mean freedom from knowing about the APIs we have listed. An application server can reduce your time to production or time to market considerably, but you still have to know the framework very well. You will still need to be familiar with JDBC, Enterprise Javabeans and the other important APIs. Application servers only make the application easier to develop and deploy.

Developing An Application For BEA Weblogic: A Case Study For Developers :

The BEA Weblogic application server (formerly called Tengah) is a server built almost completely in Java. The BEA weblogic server provides features like Zero Administration clients, graphical console for administration, transaction processing, transaction control and security. In the absence of an application server, building all those features into your system might simply take up all the time that your development team has on their hands.

Like all application servers, this is not simple or easy-to-use. Weblogic is an advanced developers product and offers APIs, frameworks and packages for use by developers. Many of these APIs are substantial improvements over the Javasoft APIs - and are intended to make things easier for us developers. Of course, most APIs are specific to the scenario where Weblogic is being used for enterprise application.

Some of the important APIs are Tengah JDBC, Tengah Enterprise Java Beans, Tengah HTTP Servlet support and Tengah SSL. Here is our old list appearing again - this time the idea is to map your development problem to a Weblogic-specific area.


Requirement/Need	Technology
Transferring files to and from the server in your application	Tengah File services
Client to Server security and encryption	Tengah ACLs, Tengah SSL
Use COM components	Tengah COM
Client-Server processing tradeoffs(Thin and Fat Clients)	Tengah Remote
Realtime results	Tengah Events
Scheduled events	Tengah Time API
Connection pooling	Tengah Enterprise beans
Access to directory services like Novell Directory services and Microsoft Active Directory.Directory services Supporting the LDAP protocol	Tengah JNDI
HTML/HTTP based access	htmlkona , Tengah HTTP Servlets
Database access	Tengah/JDBC

Here, we will first deal with connecting to a database to retrieve data. Both the two tier and the three tier cases are dealt with. A description of the components of the Weblogic framework will follow this application building exercise.

Imagine a system where users in a corporation need to check each other's schedules in order to make planning decisions. Typically, such a system might have the following technology requirements

Database support - Oracle, MS SQL Server or Informix.
A browser based front end so that users need not install applications on their computers. This might even be extended to an Enterprise Java Bean.
Encrypt transmissions in order to prevent unauthorized users from reading schedules
Access over HTTP in order to work over firewalls

In this section we will explain the fundamental issue of creating 2-tier and 3-tier database connections. The SSL-enabling and the Servlet support functions of the sample application will not be implemented here. Nor will we delve into issues involved with Enterprise JavaBeans development.

To build a system supporting the above four requirements, one would firstly need a conceptual understanding of the Weblogic framework. Database support is available through the Tengah/JDBC. Weblogic provides support for both 2-tier and 3-tier implementations of the application. The 2-tier application is quite simple - get the instance of the driver required, create a connection object, create a statement object and use a statement.executeQuery() call to retrieve a view. To access the view through the recordset object retrieved, use recordset.next() and recordset.getString().To update the table, use statement.executeUpdate(). All this is standard database access procedure if you are familiar with JDBC.

The following example is a simple Tengah/JDBC application that will connect to an MS SQL Server database and retrieve a few records. For the sake of simplicity, we have stripped away the user interface and the error handling sections of the code. If you use a different database, replace "mssqlserver" in the DriverManager.getConnection() call to "oracle", "sybase" or otherwise, as the case might be. For further details refer the BEA Weblogic documentation.

Quite easy, wasn't it? Of course, before running the app, make sure that

BEA Web logic is set up on the machine you are running the application on
Create the schedule table on the default database with the fields Name, StartTime, EndTime, MeetingSummary and MeetingDetails.
StartTime and EndTime are date fields. Name, MeetingSummary and MeetingDetails are string/text fields.
Populate the table with a few rows.
The database access properties are changed - user, password and server values are changed to reflect your correct database access details. Contact your database administrator if you need help on this.

Now that we are set, let us explore converting this application to a 3-tier application.

Add the following import statements to the beginning of the code.

Create a T3Client object to connect to the server -the default port at which the Weblogic server listens is 7001. Update the port number if you have set up the Weblogic server to listen on another port. Here, I am assuming that MYTENGAH is your server name. Note that the protocol descriptor "t3://" is necessary to correctly create the object.

A few T3Client specific properties need to be set after this. The rest follows in JDBC style- create a connection object, create a statement object and then create a recordset object from the statement object. Execute the query on the statement and use next() on the recordset in order to retrieve rows.

t3props.put("weblogic.t3",  t3);
				t3props.put
				("weblogic.t3.driverClassName","weblogic.jdbc.dblib.Driver");
				t3props.put
				("weblogic.t3.driverURL", "jdbc:weblogic:mssqlserver");
				
				Class.forName("weblogic.jdbc.t3.Driver").newInstance();
				conn = DriverManager.getConnection
				("jdbc:weblogic:t3", t3props);
				
				// A connection to the database has been established. 
				// Note that we could have established a 
				// connection to many Now, retrieve required data.
				Statement stmt = conn.createStatement();
				String query = "SELECT * FROM ScheduleTable";
				ResultSet rs = stmt.executeQuery(query);
				while (rs.next()) 
				{
					String s = rs.getString("Name");
					String s2 = rs.getString("StartTime");
					String s3 = rs.getString("EndTime");
					System.out.println(s + "  "+ s2 + "  " + s3 );
				}
					  
				   catch (Exception e)
					{
						e.printStackTrace();
					}
						finally 
					{
						try {conn.close();}    
						catch (Exception e) { e.printStackTrace();}
						try {t3.disconnect();} 
						catch (Exception e) { e.printStackTrace();}
					}

Note that, in order to tailor the implementation to databases like Oracle or Sybase, you will have to modify both the "weblogic.t3.driverClassName" and the "weblogic.t3.driverURL" properties.

Here, as you would have no doubt observed, the key difference is that the connection to the database is being made through the BEA Weblogic server. (This is the point where you get the benefits associated with application servers).

We have investigated the basic issue of database access in two tier and three tier applications. But what about the more advanced features like reusability, servlet building, Security of electronic transmissions?

Weblogic does provide EJB support, SSL and HTTPS support and support for building servlets. To develop the browser based front end, we would need to create an applet that might need to adhere to the EJB component model. In order to build the encryption and security functionality into the application, use Tengah SSL. Using Tengah SSL primarily involves making a few changes in a properties file and changing the URL scheme from t3:// to t3s://. Some other complications that will influence your SSL-aware application are - slowdown in transfer rate due to encryption and decryption, issues relating to using SSL in servlets and the feasibility of using certificate authentication from applets. Of course, in order to enable SSL on your Weblogic server, you will need to obtain a server certificate from a Certificate Issuing Authority like Verisign. Refer the BEA Weblogic documentation for further details.

The Important APIs Relevant To A Java Application Server :

The application server framework as we noted earlier, consists of APIs like EJB, JDBC, RMI, JNDI and Servlets to name a few. This section will attempt to present an overall picture of the important APIs involved.

Enterprise Javabeans

Let us first see what enterprise Javabeans are all about. An enterprise Javabean is an "extended JavaBean". Javabeans are java-specific user-interface oriented components that aid developers in building reusable and portable java components. Reusability is the key in a JavaBean.

Enterprise JavaBeans are non-visual Javabeans components. Instead of being oriented at user interface components, EJBs play a more significant role in the application server context by providing a framework for developers to encapsulate business logic in. The EJB framework takes care of transaction management, state management and security. The EJB container also handles low level details like multi-threading, remote invocation, transaction boundary management, and distributed transaction management, clustering and automatic persistence. The EJB specification also allows for strong cryptography and security.

An enterprise bean can be deployed on multiple platforms without recompilation or source code modification.

Developers can focus on the business problem and leave out all the highly technical infrastructure and management details to the framework. The Enterprise Javabeans framework also makes possible a scenario where application building is accomplished by putting together a number of EJBs in an application server framework.

EJBs will make it possible to build distributed applications by combining components developed using tools from different vendors. EJBs also provide interoperability between enterprise beans and non-Java applications.

For more information, refer the EJB specification at Javasoft.

JDBC

The JDBC is Java's default database access interface. To access databases in Java, you will need a JDBC driver in between the application and the underlying database driver.

There are four kinds of JDBC drivers - type I to type IV: the JDBC-ODBC bridge, the direct JDBC driver, the three tier drivers available in application servers like Weblogic and finally, the native JDBC to database-network-protocol driver


Driver	Architecture
Type I	Calls go from JDBC to the ODBC bridge layer. ODBC converts queries to the native API for the database.
Type II	JDBC has a vendor supplied library to translate JDBC functions to the DBMS's query language.
Type III	JDBC driver on the client passes queries to the middle layer-server. The server then works with the database like a Type I or Type II driver does.
Type IV	Driver converts queries to the protocol directly understood by the database. The mapping is not to the DBMS query language.

Type I and type II drivers do not involve downloading any code to the client. With Type III and Type IV drivers, clients download database drivers across the network. Type IV drivers can be quite considerable in size. This can result in increased connection time.

While the first two are the more simple implementations, enterprise application building will often involve using type III or Type IV implementations. Here is a clear summary of the situations that you might face - mapped to the driver that will be relevant.


Need/Situation	Appropriate Driver
Simple applications involving very basic database access. OBDC drivers are already available for the database and getting a dedicated JDBC driver may not be possible.	Type I
Transaction Control	Type II
Database access to various databases	Type II
Transferring files to and from the server in your application	Type II
HTML/HTTP based access	Type III
Client to Server security and encryption	Type III, generally - depending on the implementation
Client-Server processing tradeoffs(Thin and Fat Clients)	Type IV

Now that we have discussed JDBC drivers from an architectural perspective, it is time to quickly summarize the process of using JDBC to connect to the database and retrieve records.

You will need to do the following

Load the class that will handle your JDBC connection.
Establish a database connection.
Create a statement object from the connection object.
Execute SQL retrieve/update statements.
Retrieve and display the results.

Transaction control is possible through the

method. In this case, you will need to specify when to rollback the transaction. Refer the Java 2 Platform API documentation for the more advanced features available in JDBC.

Where the same query or update may be repeated often, use a prepared statement to speed up results.

This is an overview. For more detailed information on JDBC and database access, refer the Java Tutorial.

Servlets

Servlets are Java's server side applications. Servlets are a very attractive alternative to CGI scripts. Compared to CGI scripts, Servlets offer benefits like better performance, lower effort in creation and platform independence.

Servlets are excellent when you have your application server behind a firewall and require clients from across the firewall to connect to the server for processing. This is simply because HTTP access using Servlets is easy (Firewalls wont restrict HTTP access). Other situations where Servlets are handy include load balancing, communication between several users using a server, etc.

To a developer, a Servlet is at the barest minimum a class that extends a GenericServlet class. The HTTPServlet class in the javax.servlet.http API is probably the most useful subclass of GenericServlet that you can ever dream up of. HTTPServlet is a class that is tailored for sockets communicating with clients over HTTP. The HTTP GET, POST, PUT and DELETE methods may be overridden to provide functionality. For instance, if the HTTP GET method implementation is supplied by your subclass of HTTPServlet, you can return a simple HTML page to the client.

The javax.servlet.html contains some very useful methods for assembling data into HTML elements such as tables and forms.

Servlets typically need to take care of multiple clients simultaneously. So you will need think about synchronized access to shared data when you design a Servlet for a demanding application. If you can actually afford the luxury of having a single servlet service each client, you implement the SingleThreadModel interface in your servlet. In situations where a single servlet on a single machine would be insufficient to handle the load, you will have to resort to some load balancing and session tracking. One simple way of balancing the load would be redirect the client to another page through HTML. Alternatively, you could open a new URL connection to another downstream servlet and have the second servlet perform the processing.

What are the input parameters to the doGet method? How do I write a simple Servlet? How do I use Servlets for load balancing? Servlets are a rather involved topic. We have only given you an overview in order to let you know what you might be getting into when you start Servlet development. A detailed discussion of Servlets is outside the scope of this paper. For answers to the above questions and more, refer Servlet Central or the Java Tutorial.

Conclusions

This paper has attempted to guide the reader towards attaining technological perspectives necessary for developing applications for a Java Application server. The significant elements of application building have been addressed at the level appropriate for System Architect - areas like JDBC, Enterprise JavaBeans and Servlets have been covered with this perspective in mind.

Java application servers now make the development of highly reusable applications a practical possibility. Technological complexities are mostly taken care of by the framework. The emphasis here is certainly on taking a larger view of the business model - that is the crux of the Java application server.

We in Calsoft hope that the information given in this paper serves as a useful guide for your decisions on application building.

References

The Java Platform documentation page-www.java.sun.com/docs/index.html
The Java Tutorial - www.java.sun.com/docs/books/tutorial/index.html
Javasoft's JDBC core API- www.java.sun.com/products/jdbc/index.html
IBM Websphere home- www-3.ibm.com/software/webservers/index.html
BEA Weblogic documentation- www.weblogic.com/docs/techoverview/index.html
Netdynamics application server-www.sun.com/developers
Netscape application server-www.enterprise.netscape.com/
Microsoft Transaction Server Compared to Enterprise Java Beans: Read Microsoft's version of why their core application server technology is better than Enterprise JavaBeans!- www.microsoft.com/ntserver

Resources

Next Step