Professional Documents
Culture Documents
0 Vs Spring
Priya Thinagar
CEO, X ON Technologies LLC
Contents
1 Introduction.............................................................................................5
1.1 About this document ..................................................................................5
1.2 How this document is Organized ...............................................................5
3 EJB 3.0.....................................................................................................9
3.1 Overview ....................................................................................................9
3.1.1 High lights of Java EE 5.....................................................................................9
3.2 Enterprise JavaBeans 3.0 and the Java Persistence API (JPA)................9
3.2.1 Simplified Programming Model with Java EE 5 ...............................................10
3.3 Main benefits of the Java EE platform .....................................................10
3.4 Summary..................................................................................................11
Appendix A. ...................................................................................................18
5.3 References...............................................................................................18
5.4 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.
What is IoC?
In traditional application development, the control of logic, relationships and flow are usually
defined and maintained within the application codes. In the IoC world, the control is handed
over to Spring framework, which calls application code (usually POJO) instead of application
calling the framework, and hence the name “Inversion” of Control.
In Spring framework, the objects that are instantiated and managed by the Spring IoC
Container are referred to as beans. These beans, together with their relationships and
dependencies are defined in the configuration metadata (i.e. xml format) used by the
container.
The first goal of Spring's AOP support is to provide J2EE services to POJOs. Spring AOP is
portable between application servers, so there's no risk of vendor lock in. It works in either
web or EJB container, and has been used successfully in Web Logic, Tomcat, JBoss, Resin,
Jetty, Orion and many other application servers and web containers.
The use of AOP as an alternative to EJB (version 2 or above) for delivering enterprise
services is growing in importance. Spring has successfully demonstrated the value
proposition.
¾ 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.
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.
¾ 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.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.
9. The enhancements in Java EE 5 greatly reduce the amount of code and
configuration with which application developers have to contend improving their
productivity.
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
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
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 it’s 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/
3. AOP Aspect Oriented Programming
¾ 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
5. Spring Vs EJB3.0 Comparison
¾ http://www.onjava.com/pub/a/onjava/2005/06/29/spring-ejb3.html?page=1
6. Books Referred
¾ POJO IN ACTION - by Chris Richardson
¾ EJB3 IN ACTION – by Debu Panda, Reza Rahman, Derek Lane
7. EJB3 projects in Industry
¾ http://blogs.sun.com/stories/
8. EJB3 support by Weblogic
¾ 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 Aspect Oriented Programming