Académique Documents
Professionnel Documents
Culture Documents
0 Vs Spring
Priya Thinagar
CEO, X ON Technologies LLC
Contents
1
Introduction.............................................................................................5
1.1
1.2
Overview ....................................................................................................6
Concepts of Spring Framework .................................................................6
2.2.1Inversion of Control ............................................................................................6
2.2.2Dependency Injection ........................................................................................6
2.2.3Auto wiring .........................................................................................................7
2.2.4Aspect Oriented Programming (AOP)................................................................7
2.3 Architectural benefits of Spring Framework ...............................................7
2.4 Summary....................................................................................................8
EJB 3.0.....................................................................................................9
3.1
Overview ....................................................................................................9
3.1.1High lights of Java EE 5.....................................................................................9
3.2
3.3
3.4
4.2
Conclusion ...............................................................................................16
5.1.1Use Spring if:....................................................................................................16
5.1.2Use EJB 3 if: ....................................................................................................16
5.2
Recommendations ...................................................................................17
Appendix A. ...................................................................................................18
5.3
5.4
References...............................................................................................18
Acronyms .................................................................................................19
1 INTRODUCTION
1.1 About this document
The main goal of this document is to analyze and compare primarily, both EJB 3.0
and Spring framework in order to choose the suitable technology for Leicester project
development. This document will be a justification on why the particular technology
has been recommended and this justification will factor-in the nature of the project
The technology recommendation by this document will solely applicable only for
Leicester project and will/should not be taken for general consideration to other
related or non related projects.
This document is not learning tutorial for any technology which are discussed inside
but rather it should give you an overview of them. Information given in this document
are based upon official documentation, tutorial which are provided by respective
technology inventor and from different forums, blogs, interviews , articles and books.
Some of the source references are given in reference section of this document.
In this section comparison is done for both EJB 3.0 and Spring
framework and provided the comparison matrix based upon different
potential services/concepts.
Appendix A :
o
2 SPRING FRAMEWORK
2.1 Overview
Among all the lightweight containers, Spring framework stands out as the most popular and
the most widely accepted framework for enterprise application development, with Good
reasons. Spring is a Lightweight Application Framework where Struts, WebWork and others
can be considered Web frameworks. Spring addresses all tiers of an application.
Spring is NOT a J2EE application server.
Spring can integrate nicely with J2EE application servers (or any Java environment)
Spring can, in many cases, elegantly replace services traditionally provided by J2EE
application servers
Spring can effectively organize middle tier objects, whether or not EJB has been
chosen to use. Spring takes care of plumbing that would be left up to developer if
he/she uses only Struts or other frameworks geared to particular J2EE APIs. And
while it is perhaps most valuable in the middle tier, Spring's configuration
management services can be used in any architectural layer, in whatever runtime
environment.
Spring can eliminate the increase of Singletons seen on many projects; this is a
major problem, reducing testability and object orientation.
Spring can eliminate the need to use a variety of custom properties file formats,
by handling configuration in a consistent way throughout applications and
projects. Ever wondered what magic property keys or system properties a
particular class looks for, and had to read the Javadoc or even source code? With
Spring developer simply look at the class's JavaBean properties or constructor
arguments. The use of Inversion of Control and Dependency Injection helps
achieve this simplification.
Spring can facilitate good programming practice by reducing the cost of
programming to interfaces, rather than classes, almost to zero.
Spring is designed so that applications built with it depend on as few of its APIs
as possible. Most business objects in Spring applications have no dependency on
Spring.
Applications built using Spring are very easy to unit test.
Spring can make the use of EJB an implementation choice, rather than the
determinant of application architecture. Developer can choose to implement
business interfaces as POJOs or local EJBs without affecting calling code.
Spring helps to solve many problems without using EJB. Spring can provide an
alternative to EJB that's appropriate for many applications. For example, Spring
can use AOP to deliver declarative transaction management without using an EJB
container; even without a JTA implementation, if developer only needs to work
with a single database.
Spring provides a consistent framework for data access, whether using JDBC or
an O/R mapping product such as TopLink, Hibernate or a JDO implementation.
Spring provides a consistent, simple programming model in many areas, making
it an ideal architectural "glue." Developer can see this consistency in the Spring
approach to JDBC, JMS, JavaMail, JNDI and many other important APIs.
2.4 Summary
1. Spring is a powerful framework that solves many common problems in J2EE. Many
Spring features are also usable in a wide range of Java environments, beyond classic
J2EE.
2. Spring provides a consistent way of managing business objects and encourages good
practices such as programming to interfaces, rather than classes. The architectural
basis of Spring is an Inversion of Control container based around the use of
JavaBean properties. However, this is only part of the overall picture: Spring is unique
in that it uses its IoC container as the basic building block in a comprehensive solution
that addresses all architectural tiers.
3. Spring provides a unique data access abstraction, including a simple and productive
JDBC framework that greatly improves productivity and reduces the likelihood of
errors. Spring's data access architecture also integrates with TopLink, Hibernate, JDO
and other O/R mapping solutions.
4. Spring also provides a unique transaction management abstraction, which enables a
consistent programming model over a variety of underlying transaction technologies,
such as JTA or JDBC.
5. Spring provides an AOP framework written in standard Java, which provides
declarative transaction management and other enterprise services to be applied to
POJOs or an ability to implement the own custom aspects. This framework is powerful
enough to enable many applications to dispense with the complexity of EJB, while
enjoying key services traditionally associated with EJB.
6. Spring also provides a powerful and flexible MVC web framework that is integrated
into the overall IoC container.
3 EJB 3.0
3.1 Overview
The primary goal of EJB 3.0 is to target ease of development and it is the main theme
of the Java EE 5 platform release. EJB 3.0 is a major simplification over the APIs
defined by the EJB 2.1 and earlier specifications. The simplified EJB 3.0 API allows
developers to program EJB components as ordinary Java objects with ordinary Java
business interfaces rather than as heavy weight components.
Both component and client code are simplified, and the same tasks can be
accomplished in a simpler way, with fewer lines of code. Because it is much simpler,
EJB 3.0 is also much faster to learn to use than EJB 2.1.
EJB -- simpler, better. EJB 3.0 makes programming with Enterprise JavaBeans
technology simpler through the use of Plain Old Java Objects (POJOs)
Enhanced web services. Java EE 5 includes simplified web services support and the
latest web services APIs, making it an ideal implementation platform for ServiceOriented Architectures (SOA).
JSF, JSTL, AJAX, and more. Constructing web applications is made easier with Java
Server Faces (JSF) technology and the JSP Standard Tag Library (JSTL). Java EE 5
supports rich thin-client technologies such as AJAX, technologies that are crucial for
building applications for Web 2.0.
New persistence API (JPA). Java Persistence API to provide a light-weight POJO
persistence API for object/relational mapping. The Java Persistence API incorporates
support for many of the features that EJB developers have been asking for, including
support for improved object modeling, inheritance, and polymorphism, an expanded
query language, and rich metadata for the specification of object/relational mapping.
Java Persistence is available both as part of Java EE, and for use outside Java EE in a
Java SE environment.
It is much easier to write a stateless or stateful component that takes full advantage of
the transactional capabilities of the EJB container. EJB components can be written as
POJOs with, for example, a simple @Stateless annotation. By default, the public
methods of the component will be exposed to clients and will run in a transaction.
Additional annotations can be used to control security requirements for methods and
transaction requirements.
Adopting a plain old Java object (POJO) programming standard and setting
intelligent defaults for EJB components
Eliminating the need for deployment descriptors and using Java metadata
annotations for deployment settings instead
Introducing a simplified POJO persistence model similar to Oracle TopLink and
JBoss Hibernate
Using dependency injection instead of the Java Naming and Directory Interface
(JNDI) to locate resources and EJB components.
3. Freedom of choice.
a. Java EE technology is a set of standards that many vendors can
implement. The vendors are free to compete on implementations
but not on standards or APIs. Sun supplies a comprehensive Java
EE Compatibility Test Suite (CTS) to Java EE licensees. The Java
EE CTS helps ensure compatibility among the application server
vendors which facilitates portability for the applications and
components written for the Java EE platform. The Java EE
platform brings Write Once, Run Anywhere (WORA) to the server.
4. Simplified connectivity.
a. Java EE technology makes it easier to connect the applications
and systems you already have and bring those capabilities to the
web, to cell phones, and to devices. Java EE offers Java Message
Service for integrating diverse applications in a loosely coupled,
asynchronous way. The Java EE platform also offers CORBA
support for tightly linking systems through remote method calls. In
addition, the Java EE platform has J2EE Connectors for linking to
enterprise information systems such as ERP systems, packaged
financial applications, and CRM applications.
5. By offering one platform with faster solution delivery time to market,
freedom of choice, and simplified connectivity, the Java EE platform helps
IT by reducing Total Cost of Ownership (TCO) and simultaneously avoiding
single-source lock-in for their enterprise software needs.
3.4 Summary
1. Java EE 5 accelerates and radically simplifies Enterprise Java development,
especially for Web Services (JAX-WS 2.0), Web Applications (JSF), and
transactional components (EJB 3.0). It introduces a new database persistence
model (Java Persistence) and leverages Annotations from Java SE.
2. EJB 3.0 greatly simplifies the programming model through Plain Old Java Objects
(POJOs), which can easily be converted to Web Services with Annotations or made
persistent using the Java Persistence API. It is now much easier to write a stateless
or stateful component that takes full advantage of the transactional capabilities of
the EJB container.
3. Java Persistence is a much cleaner approach to mapping Java objects to relational
databases, and benefits greatly from work done in Hibernate, TopLink, and Java
Data Objects (JDO).
4. JAX-WS 2.0, which replaces JAX-RPC, simplifies the development of web services
by automatically generating client and server code. It now provides support for
JAXB 2.0 data binding, the latest W3C and WS-I standards (e.g. SOAP 1.2, WSDL
1.2), protocol and transport independence, and the REST style of web services.
5. JAXB 2.0, which adds full support for W3C XML Schemas, maps Java classes to
XML data and is used by JAX-WS to encode and decode data sent in web services
calls.
6. JavaServer Faces 1.2 simplifies the building of user interfaces for Web-based
applications by providing pre-packaged components, significantly reducing new
code development. The latest version offers better alignment with JavaServer
Pages, improved state-saving behavior, and the ability to turn off component ID
generation.
7. Java EE draws upon annotations and generics from Java SE virtually eliminating
the need for deployment descriptors. Annotations allows declarative information to
be moved inside the code and makes it much easier to deal with persistence, web
services, transactions, security, and all the other powerful capabilities of Java EE.
8. Java EE also simplifies common coding issues by removing boilerplate code,
relying upon reasonable defaults whenever possible, and providing a broader set of
commonly used utility classes.
10. Java EE 5 takes drudgery out of creating applications and reduces the amount of
time spent worrying about Java EE plumbing and thus allows developers to
concentrate on the business logic.
4 COMPARISON ANALYSIS
Most importantly, Spring is an implementation while EJB 3.0 is a specification. But they do
have some areas of overlap, for example both provide a mechanism to deliver middleware
services to Java applications. Spring was developed as a reaction against EJB and this
makes comparison between the two natural. Particularly now that a new version of EJB is
available, it is a good time to re-evaluate how well EJB 3.0 has addressed the shortcomings of
previous versions
d. Instead, EJB 3 adopts JPA, an API based paradigm similar to Hibernate, TopLink
and JDO.
e. Object Relational Mapping and Object queries have been completely defined
instead of being left up to container vendors to sort out.
f.
. No
Concepts/ Services
EJB 3.0
Spring Framework
Is required for
Leicester?
1.
Dependency Injection
Implementation
Choice
2.
Transaction
Management
Have to configure it
to make it work, but
supports a number of
strategies including
JTA, JDBC and
Hibernate
Highly required
3.
Persistence
Tightly integrated
through JPA
Framework support
for JPA, Hibernate,
JDBC, iBatis
Highly required
4.
State management
Indirect support
dependent on web
container session
management
Highly required
5.
Web services
Highly required
6.
Messaging
Need to add
configuration for
message listeners.
However,
JMSTemplate adds
nice abstraction over
JMS.
Highly required
7.
AOP
Robust support
through AspectJ and
Spring AOP alliance.
May be
. No
Concepts/ Services
EJB 3.0
Spring Framework
Is required for
Leicester?
8.
Security
Highly required
9.
Scheduling.
Simple scheduling
possible through EJB
Timer service
May be or N/A
Remoting
Integrated support
through Session Bean
remote interfaces.
Supports distributed
transactions and
security.
Remoting support
may be added via
configuration.
Remote transactions
and security are not
supported. However
protocols other than
RMI such as Hessian
and Burlap are
supported.
May be
10.
5 CONCLUSIONS AND
RECOMMENDATIONS
5.1 Conclusion
At this point we have learned many similarities between Spring framework and EJB 3.0. It is
totally upto the users discretion to choose one of them since both technologies have their
own pros and cons and they do have their own work around for each disadvantage.
They are subjected to debatable forever and corresponding technology inventor would justify
that they are the best and sometimes selection would be based upon the political decision
too. (i.e. biased to certain technology)
From the earlier sections of this document, we can summarize list of situations where it might
be too appropriate to consider Spring or EJB 3.0
You prefer a tightly integrated solution stack that makes sensible default choices for
you and minimizes configuration.
Spring gives you more flexibility in many aspects of application development than EJB does
and this is particularly true with regards to persistence and transaction providers. But the
trade-off for this added flexibility is increased complexity in configuration. EJB 3.0 provides
less flexibility but its tight technology stack, annotations-based configuration, and philosophy
of configuration by exception make configuring EJB 3.0 applications quite simple.
Standardization: While Spring integrates many standards such as JTA, JDBC, and JMS it is
not itself a Java standard. When standardization (and by extension vendor support, tooling,
etc.) is important to our organization or application then it is good to simply go with EJB 3.0.
5.2 Recommendations
In order to choose the right choice (close to best) for Leicester we do take the following
important factors for consideration and all the other factors for this project could be sufficed by
both of them.
State Management
Configurability
Standardization
Web Service
Security
When the Leicester is highly stateful then it is necessary to consider EJB 3.0 SFSBs might be
a good solution. For highly conversational applications we may want to consider SEAM, which
provides a very powerful solution for conversational interaction built on SFSBs and JSF.
For all the above potential factors , EJB3.0 would work better for us when compared to Spring
framework and because of these factors it is recommended to use Java EE 5 (EJB 3.0) as a
technology solution for Leicester project.
Important Note: Luckily Spring and EJB 3.0 are not mutually exclusive choices. There are
very powerful ways of integrating these two technologies to take advantage of their relative
strengths and weaknesses. When it is highly necessary, with Java EE 5 its always possible to
make use of some common integration points with the Spring Framework. Specifically, EJB
3.0 and JPA combine naturally with Spring
Appendix A.
5.3 References
1. The Spring Framework - Reference
http://static.springframework.org/spring/docs/2.0.x/reference/index.html
http://springframework.org/
2. Java EE
http://java.sun.com/javaee/
http://www.jcp.org/en/jsr/detail?id=220
http://java.sun.com/javaee/community/
http://www.onjava.com/pub/a/onjava/2004/01/14/aop.html
4. EJB3 Interviews
http://www.infoq.com/interviews/Mike-Keith
http://java.sun.com/developer/technicalArticles/Interviews/shannon_qa.html
http://www.onjava.com/pub/a/onjava/2005/06/29/spring-ejb3.html?page=1
6. Books Referred
http://blogs.sun.com/stories/
http://www.bea.com/framework.jsp?CNT=moreinfo_WLS10.jsp&FP=/cont
ent
5.4 Acronyms
SL. No
Acronym
Explanation
1.
IoC
Inversion of Control
2.
DI
Dependency Injection
3.
AOP
4.
Java EE
5.
SFSB
6.
POJO
7.
SEAM