Adoption of Latest Frameworks & APIs For The Development of Enterprise Application in The Software Industry Using Java Platform

Adoption of Latest Frameworks & APIs for the development of MS Research Survey
Enterprise Application in the Software Industry using Java Platform By: Muhammad Ali Ameer – MS-SPM (06-0802)
National University of Computer Emerging Sciences – FAST, Karachi
Java Platform, Enterprise Edition or Java EE is a widely used platform for server side programming in
the Java programming language. The Java EE Platform differs from the Standard Edition (SE) of Java in
that it adds additional libraries which provide functionality to deploy fault‐tolerant, distributed, multi‐
tier Java software, based largely on modular components running on an application server.
Due to ever increasing enterprise level requirements i.e. accessing application from different
geographical locations and catering huge corporate business domains which cause integration with
legacy systems and other solutions in the form of thirdy party libraries, tools and web services, the Java
Community has been involved in meeting these enterprise needs and demands by developing and
adapting different frameworks and APIs to architect the design of scalable, robust, extensible and more
manageable enterprise applications.
A framework is a basic conceptual structure used to solve or address complex issues. A software
framework is a re‐usable design for a software system (or subsystem). A software framework may
include support programs, code libraries, a scripting language, or other software to help develop and
glue together the different components of a software project. Various parts of the framework are
usually exposed through APIs.
This research and survey document focuses on the following areas which are related to Enterprise Web
Applications:
• Enterprise Java Frameworks like Java Server Faces ‐ JSF, Tapestry, Struts, Hibernate (along
with Java Persistence API – JPA, Java Data Objects – JDO and Java Transaction API JTA)
and Spring.
Frameworks like JSF and Struts are based on Model View Controller Architecture (MVC) for
building HTML forms, validating their values, invoking business logic, and displaying
results. The focus is to separate Presentation/View – User Interfaces from Model/Business
Processes & Data.
JSF provides many prebuilt HTML‐oriented GUI controls, along with code to handle their
events.

Tapestry is an open‐source framework for creating dynamic, robust, highly scalable web
applications in Java. Tapestry complements and builds upon the standard Java Servlet API,
and so it works in any servlet container or application server. Tapestry is specifically
designed to make creating new components very easy, as this is a routine approach when
building applications. The distribution includes over fifty components, ranging from simple
output components all the way up to complex data grids and tree navigators. Tapestry is
architected to scale from tiny applications all the way up to massive applications consisting
of hundreds of individual pages, developed by large, diverse teams. Tapestry easily
integrates with any kind of back‐end, including JEE, HiveMind and Spring.

Hibernate works on Object Relational Mapping i.e. to map business objects and models to
physical database objects and to persist data stored in those models without writing any
RDBMS specific Data Manipulation Language Queries.

Page 1 of 29
Spring is a layered JEE application framework includes the most complete lightweight
container, a common abstraction layer for transaction management, a JDBC abstraction
layer, Integration with Toplink, Hibernate, JDO, and iBATIS SQL Maps, AOP functionality,
a flexible MVC web application framework.
• How these frameworks ease out Enterprise Application development which not only cut down
development & maintenance cycle but facilitate re‐usability, separation and development of
scalable applications.
• How Software firms evaluate these frameworks for their adoption in specific enterprise
applications and what benefit they will eventually get.
The frameworks mentioned above like JSF, Struts, Tapestry, Spring and Hibernate fall in t broad
category of famous Design Patterns of Enterprise Application Architecture:
Web Presentation Patterns Data Source Architectural Patterns
based on Model‐View Controller Pattern based on Patterns like Table Data Gateway,
JSF, Struts, Tapestry & Spring Row Data Gateway, Active Record & Data
Mapper
Hibernate, APIs like JDO, JPA & JTA
The first part of the document will discuss about the technicalities of frameworks that are based on
Web Presentation Patterns, how they facilitates Enterprise Application Development and how
Software Development Organizations evaluate then for their adoption in specific enterprise
applications & what benefit they eventually get.
Page 2 of 29
1. Frameworks based on Web Presentation Patterns
1.1. Struts Framework
Struts is the most famous and widely used & accepted enterprise application framework
on JEE platform. It is based on Model‐View Controller (MVC) Architecture.
Struts 2 Architecture
Page 3 of 29

The Request Initiation
The request‐response cycle starts and finishes from the user’s web browser. A URL that represents an
action can be entered as a URL directly into the browser’s address bar, or it can be generated by the
framework when the user clicks on a link or submits a form. The URL will look something like
http://localhost:8080/app/index.action.
Configuration files for the web application determine which URLs are handled by the
Struts2 framework and which aren’t. Usually, all requests for an entire web context or installed
application are forwarded to the Struts2 servlet filter, and it makes the decision.

The Struts2 Servlet Filter
When requests are received at the servlet container, they are forwarded to either a servlet or a filter
that will handle processing the request. In Struts2, a filter is used, and the class for handling the request
is the FilterDispatcher class.
The filter and a Dispatcher class (to which many of the tasks are delegated) are the heart of the Struts2
framework. Together, they provide access to the infrastructure that will be needed to process the
request. Upon startup, implementations of configurable elements in the framework, including
ConfigurationManager, ActionMapper and ObjectFactory are loaded. With respect to processing the
request, the Struts2 filter performs the following:

• Serves static content: Dojo content, JavaScript, and user configurable files can be served from the
Struts2 or the web application’s JAR file, allowing all the elements for a web application to be packaged
together.

• Determines the action configuration: The filter uses the ConfigurationManager and the
ActionMapper implementations to determine which action maps to the URL from the incoming request;
by default, actions are determined by looking for an action extension.

• Creates the action context: Because actions are generic and not specific to HTTP, the information
contained in the web request needs to be converted to a protocol independent format for the actions to
use; this includes extracting data from the HttpServletRequest and the HttpSession objects.

• Creates the action proxy: There is an additional layer of indirection in the processing in the form of
an ActionProxy class. This class contains all the configuration and context information to process the
request and will contain the execution results after the request has been processed.

• Performs cleanup: To ensure that no memory leaks occur, the filter automatically performs
cleanup of the ActionContext object. When the ActionProxy class instance is created and configured, the
execute() method is invoked. This signals that the preparation of the action is complete, and the real
processing of the action is about to start.

