Askar S. Boranbayev
Eurasian National University named after L.N. Gumilyov, Astana,
Architecting and Designing Web Applications
1. Overview
When
architecting and designing an application, you are in the first phase of the
software life cycle. When architecting
and designing an application, there are usually many existing blueprints and
design patterns that can be used as a starting point to build the
application. The advantage of using an
existing blue print or design pattern is they solve many issues common to
application development. There are also
many factors to take into account when planning the application. This includes performance, scalability,
packaging and deployment restrictions.
2. Reference Architecture for Web Applications
The reference
architecture should be used as the basis when designing a particular
system. It is assumed that architect can
select from a set of well-known elements (standard parts) and use them in ways
appropriate to the desired system.
Depending on
the project requirements, web based applications come in two flavors -
reporting or transactional. Transactional application performs a lot of
business functions against incoming and outgoing data when managing
transactions and controlling its state. Reporting application, on the other
hand, does not apply extensive business logic to the tunneled data, its main task is to retrieve and to present big data
sets to the end-user in the form of tables or lists of records. There are
situations when transactional and reporting functionality need to be combined
in the same web application.
2.1 Tiers
For both
types, application functionality is distributed over three locations: user
machines, the application server machine, and the database or any other
resources at the back end. For the front-end tier, there is a browser running
on the desktop computer, which renders such interactive components as HTML or
DHTML, with embedded scripting elements (JavaScript in most cases).
The back-end
tier is constituted from one or several relational databases (such as Oracle)
and/or multiple Tuxedo services (C based transaction processing system).
Application Server(s)
presents the middle-tier. At this tier,
the web container of WebSphere Application Server
provides runtime environment for Java-based applications. The middle-tier is where the most of the
architectural expertise and effort is usually applied.
Front-End Tier Back-End Tier Middle Tier
2.2 Layers
Control Layer: The Control Layer
translates user requests into actions to be performed by the application. The
framework provides major control for this layer through the means of MyProxy and MyRequestHandler java
classes. Application specific proxy and request handler classes must extend
from them. The proxy acts as a
controller, responsible for delegating the requests to the appropriate request
handlers. It also initializes (once, at
start-up) and manages all available services and resources for the
application. Framework logic around MyProxy and MyRequestHandler also
interacts with AuthenticatorWEB component on behalf
of the application for authentication and authorization purposes.
NOTE: Each
specific application action (view, create, submit, delete, calculate etc.,)
should have one corresponding request handler on the server side. This approach helps to define fine grained
control structure for the application, which is easy to understand, manage and
support.
Business Layer: Business Layer serves the
purpose of encapsulating all necessary business logic that needs to be
performed against incoming and out-going application data, whatever form it
might take - primitive Java types, Domain Value Objects, Collections, etc. [2]
Each business
service on that layer is supposed to contain only objects that are logically
related to each other - either because they are consistent with business
process flow (use case) or they operate on the same set of data.
NOTE: A Business service,
either presented as one single object or collection of objects, executes
business logic [it is a processing unit and not a Java Bean with numerous get..() and set...() methods.]
Data Access Layer: The data access layer
separates application business logic from system data storage's [2]. The Data
Access Object (DAO) is the primary object of this layer.
The data access
object abstracts the underlying data access implementation for the business
layer to enable transparent access to the data resource.
The data
resource could be a persistent storage like an RDBMS, or a repository like an
LDAP database. The DAO completely hides the data access implementation
details.
Because the
interface exposed by the DAO is not supposed to change when the underlying data
resource implementation changes, this allows the DAO to adapt to different storage
schemes without affecting application business layer. Essentially, the DAO acts as an adapter
between the business logic and the data resource.
The
functionality (set of methods) for DAO should be centered on business domain
entities. It means, for example, that
for such business entity as "Order" all DB operations (object
methods) for updating, selecting, or deleting order related data should be
placed into one DAO (one java class).
In some cases,
DAO will return such business domain entity (in the form of Java Bean or Value
Object) to the business layer for further processing. In other cases, it might return only the
final condition of the performed operation (success or failure).
There are
several frameworks available for usage on the data access layer. When
application data resource is RDBMS - the Database Access Framework provides
seamless database connection pooling and simplified set of functions for
retrieving connections, executing queries, and working with the query results
set. When there is a need to persist
data between several requests - the Persistence Framework provides the storage
of objects in any JDBC or JNDI compliant databases. It helps in relating the object model to the
data model through the set of simple Java API's.
Presentation Layer
Presentation
Layer handles the layout and formatting of the data before it is sent to the
front-end tier. It relieves the other
application layers of any concerns regarding data represented to the end-user.
The
presentation layer contains set of JSP's. Usually one JSP corresponds to one HTML page
displayed by the browser. JSP obtains
all necessary data from Domain Objects that had been previously created by the
data access layer and processed by business layer [2].
The
presentation layer does its work after the control layer of the application
transfers the execution flow to it.
2.3
Reporting Application
Most of what
has been mentioned about layers, components, and services can be successfully
applied for reporting type applications as well. At the same time a reporting application
differs from a transactional application in two major aspects; first - it works
with big (sometime huge) data sets, second - it does not apply extensive
business logic when processing those data sets.
In the
reporting application there is no need for creating domain entities, because
there is no business logic that needs to operate on those entities. The functionality that is applied to the
retrieved data is usually limited to the structuring, formatting, and sorting
tasks.
This leads us
to the idea of storing retrieved data in the form of columns and records in
plain data structures, such as arrays and collections. The absence of sophisticated business logic
usually restricts the business layer to the set of simple responsibilities of
assembling and arranging retrieved data, so it can be easily embedded into HTML
pages by the presentation layer.
3. Integration and Remote Communications
3.1 Creating Business Services
One of the
biggest promises of object-oriented development has been that of promoting code
reuse. That promise is built on the idea that if you were to build generic
objects, those could be used and reused.
The question
that comes to mind is how to take that one step further and be able to reuse
business functionality. Till so far, architects and designers have been able to
contain business logic in a set of business objects that comprise the Business
Layer. How do you package this business functionality such that different types
of clients could reuse it?
Layered Approach
The first
principle of creating business services is that of separation of layers. A layer consists of entities that share
similar responsibilities. For instance,
the data access object layer contains objects that are responsible for
providing access to various data stores. In order to eliminate circular dependencies, a
lower layer never depends on a higher layer. For instance, the Services Layer should not
accept HttpServletRequest as an input parameter.
Doing so makes it dependent on a type of Invocation Layer. A higher layer would always depend on the
functionality provided by the lower layer. Based on this principle the Services layer
should not contain any of the following:
·
HTTP/ Servlet / Swing API
·
Java remoting or UI technology
specific constructs.
·
JDBC constructs
Interface Driven Design and Development
The second
principle is that of Interface driven design and development. It states that software designers should
define clear interface specifications for components. All collaborations amongst components within a
layer and across layers should be driven by these interface specifications or
contracts. The big advantage of this principle is that it forces designers to
assign specific responsibilities to components, and it helps to clearly
identify the various collaborations amongst components. An additional advantage is that
implementations of these interfaces can evolve over time, without disrupting
the other dependent components.
The Factory
design pattern is a good way to cleanly separate the instantiation of an
implementation of an interface, from the use of the interface itself.
Business Services
A service
consists of a collection of components that work in concert to deliver the
business function that the service represents.
It is an abstraction layer on top of the functionality exposed by
business objects, which in turn are fine-grained and are solely focused on
implementing the individual steps of a business process workflow. Services orchestrate various operations
across multiple business objects, thus promoting the reusability of business
objects. Any extensive orchestration of
service operations by the calling clients should essentially be exposed as a
coarse-grained operation on the service itself.
At times, services may appear as a pass-through layer but they provide
the flexibility of being able to create orchestrations of the business objects,
in future.
Services are
process-centric, in that they map to the business functions that are identified
during business process analysis. They encapsulate business functionality and
for all practical purposes can be treated as black boxes.
·
All validations are performed within the operations
·
All entity relations are handled within the operations
Invocation of services is
stateless, as service requests don’t depend on each other. Services may be
fine- or coarse-grained depending upon the business processes. However fine-grained calls to a service, over
a network can increase network chatter and clog the network.
3.2 Using EJBs (Key facts to
analyze prior to using
EJBs are not supported in some organizations. In considering the support of EJBs for future projects, the following may be helpful:
Stateless Session Beans should be considered where there is
a need to manage distributed transactions if the following apply [5]
·
Participating systems are XA compliant
·
Transactions are "very short lived"
·
You want your transaction to fail if any of the participating
systems is unavailable
·
All systems have an equal say in rejecting the transaction
A messaging based
store-and-forward approach should be considered (instead of Stateless Session
Beans), if you want the transaction to succeed as long as the primary system is
up, and if it is OK for other secondary systems to catch up later. This is based on the assumption that the
secondary or downstream systems cannot reject or veto the transaction.
Message Driven
Beans should be considered if your application needs to respond to events /
messages generated by a remote server. MDBs are a better alternative to standalone JMS listeners
and custom dispatch code, especially when it comes to managing transactions and
parallel processing of several messages.
Entity Beans
are not recommended. This is primarily
on account of performance considerations and lack of any tangible benefit over
using a Remote Invocation Framework for remoting and
Persistence Framework for persistence.
In some cases EJBs are a good fit for an application based on the above
criteria. Organizations need to evaluate
the applicability and justify support for EJBs in
their environment [5].
3.3 Guidelines for JMS
JMS, like JDBC
and JNDI, is a Java specification and not a product, for messaging middleware. It defines an enterprise messaging API that
makes it easy to write business applications that can exchange business, data
and events asynchronously reliably and flexibly [7].
Portability is
a big advantage for JMS applications, as JMS applications aren't tied to one
vendor-proprietary API.
The JMS
clients are loosely coupled and asynchronous, thus giving enterprise
applications the flexibility when implementing the business processes. Neither JMS client needs to be aware of the
other, nor must they be running simultaneously for messages to be
exchanged. JMS clients don't communicate
directly but via the destination service provided by the JMS provider. Producers send messages to a destination,
where they are held until consumers retrieve messages or the messages expire
[8].
Even though
the communications between JMS clients are asynchronous, the communication
between producers and a JMS provider are synchronous, and the communication
between consumers and a JMS provider are synchronous or asynchronous.
When JMS
clients send or receive messages from JMS provider destinations, they go
through a receive-acknowledge handshake.
Example of Asynchronous Communication:
1. An order-entry application
can use JMS to place a message containing order information on a JMS queue and
can continue processing without waiting for the message to be processed by the
Sales/Order Processing/Fulfillment applications.
2. Applications can use
JMS to provide monitoring and logging services separately from mission critical
services. This gives applications asynchronous logging that can decouple client
application from the log service.
JMS messages
can be marked as either persistent or non-persistent. In both cases, a JMS provider will attempt to
deliver the message to the consumer until the JMS consumer either receives the
message and acknowledges it, or until the message expires.
The difference
between a persistent and a non-persistent message is significant, yet subtle.
If a message
is marked as persistent, the JMS provider saves the message on the disk before
acknowledging to the message producer and uses a store-and-forward mechanism.
In
non-persistent messaging, the JMS provider doesn't save the message to disk
before sending an acknowledgment to the message producer. [8].
There are
three component of guaranteed delivery [8]:
Message autonomy: Message itself is an autonomous
self-contained entity. Once the sender
sends the message the JMS server guarantees that any other interested parties
will receive the message.
Message persistence (Store
and Forward): JMS server has
configurable persistence mechanism for storing the message until it has been
deliver to the recipient.
Message acknowledgement: The messaging JMS server works with both the
clients i.e. message producer and message consumer for message acknowledgement,
thereby guaranteeing the receipt of the message.
4. Conclusion
In this paper I
have addressed important architecture topics, technologies and development
steps that one should consider in a J2EE project. The information was taken from real-world
experiences, and is intended to help developers build J2EE systems.
This, however,
is just the tip of the iceberg, as no short paper could begin to do justice to
J2EE's potential impact on an enterprise application.
I focused my attention on
the technologies that people are most likely to encounter when working with
J2EE. Whether you are a developer,
business analyst, or project manager, you now should have a good idea of what
J2EE has to offer you and your enterprise applications.
In a world of
constantly changing technology requirements, J2EE is the way to enable the
Nowadays
software developers need to be able to develop truly scalable and distributed
enterprise server applications. The
ultimate goal is to deliver a complete J2EE solution that satisfies our
customer's requirements.
References
1.
Boranbayev A.S. Development of E-business websites using a multi-tiered architecture and J2EE // Материалы VI
Казахстанско-Российской международной научно-практической конференции
“Математическое моделирование научно-технологических и экологических проблем в
нефтегазодобывающей промышленности”. -Астана, 2007, с.87-91.
2. Java Platform, Enterprise
Edition from Wikipedia: http://en.wikipedia.org/wiki/Java_Platform,_Enterprise_Edition
3. Sun Developers Network
(SDN) J2EE 1.4 Specification: http://java.sun.com/javaee/index.jsp
4. Sun Microsystems Servlet specification: http://java.sun.com/products/servlet/
5. Sun Microsystems EJB
specification: http://java.sun.com/products/ejb/docs.html
6. Top-down and bottom-up
design, from Wikipedia: http://en.wikipedia.org/wiki/Top-down#Software_development
7. Sun Microsystems JMS
specification: http://java.sun.com/products/jms/
8. Java Message Service (JMS)
API from Wikipedia, the free encyclopedia:
http://en.wikipedia.org/wiki/Java_Message_Service