Application Servers and Enterprise application development

makeshiftklipInternet και Εφαρμογές Web

31 Οκτ 2013 (πριν από 3 χρόνια και 9 μήνες)

78 εμφανίσεις

Application Servers and Enterprise application
development



INTRODUCTION

................................
................................
................................
................................
.........................

2

What are application servers?
................................
................................
................................
..............................

2

Features in application servers

................................
................................
................................
............................

2

THE JAVA

APPLICATION SERVER

................................
................................
................................
...................

3

Typical Technical issues in enterprise application development

................................
................................
...

3

D
EVELOPING AN APPLICA
TION FOR
BEA

W
EBLOGIC
:

A

C
ASE
S
TUDY FOR DEVELOPERS

................................

4

T
HE
I
MPORTANT
API
S RELEVANT TO A
J
AVA
A
PPLICATION
S
ERVER

................................
................................
..

8

Enterprise Javabeans

................................
................................
................................
................................
..........

8

JDBC
................................
................................
................................
................................
................................
.........

9

Servlets

................................
................................
................................
................................
................................
..
10

C
ONCLUSION
................................
................................
................................
................................
...............................

12

REFERENCES
................................
................................
................................
................................
.............................
13


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 Ap
plication 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 d
ifference 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
(som
etimes 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.


Whil
e 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 fram
eworks 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
BackOffic
e 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 spe
ed in these
technologies can range from two to six months.


This means that outsourcing this kind of development activity would in general be a good idea.


Features in application servers


At this point, it might be appropriate to take a look at the featur
es 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 th
e 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 d
evelopment 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 ar
e 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 orie
nted 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 import
ant 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 standar
d 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 applic
ations 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 t
hat 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 imple
mentation 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 fami
liar
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 (f
ormerly called Tengah) is a server built almost completely
in Java. The BEA weblogic server provides features like Zero Administration clients, graphical
console for administation, transaction processing, transaction control and security. In the
absence o
f 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
prod
uct 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 W
eblogic 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 pr
oblem 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
-
Se
rver 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 Di
rectory. Directory services Supporting
the LDAP protocol

Tengah JNDI

HTML/HTTP based access

htmlkona , Tengah HTTP Servlets

Database access

Tengah/JDBC


The fundamental step in application development using the BEA Weblogic server would be to
connect to

the database of your choice. This can be done through a two tier or a three tier
application.


Here, we will first deal with the business of connecting to a database to retrieve data. Both the
two tier and the three tier cases are dealt with. A descriptio
n 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 f
ollowing technology
requirements


1.

Database support


Oracle, MS SQL Server or Informix.

2.

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.

3.

Encrypt transmissions
in order to prevent unauthorized users from reading schedules

4.

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 suppo
rt 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, cre
ate
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.exec
uteUpdate(). 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 detail
s refer the BEA Weblogic documentation.


import java.sql.*;

class twoTierSample

{

public static void main(String[] args)


{


java.util.Properties dbprops = new java.util.Properties();


dbprops.put("user","matt");


dbprops.put("password","mattpw")
;


dbprops.put("server","FBI_CIA");


try


{

Class.forName("weblogic.jdbc.dblib.Dri ver").newInstance();

java.sql.Connection conn =
DriverManager.getConnection("jdbc:weblogic:mssqlserver",dbprops);

Statement stmt = conn.createStatement();

String qu
ery = "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)


{

System.out.println("Error ");

e.printStackTrace();


}

}

}


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

a.

BEA Web logic is set up on the machine you are running the application on

b.

Creat
e the schedule table on the default database with the fields Name, StartTime, EndTime,
MeetingSummary and MeetingDetails.

c.

StartTime and EndTime are date fields. Name, MeetingSummary and MeetingDetails are
string/text fields.

d.

Populate the table with a few
rows.

e.

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 t
his application to a 3
-
tier application.


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

import weblogic.db.jdbc.*;

import weblogic.common.*;



Create a T3Client object to connect to the server

the default port at which the Weblogic ser
ver
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.

t3 =

new T3Client("t3://MYTENGAH:7001");


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.


import java.sql.*;

import java.util.Properties;

import weblogic.common.*;

class threeTierSample

{

public static void main(String args[])

{

T3Client t3 = null;

Connec
tion conn = null;

try {


t3 = new T3Client("t3://199.2.24.84:7001");

t3.connect();

// now we have a connection to the weblogic server

// Let us now get the connection to the datase

Properties dbprops = new Properties();

dbprops.put("user","matt");

dbprops.
put("password","mattpw");

dbprops.put("server","FBI_CIA");


Properties t3props = new Properties();

t3props.put("weblogic.t3.dbprops", dbprops);

t3props.put("weblogic.t3", t3);

t3props.put("weblogic.t3.driverClassName", "weblogic.jdb
c.dblib.Driver");

t3props.put("weblogic.t3.driverURL", "jdbc:weblogic:mssqlserver");


Class.forName("weblogic.jdbc.t3.Driver").newInstance();

conn = DriverManager.getConnecti on("j dbc:weblogic:t3", t3props);



// A connection to the database has been estab
lished.


// 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()) {



Strin
g 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.clos
e();}

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 "web
logic.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 transmiss
ions?


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 encryp
tion 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
-
awar
e 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 wi
ll
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 ea
rlier, 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 enterp
rise 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 Javab
eans 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 transacti
on 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 technica
l
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 a
t 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. OD
BC 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
污nguage

qype fff

gaBC dr楶er on the 捬cent passes quer楥s to the m楤d汥 污yer
J
server. qhe server then
wor
ks w楴h the database 汩ke a qype f or qype ff dr楶er does.

qype fs

ar楶er 捯nverts quer楥s to the proto捯氠d楲e捴汹 understood by the database. qhe
mapp楮g 楳 not to the aB䵓 query 污nguage.


qype f and type ff dr楶ers do not 楮vo汶e down汯ld楮g any 捯de

to the 捬cent. t楴h qype fff and
qype fs dr楶ersI 捬cents down汯ld database dr楶ers a捲oss the network. qype fs dr楶ers 捡n be
qu楴e 捯ns楤erab汥 楮 s楺e. qh楳 捡n resu汴 楮 楮捲eased 捯nne捴楯i t業e.



th楬e the f楲st two are the more s業p汥 業p汥mentati
onsI enterpr楳e app汩捡t楯i bu楬d楮g w楬氠often
楮vo汶e us楮g type fff or qype fs 業p汥mentat楯is. eere 楳 a 捬car summary of the s楴uat楯is that
you m楧ht fa捥


mapped to the driver that will be relevant.


Need/Situation

Appropriate Driver

Simple applic
ations 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

Situations where queries are not very lengthy. Frequent database
accesses take place, though c
onnections last for short intervals.

Type II

Performance is important. Network speed is a bottleneck.

Type II

Situations where database connection time can affect the performance
of the system considerably.

Type II

Ease of application deployment is imp
ortant. Many applications may be
deployed. Performance is not mission critical. High database connection
times are not a problem.

Type III

Advanced database processing situations. Distributed database
processing. Distributed transactions

Type III, general
ly


depend楮g on the
業p汥mentat楯i

iong and 楮vo汶ed database pro捥ss楮g where h楧h database
捯nne捴楯i t業e does not adverse汹 affe捴 performan捥.

qype fs


Now that we have discussed JDBC drivers from an architectural perspective, it is time to quickl
y
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 connection.setAutoCommit() method. In this case,
you will need to specify when to rollback the transaction. Refer the Java 2 Plat
form 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 in
dependence.


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 rest
rict 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 c
lass 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 ma
y 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 assem
bling 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 serv
let 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 wha
t 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, for instance.

Conclusion


This
paper has attempted to guide the reader towards attaining technological perspectives that is
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 complexitie
s 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 CSWL 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

http://www.javasoft.com/docs/index.html


The Java Tutorial

http://www.javasoft.com/docs/books/tutorial/i ndex.html


Javasoft’s JDBC core API

http://www.javasoft.com/products/jdbc/i ndex.html


IBM Websphere home

http://www.software.ibm.com/webservers/index.ht ml


BEA Weblogic documentation

http://www.weblogic.com/docs/techoverview/index.html


S
ilverstream home page

http://www.silverstream.com/


Oracle application server

http://www.olab.com/


Netdynamics application server

h
ttp://netdynamics.com/


Netscape application server

http://home.netscape.com/appserver/v2.1/index.html


Microsoft Transaction Server Compared to Enterprise Java Beans: Read Microsoft’s ve
rsion of
why their core application server technology is better than Enterprise JavaBeans!
http://www.microsoft.com/ntserver/appservice/techdetails/techcompare/MT
SEJB.asp


Servlet Central

http://www.servletcentral.com