The Action Invocation
The ActionInvocation object manages the execution environment and contains the conversational state
of the action being processed. This class is the core of the ActionProxy class. The execution
environment is made up of three different components: actions, interceptors and results.
In addition to these elements, actions can have methods configured as life cycle callbacks. The
ActionInvocation class invokes these callback methods at the appropriate times.

Page 4 of 29
The Action
One of the first tasks that the ActionInvocation performs is to consult the configuration being used and
to create an instance of the action. Unlike Struts and other frameworks that reuse action instances,
Struts2 creates a new action object instance for each and every request that is received. There is a slight
performance overhead with this approach, but the advantage gain is that the object can behave as a
Plain Old Java Object (POJO).

Interceptors
Interceptors provide a simple way to add processing logic around the method being called on the
action. They allow for cross‐functional features to be applied to actions in a convenient and consistent
way, avoiding the need for adding code to each and every action that over time would create additional
maintenance overhead. The functionality is similar to that provided by servlet filters and the JDK Proxy
object. Each action will have many interceptors configured. These interceptors are invoked in the order
that they are configured. After they are all applied to the request, the actions method that processes
the logic for the request is called. By convention, this is the execute() method; however, any no‐
argument method in the class that returns a String or a Result object may be used.
After the action logic is executed, the call returns through the configured interceptors in the reverse
order, allowing for post processing of the action.

The Results
After the processing of the action is complete, the method of the action class that processes the
request returns a String as the result, which is mapped via configuration to an implementation of the
Result interface, or the action can directly return a Result object instance. The Result interface is very
similar to an action class; it contains a single method that generates a response for the user. The
response generated can vary dramatically between different concrete class implementations (know as
result types). It could modify the HTTP response codes, generate a byte array for an image, or render a
JSP. When returning a String as the result, the default configured Result implementation renders JSPs
to the user.
The final step is to return the response (if one is generated) back to the user, which completes the
current request processing cycle.

Page 5 of 29
Struts 2 – The Core Components

The interactions and relationships between Struts 2 core components

Actions
Actions are the core of the Struts2 framework, as they are for any MVC (Model View Controller)
framework. Each URL is mapped to a specific action, which provides the processing logic necessary to
service the request from the user.
The only requirement for actions in Struts2 is that there must be one no‐argument method that returns
either a String or Result object. If the no‐argument method is not specified, the default behavior is to
use the execute() method. Otherwise, an additional configuration to specify the method name is
needed.
When the result is a String object, the corresponding Result is obtained from the action’s configuration
and instantiated. This is then used to generate a response for the user. Even though there is no
requirement that an action implements an interface or extends another class, sometimes it makes
sense to extend helper classes or interfaces. Struts2 provides two such helpers that can be used.

The first helper is the Action interface. This interface does nothing more than supply the common
string‐based return values as constants and enforce that implementing classes provide the default
execute() method.
The ActionSupport class is more interesting. It implements the Action interface and provides an
implementation for the execute() method that returns the SUCCESS value.
Page 6 of 29
Four other interfaces are also implemented. The Validateable and ValidationAware interfaces provide
support for validation. These allow the action to provide programmatic, annotation‐based, and
declarative XML‐based validation. The TextProvider and LocaleProvide interfaces provide support for
localization and internationalization.

Interceptors
Interceptors allow for crosscutting functionality to be implemented separately from the action as well as
the framework. This makes the core framework code leaner than it may have originally been and able
to adapt to new framework features much faster. In fact, the loose coupling means that users no longer
have to wait for the framework to implement the new feature they require; instead, they can
implement and apply the needed features themselves without modifying the underlying framework
source code.

Using interceptors, the following can be achieved:

• Providing preprocessing logic before the action is called.

• Interacting with the action, providing execution information, such as Spring‐managed objects, and
setting the request parameter on the action.

• Providing post‐processing logic after the action is called.

• Modifying the result being returned, hence changing what is rendered to the user.

• Catching exceptions so that alternate processing can be performed or a different result can be
returned.

The Value Stack and OGNL
The Value Stack is a central concept in the Struts2 framework. All of the core components interact with
it in one way or another to provide access to context information as well as to elements of the
execution environment.
Underneath, the Value Stack is exactly what it says—a stack implementation. However, there are
differences between a traditional stack implementation and the Value Stack. The first difference is that
the contents of the stack are made up of four levels:

• Temporary objects: These objects need temporary storage during the processing of a request, for
example, the current element in a collection that is being iterated over.

• Model object: When the action implements the ModelDriven interface, the model object is placed on
the stack in front of the action that is being executed; this level will not be present if the interface is not
implemented by the action.

• Action object: This is the action that is currently being executed.

• Named objects: Any object can be assigned an identifier, making it a named object. Named objects
can be developer created but also included are #application, #session, #request, #attr, and parameters
— each corresponding to an equivalent HTTP scoped object collection.

Page 7 of 29
Another difference is how the stack is used. Traditionally, when using a stack, objects can be pushed on
and popped off when wanted to use them. The Value Stack uses OGNL (Object Graph Navigational
Language) syntax for searching or evaluating a particular expression.
Like other expression languages, such as JSTL (JSP Standard Tag Library) or MVEL (MVFLEX
Expression Language), OGNL provides a mechanism to navigate object graphs using a dot notation and
evaluate expressions, including calling methods on the objects being retrieved.
Searching is also not something that is generally associated with stacks. For the Value Stack, the OGNL
expression is tested at each level, in the order they are listed at the start of the section. If the expression
can be evaluated, the result is returned. Otherwise, the next level down is tested. When all the levels
have been exhausted, and a result still cannot be evaluated, a null value is returned.
Results and Result Types
After an action has been processed, it’s time to send the resulting information back to the user.
In Struts2, this task is split into two parts: the result type and the result itself.
The result type provides the implementation details for the type of information that is returned to the
user. Result types are usually preconfigured in Struts2 or provided via plug‐ins, but developers can
provide custom result types as well. Configured as the default result type is the dispatcher, which uses a
JSP to render the response to the user. After a result type is defined, it can be used many times by
different action results.

Tag Libraries
Tag libraries provide the intersection between actions and views, allowing dynamic information from
the actions to be rendered as well as making rendering decisions on the information to display at
runtime. This is nothing unusual, and tag libraries in one form or another are available in most web
application frameworks.
The difference between the Struts2 tag libraries and other tag libraries (such as JSTL) is that the Struts2
tag libraries have a tight integration with the framework. They take full advantage of the Value Stack to
access action methods, and they take advantage of OGNL to evaluate expressions, project into
collection properties, and perform on‐the‐fly object creation and collection generation.

The four different categories for tag libraries are listed here:

• Control tags: This group provides tags that control what information is rendered in the final view, as
well as ways to manipulate collections of elements that can then be further utilized.

• Data tags: This group provides tags that render dynamically generated information (such as data)
from the action that has just executed, internationalized text, and generated URLs and links. They can
also provide debug information for the developer.

• Form tags: This group provides wrappers for HTML form tags, as well as additional user interface
widgets. They include the option transfer group, date and time pickers, and check box lists.

• Nonform tags: The tags in this group are used in forms but are not directly form entry elements.
They include error message displays, tabbed panels, and tree views.

The biggest difference between the Struts2 tag libraries and other tag libraries is in the architecture.

Page 8 of 29
The MVC structure of Struts2 tag libraries

Following are the three main components that make up the Struts2 tag architecture:

Model: The model component in the diagram is the Component class. For tags that are form
elements or those that provide a great deal of HTML, there is also the UIBean class. The UIBean class
provides additional features to allow the tag’s specific Freemarker rendering templates to be merged
into the output stream. Each new tag requires a model class to be implemented that extends one of
these two classes. The class is simple, providing the getters and setters for properties that are available
to be used. The parent Component class has access to the Value Stack for retrieving extra parameters
or for when OGNL expressions need to be evaluated.

View: The view consists of either one or two templates (by default, these are Freemarker templates);
only one needs to be specified if the tag doesn’t have enclosed tags. The templates provide a
mechanism to keep formatting away from the logic and a way to change what is presented to the user
on a per‐project basis without recompiling the framework.

Controller: The controller allows tags to be accessed via JSP, Velocity, or Freemarker result templates.
This is a major deviation from traditional tags. Normally, tag libraries are available to JSP templates but
not to other view technologies. Struts2 fixes this by making tag library objects available in non‐JSP
templates. For each view technology that we want to support, a new subclass of TagModel,
AbstractDirective, or ComponentTagSupport needs to be created. These classes provide a custom
mechanism to populate the necessary fields in the model object.

Page 9 of 29
1.2 Tapestry Framework
Tapestry is a component‐based web application framework, written in Java. Tapestry is more
than a simple templating system; Tapestry builds on the Java Servlet API to build a platform for
creating dynamic, interactive web sites. More than just another templating language, Tapestry is a real
framework for building complex applications from simple, reusable components. Tapestry offloads
much of the error‐prone work in creating web applications into the framework itself, taking over
mundane tasks such as dispatching incoming requests, constructing and interpreting URLs encoded
with information, handling localization and internationalization and much more besides.
Why is Tapestry Special?
Tapestry is a framework that was created keeping the developer in mind. First of all, its paradigm is
very close to that of the RAD environment. A button on the Tapestry page has an event handler
method associated with it in a declarative way, and the method is invoked when the button is pressed.
The Tapestry web developer doesn't need to remember that the button on the page in a user's web
browser and the code of the event handler method on the web server can be thousands miles apart,
and doesn't need to care about which communication protocol is being used. This natural approach
makes Tapestry significantly easier to learn than any other web development framework, and it makes
the process of development much more efficient. However, there are a number of other attractive
features, the combination of which makes Tapestry unique.
Perhaps the hardest part of understanding Tapestry is the fact that it is component‐centric not
operation‐centric. Most web technologies (Struts, Servlets, PHP, etc.) are operation‐centric. We create
Servlets or Actions that are invoked when a user clicks a link or submits a form. We are responsible for
selecting an appropriate URL, and the name and type of any query parameters, so that we can pass
along the information we need in the URL. We are also responsible for connecting our output pages
(whether they are JSPs, Velocity templates, or some other form of templating technology) to those
operations. This requires us to construct those URLs and get them into the href attribute of our <a>
(hyperlinks) tag, or into the action attribute of our <form> tag.
Everything is different inside Tapestry. Tapestry applications consist of pages; pages are constructed
from smaller components. Components may themselves be constructed from other components. Every
page has a unique name, and every component within a page has its own unique id. This is a component
object model. Effectively, every component has an address that can easily be incorporated into a URL.

Page 10 of 29

Request – Response Cycle in Tapestry Framework

Tapestry Application is a set of Interactive Pages
It is natural for a user of a web application to think of it as a set of pages. The user might click on a
button, select a value in a drop‐down list or do something else, and the page would display different
data, or even a completely different page might be shown by the application as a result of user actions.
The design of Tapestry is very close to this natural paradigm, as a Tapestry application actually consists
of a number of Tapestry pages. A Tapestry page is quite a clever entity. It remembers the values
entered by the user, and if the user initiates some action, like clicking on a link or clicking on a button,
the page will react to that action by running an appropriate fragment of code—an event handler
method. It is for developers to decide what kind of code it will be and how it will use the input provided
by the user.
This will sound very familiar to those who have experience of developing desktop applications with
some Rapid Application Development environments, such as Borland Delphi or Microsoft Visual Basic.
However, web applications are very different from desktop applications, and although working with
Tapestry we do not need to deal with complexities that arise from this difference, it is useful to
understand how things work, at least in general terms.
Tapestry Pages are Pooled
Tapestry was designed with great scalability in mind. This means that a Tapestry application should be
able to easily handle a huge amount of concurrent users, and for this, it should spend minimal efforts to
serve every individual request.
Page 11 of 29
Say, a user requests the Start page. Should Tapestry create an instance of this page especially for this
user and discard it as soon as the user will go to another page? This wouldn't be efficient, as the next
moment, twenty other users will come and request an instance of the Start page. It would be
reasonable not to discard, but to reuse the instance that was just used for the first user. However, there
is a potential problem. The page might have some sensitive data put into it by the first user—say a
password, or anything else. To avoid this problem, Tapestry will wipe clean the instance used by the
first user before giving it to any other user. It will reset all variables on the page class to their initial
values.

In reality, Tapestry maintains a pool of instances for every page, and when a page is requested, it takes
an instance from the appropriate pool to serve that request, and then returns the instance to its pool. At
the end of the request, Tapestry will wipe clean the variables of the instance of any user‐specific data.
This mechanism makes Tapestry very efficient. But we have to remember that even if we think that we
are dealing with the same page, in most cases the page will be represented by a different instance (may
be even coming from a completely different server, in a clustered environment), and the next instance
will have no idea of what we have just told the previous instance. That is, unless we take special care
and make sure that the information is passed between instances properly.
What happened when we tried to pass a message to the Another page is that we took an instance of it,
and put our message into it. Then we told Tapestry to show the Another page to this user. What
Tapestry 5 does is that it tells the user's browser that it has successfully handled user’s submission; now
go on. When the browser requests for the Another page, it takes a fresh instance of that page from the
pool and uses it to produce the output. Unfortunately, that fresh instance will know nothing about the
message we wanted to pass.
So how can we make our application work with all this instance pooling? Should there be a way to make
Tapestry remember the information we have put into the page, no matter which instance of that page
is being used?
There are actually two approaches to this:
• We can make a page field persistent. This is a very simple approach, but it has some downsides.
• We can use page activation context. This is a superior approach, but not for every case, and it
involves more coding.
The Engine is a central object, it occupies the same semantic space in Tapestry that the HttpSession
does in the Servlet API. The Engine is ultimately responsible for storing the persistent state of the
application (properties that exist from one request to the next), and this is accomplished by storing the
Engine into the HttpSession. Engine services are the bridge between Servlets and URLs and the rest of
Tapestry. Engine services are responsible for encoding URLs, providing query parameters that identify,
to the framework, the exact operation that should occur when the generated URL is triggered (by the
end user clicking a link or submitting a form). Services are also responsible for dispatching those
incoming requests. This encapsulation of URL encoding and decoding inside a single object is key to
how Tapestry components can flexibly operate without concern for how they are contained and on
which page the services take into account page and location when formulating URLs.
Page 12 of 29
The Visit object is an application‐defined object that acts as a focal point for all server‐side state (not
associated with any single page). Individual applications define for themselves the class of the Visit
object. The Visit is stored as a property of the Engine, and so is ultimately stored persistently in the
HttpSession.
The Global object is also application‐specific. It stores information global to the entire application,
independent of any particular user or session. A common use for the Global object is to centralize logic
that performs JNDI lookups of session EJBs.
Tapestry is tightly integrated with OGNL, the Object Graph Navigation Language. OGNL is a Java
expression language, which is used to peek into objects and read or update their properties. OGNL is
similar to, and must more powerful than, the expression language built into the JSP 2.0 standard tag
library. OGNL not only support property access, it can include mathematical expressions and method
invocations. It can reference static fields of public classes. It can create new objects, including lists and
maps. OGNL is primarily used to allow two different objects (such as a page and a component
contained by that page) to share information.
Page 13 of 29
1.3. Spring Framework
The Spring Framework is an open source lightweight application framework that aims to make
JEE development easier. Unlike single‐tier frameworks such as Struts or Hibernate, Spring aims to help
structure whole applications in a consistent, productive manner, pulling together best‐of‐breed single‐
tier frameworks to create a coherent architecture. Since Spring is a lightweight framework, it not only
aims to reduce complexity in application code, but avoid unnecessary complexity in their own
functioning. So it doesn’t have a high startup time, doesn’t involve huge binary dependencies, will run
in any environment, and doesn’t place obstacles in the way of testing.
Spring is both the most popular and most ambitious of the lightweight frameworks. It is the
only one to address all architectural tiers of a typical JEE application, and the only one to offer a
comprehensive range of services, as well as a lightweight container. The following are the key Spring
modules:
Inversion of Control container: The core "container" Spring provides, enabling sophisticated
configuration management for POJOs. The Spring IoC container can manage fine or coarse‐
grained POJOs (object granularity is a matter for developers, not the framework), and work
with other parts of Spring to offer services as well as configuration management.
Aspect‐Oriented Programming (AOP) framework: AOP enables behavior that would
otherwise be scattered through different methods to be modularized in a single place. Spring
uses AOP under the hood to deliver important out‐of‐the‐box services such as declarative
transaction management. Spring AOP can also be used to implement custom code that would
otherwise be scattered between application classes.
Data access abstraction: Spring encourages a consistent architectural approach to data
access, and provides a unique and powerful abstraction to implement it. Spring provides a rich
hierarchy of data access exceptions, independent of any particular persistence product. It also
provides a range of helper services for leading persistence APIs, enabling developers to write
persistence framework–agnostic data access interfaces and implement them with the tool of
their choice.
JDBC simplification: Spring provides an abstraction layer over JDBC that is significantly simpler
and less error‐prone to use than JDBC when we need to use SQL‐based access to relational
databases.
Transaction management: Spring provides a transaction abstraction that can sit over JTA
"global" transactions (managed by an application server) or "local" transactions using the JDBC,
Hibernate, JDO, or another data access API. This abstraction provides a consistent
programming model in a wide range of environments and is the basis for Spring's declarative
and programmatic transaction management.
MVC web framework: Spring provides a request‐based MVC web framework. Its use of shared
instances of multithreaded "controllers" is similar to the approach of Struts, but Spring's web
Page 14 of 29
framework is more flexible, and integrates seamlessly with the Spring IoC container. All other
Spring features can also be used with other web frameworks such as Struts or JSF.
Simplification for working with JNDI, JTA, and other J2EE APIs: Spring can help remove the
need for much of the verbose, boilerplate code that "doesn't do anything." With Spring, we can
continue to use JNDI or EJB, if we want, but we'll never need to write another JNDI lookup.
Instead, simple configuration can result in Spring performing the lookup on our behalf,
guaranteeing that resources such as JNDI contexts are closed even in the event of an exception.
Lightweight remoting: Spring provides support for POJO‐based remoting over a range of
protocols, including RMI, IIOP, and Hessian, Burlap, and other web services protocols.
JMS support: Spring provides support for sending and receiving JMS messages in a much
simpler way than provided through standard J2EE.
JMX support: Spring supports JMX management of application objects it configures.
Support for a comprehensive testing strategy for application developers: Spring not only
helps to facilitate good design, allowing effective unit testing, but provides a comprehensive
solution for integration testing outside an application server.
Spring’s Value
The key Spring values can be summarized as follows:
Spring is a non‐invasive framework. This is the key departure from most previous frameworks.
Whereas traditional frameworks such as EJB or Apache Avalon force application code to be aware of
the framework, implementing framework‐specific interfaces or extending framework‐ specific classes,
Spring aims to minimize the dependence of application code on the framework. Thus Spring can
configure application objects that don't import Spring APIs; it can even be used to configure many
legacy classes that were written without any knowledge of Spring. This has many benefits. For
example:
Application code written as part of a Spring application can be run without Spring or any other
container.
Lock‐in to Spring is minimized. For example, we could migrate to another lightweight container, or
possibly even reuse application objects in an EJB 3.0 EJB container, which supports a subset of Spring's
Dependency Injection capability.
Migration to future versions of Spring is easier. The less code depends on the framework, the greater
the decoupling between the implementation of our application and that of the framework. Thus the
implementation of Spring can change significantly without breaking code, allowing the framework to
be improved while preserving backward compatibility.
Page 15 of 29
Of course in some areas, such as the web framework, it's impossible to avoid application code
depending on the framework. But Spring consistently attempts to reach the non‐invasive ideal where
configuration management is concerned.
Spring provides a consistent programming model, usable in any environment. Many web
applications simply don't need to run on expensive, high‐end, application servers, but are better off
running on a web container such as Tomcat or Jetty. It's also important to remember that not all
applications are server‐side applications. Spring provides a programming model that insulates
application code from environment details such as JNDI, making code less dependent on its runtime
context.
Spring aims to promote code reuse. Spring helps to avoid the need to make some important hard
decisions up front, like whether our application will ever use JTA or JNDI; Spring abstractions will allow
to deploy our code in a different environment if we ever need to. Thus Spring enables us to defer
architectural choices, potentially delivering benefits such as the need to purchase an application server
license only when we know exactly what our platform requirements are, following tests of throughput
and scalability.
Spring aims to facilitate Object Oriented design in JEE applications. In reality, many JEE
applications do not deserve the name of OO applications. Spring aims to remove some of the
impediments in place of OO in traditional designs.
Spring aims to facilitate good programming practice, such as programming to interfaces, rather
than classes. Use of an IoC container such as Spring greatly reduces the complexity of coding to
interfaces, rather than classes, by elegantly concealing the specification of the desired implementation
class and satisfying its configuration requirements. Callers using the object through its interface are
shielded from this detail, which may change as the application evolves.
Spring promotes pluggability. Spring encourages to think of application objects as named services.
Ideally, the dependencies between such services are expressed in terms of interfaces. Thus we can
swap one service for another without impacting the rest of our application. The way in which each
service is configured is concealed from the client view of that service.
Spring facilitates the extraction of configuration values from Java code into XML or properties
files. While some configuration values may be validly coded in Java, all nontrivial applications need
some configuration externalized from Java source code, to allow its management without
recompilation or Java coding skills. Spring encourages developers to externalize configuration that
might otherwise have been inappropriately hard‐coded in Java source code. More configurable code is
typically more maintainable and reusable.
Spring is designed so that applications using it are as easy as possible to test. As far as possible,
application objects will be POJOs, and POJOs are easy to test; dependence on Spring APIs will
normally be in the form of interfaces that are easy to stub or mock. Unlike the case of JNDI, for
example, stubbing or mocking is easy; unlike the case of Struts, for example, application classes are
seldom forced to extend framework classes that themselves have complex dependencies.
Page 16 of 29
Spring is consistent. Both in different runtime environments and different parts of the framework,
Spring uses a consistent approach.
Spring promotes architectural choice. While Spring provides an architectural backbone, Spring aims
to facilitate replaceability of each layer. For example, with a Spring middle tier, we should be able to
switch from one O/R mapping framework to another with minimal impact on business logic code, or
switch from, say, Struts to Spring MVC or WebWork with no impact on the middle tier.
Spring does not reinvent the wheel. Despite its broad scope, Spring does not introduce its own
solution in areas such as O/R mapping where there are already good solutions. Similarly, it does not
implement its own logging abstraction, connection pool, distributed transaction coordinator,
remoting protocols, or other system services that are already well‐served in other products or
application servers. However, Spring does make these existing solutions significantly easier to use, and
places them in a consistent architectural approach.
Relationship to Other Frameworks
Spring does not reinvent the wheel. Spring aims to provide the glue that enables to build a
coherent and manageable application architecture out of disparate components.Spring relates to
some of the many products it integrates with.
Persistence Frameworks
Spring does not provide its own O/R mapping framework. It provides an abstraction over JDBC, but
this is a less painful way of doing exactly the same thing as might otherwise have been done with
JDBC.
Spring provides a consistent architectural model, but allows to choose the O/R mapping framework of
any choice (or an SQL‐based approach where appropriate). For the many applications that benefit
from using O/R mapping, we should integrate an O/R mapping framework with Spring. Spring
integrates well with all leading O/R mapping frameworks. Supported choices include:
Hibernate: The leading open source O/R mapping tool. Hibernate was the first O/R mapping tool for
which Spring offered integration. Spring's Hibernate integration makes Hibernate significantly easier
to use, through the HibernateTemplate we've briefly discussed and through integration with Spring's
transaction management.
JDO implementations: Spring provides support for JDO 1.0 and JDO 2.0 standards. Several JDO
vendors also ship their own Spring integration, implementing Spring's JdoDialect interface, giving
application developers access to common capabilities that go beyond the JDO specification without
locking into a particular JDO vendor.
TopLink: TopLink is the oldest O/R mapping tool on the market, dating back to the mid‐1990s.
TopLink is now an Oracle product, and Oracle has written a Spring integration that enables Spring
users to work as seamlessly with TopLink as with Hibernate or a JDO implementation.
Page 17 of 29
Apache OJB: An O/R mapping product from Apache.
iBATIS: iBATIS SQL Maps is not, strictly speaking, an O/R mapping product. However, it does offer a
convenient way of defining SQL statements in a declarative fashion, mapping objects to statement
parameters and result sets to objects. In contrast to full‐blown O/R mapping solutions, though, SQL
Maps does not aim to provide an object query language or automatic change detection.
All these integrations are consistent in that Spring facilitates the use of DAO interfaces, and all
operations throw informative subclasses of Spring's DataAccessException. Spring provides helpers
such as templates for all these APIs, enabling a consistent programming style. Spring's comprehensive
architectural template means that almost any persistence framework can be integrated within this
consistent approach. Integration efforts from several JDO vendors — the fact that the Spring/TopLink
integration was developed by the TopLink team at Oracle, and that the popular Cayenne open source
O/R mapping project itself developed Spring integration for Cayenne — shows that Spring's data
access abstraction is becoming something of a de facto standard for consistent approach to
persistence in Java/JEE applications.
Spring's own JDBC framework is suitable when we want SQL‐based access to relational data. This is
not an alternative to O/R mapping, but it's necessary to implement at least some scenarios in most
applications using a relational database. (Also, O/R mapping is not universally applicable, despite the
claims of its more enthusiastic advocates.)
Importantly, Spring allows to mix and match data access strategies — for example Hibernate code and
JDBC code sharing the same connection and transaction. This is an important bonus for complex
applications, which typically can't perform all persistence operations using a single persistence
framework.
Web Frameworks
Again, the fundamental philosophy is to enable users to choose the web framework of their choice,
while enjoying the full benefit of a Spring middle tier. Popular choices include:
Struts: Still the dominant MVC web framework (although in decline). Many Spring users use Struts
with a Spring middle tier. Integration is fairly close, and it is even possible to configure Struts Actions
using Spring Dependency Injection, giving them instant access to middle‐tier objects without any Java
coding.
WebWork: Integration with WebWork is particularly close because of WebWork's flexible design and
the strong interest in the WebWork community in using WebWork along with a Spring middle tier. It is
possible to configure WebWork Actions using Spring Dependency Injection.
Spring MVC: Spring's own MVC web framework, which of course integrates particularly well with a
Spring middle tier.
Tapestry: A component‐oriented framework from Apache's Jakarta group, Tapestry integrates well
with Spring because declarative page metadata makes it easy for Tapestry pages to access Spring‐
provided services without any code‐level coupling to Spring.
Page 18 of 29
JSF: Spring integrates very well with JSF, given that JSF has the concept of "named beans" and does
not aim to implement middle‐tier services itself.
Spring's approach to web frameworks differs from that to persistence, in that Spring provides its own
fully featured web framework. Of course, we are not forced to use this if we wish to use a Spring
middle tier. While Spring integrates well with other web frameworks, there are a few integration
advantages available only with Spring's own MVC framework, such as the ability to use some
advanced features of Spring Dependency Injection, or to apply AOP advice to web controllers.
Nevertheless, as Spring integrates well with other web frameworks, we should choose Spring's own
MVC framework on its merits, rather than because there's any element of compulsion. Spring MVC is
an appealing alternative to Struts and other request‐driven frameworks as it is highly flexible, helps to
ensure that application code in the web tier is easily testable, and works particularly well with a wide
variety of view technologies besides JSP.
AOP Frameworks
Spring provides a proxy‐based AOP framework, which is well suited for solving most problems in J2EE
applications.
However, sometimes we need capabilities that a proxy‐based framework cannot provide, such as the
ability to advise objects created using the new operator and not managed by any factory; or the ability
to advise fields, as well as methods.
To support such requirements, Spring integrates well with AspectJ and ApectWerkz, the two leading
class weaving–based AOP frameworks. It's possible to combine Spring Dependency Injection with
such AOP frameworks — for example, configuring AspectJ aspects using the full power of the Spring
IoC container as if they were ordinary classes.
Spring does not attempt to replicate the power of a full‐blown AOP solution such as AspectJ; this
would produce no benefits to Spring users, who are instead free to mix Spring AOP with AspectJ as
necessary to implement sophisticated AOP solutions.
Other Frameworks
Spring integrates with other frameworks including the Quartz scheduler, Jasper Reports, and Velocity
and FreeMarker template engines.
Again, the goal is to provide a consistent backbone for application architecture.
All such integrations are modules, distinct from the Spring core. While some ship with the main Spring
distribution, some are external modules. Spring's open architecture has also resulted in numerous
other projects (such as the Cayenne O/R mapping framework) providing their own Spring integration,
or providing Spring integration with third‐party products.
Page 19 of 29
1.4. Java Server Faces (JSF) Framework
JSF brings a component‐based model to web application development that's similar to the model
that's been used in standalone GUI applications for years. The technology builds on the experience
gained from Java Servlets, JavaServer Pages, and numerous commercial and open source web
application frameworks that simplify the development process. In JavaServer Faces, developers learn
how to use this new framework to build real‐world web applications. JavaServer Faces pays particular
attention to simple tasks that are easily ignored, but crucial to any real application: working with
tabular data, for example, or enabling and disabling buttons.
JSF is new standard framework, developed through Java Community Process (JCP), that makes it easy
to build user interfaces for java web applications by assembling reusable components in a page. We
can think of JSF framework as a toolbox that is full of ready to use components where we can quickly
and easily add and reuse these components many times in a page and capture events generated by
actions on these components. So JSF applications are event driven. We typically embed components
in a jsp page using custom tags defined by JSF technology and use the framework to handle navigation
from one page to another. Components can be nested within another component , for example, input
box, button in a form.
JSF is based on well established Model‐View‐Controller (MVC) design pattern. Applications developed
using JSF frameworks are well designed and easy to maintain then any other applications developed in
JSP and Servlets. JSF eases the development of web applications based on Java technologies.The
followings are some of benefits of using JSF:
• JSF provides standard, reusable components for creating user interfaces for web applications.
• JSF provides many tag libraries for accessing and manipulating the components.
• It automatically saves the form data and repopulates the form when it is displayed at client
side.
• JSF encapsulates the event handling and component rendering logic from programmers,
programmers just use the custom components.
• JSF is a specification and vendors can develop the implementations for JSF.
• There are many GUIs available these days to simplify the development of web based
application based on JSF framework.
The JSF framework is responsible for interacting with client devices, and it provides tools for
tying together the visual presentation, application logic, and business logic of a web application.
However, the scope of JSF is restricted to the presentation tier. Database persistence, web services,
and other backend connections are outside the scope of JSF.
Page 20 of 29
High‐level overview of the JSF framework
JSF connects the view and the modeland operates as the controller that reacts to the user by
processing action and value change events, routing them to code that updates the model or the view.
When the user submits form to the server, the JSF implementation invokes the check method of the
user bean. That method can take arbitrary actions to update the model, and it returns the navigation
ID of the next page to be displayed.
Data conversion— Users enter data into web forms as text. Business objects want data as numbers,
dates, or other data types.
Validation and error handling— JSF makes it easy to attach validation rules for fields such as "this field
is required" or "this field must be a number". Of course, when users enter invalid data, we need to
display appropriate error messages. JSF takes away much of the tedium of this programming task.
Internationalization— JSF manages internationalization issues such as character encodings and the
selection of resource bundles.
Custom components— Component developers can develop sophisticated components that page
designers simply drop into their pages. For example, suppose a component developer produces a
calendar component with all the usual bells and whistles.
Alternative renderers— By default, JSF generates markup for HTML pages. But it is easy to extend the
JSF framework to produce markup for another page description language such as WML or XUL.
Tool support— JSF is optimized for use with automated tools. As these tools mature in the coming
years, we believe that JSF will be the must‐have framework for developing web interfaces with Java.
Page 21 of 29
The JSF life cycle
The Restore View phase retrieves the component tree for the requested page if it was displayed
previously or constructs a new component tree if it is displayed for the first time. If the page was
displayed previously, all components are set to their prior state. This means that JSF automatically
retains form information. For example, when a user posts illegal data that is rejected during decoding,
the inputs are redisplayed so that the user can correct them.
If the request has no query data, the JSF implementation skips ahead to the Render Response phase.
This happens when a page is displayed for the first time.
Otherwise, the next phase is the Apply Request Values phase. In this phase, the JSF implementation
iterates over the component objects in the component tree. Each component object checks which
request values belong to it and stores them.
In the Process Validations phase, the submitted string values are first converted to "local values,"
which can be objects of any type. When we design a JSF page, we can attach validators that perform
Page 22 of 29
correctness checks on the local values. If validation passes, the JSF life cycle proceeds normally.
However, when conversion or validation errors occur, the JSF implementation invokes the Render
Response phase directly, redisplaying the current page so that the user has another chance to provide
correct inputs.
After the converters and validators have done their work, it is assumed that it is safe to update the
model data. During the Update Model Values phase, the local values are used to update the beans that
are wired to the components.
In the Invoke Application phase, the action method of the button or link component that caused the
form submission is executed. That method can carry out arbitrary application processing. It returns an
outcome string that is passed to the navigation handler. The navigation handler looks up the next
page.
Finally, the Render Response phase encodes the response and sends it to the browser. When a user
submits a form, clicks a link, or otherwise generates a new request, the cycle starts anew.
Web Development using JSF
Although JSF is designed to be independent of specific protocols and markup languages, most Java
developers will use it in concert with Java servlets and JSPs to create HTML‐based Web applications.
These applications can communicate with Java application servers via the now ubiquitous and
venerable HTTP. The authors of the JSF specification are aware of this demographic, so one of their
primary goals is to resolve a number of issues related to using the stateless HTTP protocol in concert
with HTML clients. The specification highlights a number of JSF features related to this goal:

UI Component State: JSF specifically addresses saving user interface component state between
requests in a Web client session.

Component Rendering: HTML is just one of many markup languages, and each Web client’s support
of a particular markup language may vary. JSF provides a rendering mechanism for addressing this
variety of target Web clients.

Form Processing: Most Web applications are form‐based. JSF provides a number of convenient
features for processing multipage and single‐page form‐based requests.

Form Validation: Along with form processing, validating form data is a critical need. JSF helps
automate this process and provide the necessary error reporting.

Event Model: JSF provides a strongly typed component event model for responding to client‐
generated events with server‐side handlers.

Type Conversion: Since Web client requests via HTTP provide form data as strings, a mechanism for
converting these strings to and from the application model would be very useful. JSF provides a facility
for enabling type conversion.
Page 23 of 29
Error Handling: All applications must deal with application errors and exceptions. JSF provides a
mechanism for handling error conditions and reporting them back to the user interface.

Internationalization: Multilanguage support is often a key requirement in Web applications, which are
easily accessible from around the world. JSF provides native support of internationalization.

Page 24 of 29
2. Frameworks & APIs based on Data Source Architectural Patterns
2.1. Hibernate Framework
Working with object‐oriented software and a relational database can be cumbersome and time
consuming in today's enterprise environments. Hibernate is an object/relational mapping tool for Java
environments. The term object/relational mapping (ORM) refers to the technique of mapping a data
representation from an object model to a relational data model with a SQL‐based schema.
Hibernate not only takes care of the mapping from Java classes to database tables (and from
Java data types to SQL data types), but also provides data query and retrieval facilities and can
significantly reduce development time otherwise spent with manual data handling in SQL and
JDBC.Hibernates goal is to relieve the developer from 95 percent of common data persistence related
programming tasks. Hibernate may not be the best solution for data‐centric applications that only use
stored‐procedures to implement the business logic in the database, it is most useful with object‐
oriented domain models and business logic in the Java‐based middle‐tier. However, Hibernate can
certainly help us to remove or encapsulate vendor‐specific SQL code and will help with the common
task of result set translation from a tabular representation to a graph of objects.
2.2. Java Data Objects (JDO) API
JDO specifies a persistence service for those objects whose state outlives the lifetime of a single
invocation of a Java Virtual Machine (JVM). Nearly every program saves the state of some objects and
either restores this state on a subsequent invocation or shares it with another concurrently running
program. The state preserved is both the state within objects and the relationships between objects.
JDO is a persistence service because it connects Java objects in memory to the long‐term storage of
their state. By using a service that is concerned only with persistence, applications can isolate the work
of moving state between memory and a datastore to one area of code. Without a persistence service,
the code to interface with the datastore is spread throughout the application. By using JDO, the
application programmer can make persistence a modular component. As a result, the maintainability
of the application improves. It is easier to find bugs, fix them, avoid introducing new bugs, and
upgrade the capabilities of the application.
Although most applications need to persist some objects, not all objects require persistence. Many
objects in a program are simply transient, which means their state is created as needed and discarded
when the program stops executing, if not before. Some objects are transient but use persistent objects
or the information in them. For example, an object that sums the sales figures from a collection of
persistent invoices may itself be transient.
JDO Specifies a Uniform Persistence Service
JDO specifies an Application Programming Interface (API) to a library of services that the
application program can use for persistence. JDO also specifies the persistent services that are
provided transparently to all persistent objects. JDO ships with a reference implementation of this API
that may be suitable for prototype development. Numerous vendors have created new products or
Page 25 of 29
adapted existing products to support the JDO specification. These products will compete against each
other in terms of robustness, performance, supported datastores, support for optional JDO features,
and ease of configuration, flexibility, and so forth.
JDO encapsulates and simplifies the programming issues that are unique to persistent objects. It
provides a service to find, update, and delete existing persistent objects and to store new persistent
objects. It encapsulates the mapping of object state in memory to persistent state in the datastore. It
ensures that multiple changes made to persistent objects in memory are stored in an all‐or‐nothing
fashion in the datastore. Lastly, it allows multiple concurrently executing applications and threads to
share access to the persistent state.
JDO offers a uniform set of persistence services that do not vary with the datastore used or the
deployment environment chosen. JDO implementations can be built for a variety of datastore
architectures, such as files, object databases, relational databases, and generalized transaction
processing services. Because JDO encapsulates the datastore, it allows the application to use the same
set of services regardless of the datastore selected. The uniformity of JDO allows the application to
remain blissfully ignorant of the differences in query languages, data models, and access interfaces
between the various datastores. When it comes to deployment architectures, application code that
uses JDO may be deployed in stand‐alone applications, client/server applications, servlets, and
Enterprise JavaBeans (EJBs). For the most part, the same set of JDO services is available in all of these
environments.
A Large Part of JDO's Persistence Service is Transparent
When using JDO, the application programmer does not write persistence‐related code in the
application data classes—these are the classes that define the objects that have persistent state.
Instead, the programmer creates the application data classes as if persistence were not an issue. He
declares the fields that contain the object's state and writes the methods to access and modify the
state of the object in memory.
JDO requires an enhancement step for all application data classes. The JDO vendor supplies a tool,
called the enhancer, that the programmer uses to add the persistence‐related code to application data
classes. As a result of enhancement, JDO can manage the application data objects as persistent
objects. Because enhancement usually occurs after compilation, persistence‐related code is usually
not visible in the source code of the application data classes.
Transparent persistence is powerful because it requires no coding by the application programmer and
because it imposes few design and coding constraints. When an application uses JDO, persistence
code is effectively absent in the source code of application data classes. Yet, at runtime, the data
objects are alive. They can be fetched from the datastore by queries or identity. If one persistent
object references another, the reference is instantiated transparently when used. When a transaction
is active, the data object's persistent state is transactionally consistent with the datastore, and
modifications made to it will be reflected in the datastore when the transaction is committed.
Page 26 of 29
2.3. Java Transaction API (JTA)
Distributed transaction services in Enterprise Java middleware involve five players:
The transaction manager
The application server
The resource manager
The application program and
The communication resource manager
Each of these players contributes to the distributed transaction processing system by implementing
different sets of transaction APIs and functionalities.
• A transaction manager provides the services and management functions required to support
transaction demarcation, transactional resource management, synchronization, and transaction
context propagation.
• An application server (or TP monitor) provides the infrastructure required to support the application
run‐time environment which includes transaction state management. An example of such an
application server is an EJB server.
• A resource manager (through a resource adapter1) provides the application access to resources. The
resource manager participates in distributed transactions by implementing a transaction resource
interface used by the transaction manager to communicate transaction association, transaction
completion and recovery work. An example of such a resource manager is a relational database server.
• A component‐based transactional application that is developed to operate in a modern application
server environment relies on the application server to provide transaction management support
through declarative transaction attribute settings. An example of this type of applications is an
application developed using the industry standard Enterprise JavaBeans (EJB) component
architecture. In addition, some other stand‐alone Java client programs may wish to control their
transaction boundaries using a high‐level interface provided by the application server or the
transaction manager.
• A communication resource manager (CRM) supports transaction context propagation and access to
the transaction service for incoming and outgoing requests. The JTA document does not specify
requirements pertained to communication.
From the transaction manager’s perspective, the actual implementation of the transaction
services does not need to be exposed; only high‐level interfaces need to be defined to allow transaction
demarcation, resource enlistment, synchronization and recovery process to be driven from the users of
the transaction services. The purpose of JTA is to define the local Java interfaces required for the
Page 27 of 29
transaction manager to support transaction management in the Java enterprise distributed computing
environment.
Relationship to Other Java APIs
Enterprise JavaBeans
The Enterprise JavaBeans architecture requires that an EJB Container support application‐level
transaction demarcation by implementing the javax.transaction.UserTransaction interface. The
UserTransaction interface is intended to be used by both the EJB Bean implementer (for
TX_BEAN_MANAGED Beans) and by the client programmer who wants to explicitly demarcate
transaction boundaries within programs that are written in the Java programming language.
Page 28 of 29
JDBC 2.0 Standard Extension API
One of the new features included in the JDBC 2.0 Extension Specification is support for distributed
transactions. Two new JDBC interfaces have been created for JDBC drivers to support distributed
transactions using the Java Transaction API’s XAResource interface. The new JDBC 2.0 interfaces are
javax.sql.XAConnection and javax.sql.XADataSource. A JDBC driver that supports distributed
transactions implements the javax.transaction.xa.XAResource interface, the javax.sql.XAConnection
interface, and the javax.sql.XADataSource interface.
Java Message Service
The Java Transaction API may be used by a Java Message Service provider to support distributed
transactions.AJMS provider that supports the XAResource interface is able to participate as a resource
manager in a distributed transaction processing system that uses a two‐phase commit transaction
protocol. In particular, a JMS provider implements the javax.transaction.xa.XAResource interface, the
javax.jms.XAConnection and the javax.jms.XASession interface.
Java Transaction Service
Java Transaction Service (JTS) is a specification for building a transaction manager which supports the
JTA interfaces at the high‐level and the standard Java mapping of the CORBA Object Transaction
Service 1.1 specification at the low‐level. JTS provides transaction interoperability using the CORBA
standard IIOP protocol for transaction propagation between servers. JTS is intended for vendors who
provide the transaction system infrastructure for enterprise middleware.
Page 29 of 29

Adoption of Latest Frameworks & APIs For The Development of Enterprise Application in The Software Industry Using Java Platform

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Adoption of Latest Frameworks & APIs For The Development of Enterprise Application in The Software Industry Using Java Platform

Caricato da

Copyright:

Formati disponibili

Adoption of Latest Frameworks & APIs for the development of MS Research Survey

Potrebbero piacerti anche