EJB3.0 Vs Spring

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

12 Νοε 2013 (πριν από 3 χρόνια και 8 μήνες)

86 εμφανίσεις

EJB3.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 
2
 
Spring Framework..................................................................................6
 
2.1  Overview....................................................................................................6 
2.2  Concepts of Spring Framework.................................................................6 
2.2.1
 
Inversion of Control............................................................................................6
 
2.2.2
 
Dependency Injection........................................................................................6
 
2.2.3
 
Auto wiring.........................................................................................................7
 
2.2.4
 
Aspect Oriented Programming (AOP)................................................................7
 
2.3  Architectural benefits of Spring Framework...............................................7 
2.4  Summary....................................................................................................8 
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 
4
 
Comparison Analysis...........................................................................13
 
4.1  Characteristics of EJB 2.x, Spring and EJB 3.0.......................................13 
4.1.1
 
EJB 2.x.............................................................................................................13
 
4.1.2
 
Spring Framework............................................................................................13
 
4.1.3
 
EJB 3.0.............................................................................................................13
 
4.2  Comparison Matrix between Spring Vs EJB 3.0......................................14 
5
 
Conclusions and Recommendations..................................................15
 
5.1  Conclusion...............................................................................................16 
5.1.1
 
Use Spring if:....................................................................................................16
 
5.1.2
 
Use EJB 3 if:....................................................................................................16
 
5.2  Recommendations...................................................................................17 
Appendix A....................................................................................................18
 
5.3  References...............................................................................................18 
5.4  Acronyms.................................................................................................19 


1 I
NTRODUCTION

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.
1.2 How this document is Organized
This document is organized as different sections and each section discusses the
information like below
• Section 2 : Spring Framework
o Discussed an overview information about what is spring , concepts of
spring and benefits of spring
• Section 3: EJB 3.0
o Discussed an overview of EJB 3.0 , Java EE , benefits of Java EE
• Section 4: Comparison Analysis
o 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.
• Section 5: Conclusions and Recommendations
o In this section conclusions are discussed based upon comparison
analysis and given the recommendations suitable for Leicester project.
• Appendix A :
o References are given, which are used to write this document
o Acronyms are given, which are used in this document.





2 S
PRING
F
RAMEWORK

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
2.2 Concepts of Spring Framework
Core technologies and concepts of Spring framework are
1. IoC (Inversion of Control)
2.
DI (Dependency Injection).

3.
Auto wiring

4.
AOP (Aspect Oriented Programming)

2.2.1 Inversion of Control
Inversion of Control (IoC) is the single most important concept of Spring framework. IoC
underpins a lot of functionalities provided by Spring.

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.
2.2.2 Dependency Injection
Dependency Injection (DI) is tightly coupled with IoC, In a typical application, there are
multiple classes which work together to perform certain task(s), and hence inter-relate with
each other in some sort of relationships. Instead of defining the relationships within the
application codes, these kinds of dependencies can be defined in the XML metadata
configuration, and the container will be responsible to “inject” the relationships when the bean
is created.





2.2.3 Auto wiring
Spring IoC container is able to autowire relationships between collaborating beans. It means
the container will automatically resolve the bean relationships by inspecting the BeanFactory
contents. Autowiring in Spring happens at bean level, which means it is possible to autowire
some beans in the container by not the others, and it would save a significant amount of
typing and maintenance effort of developers.
2.2.4 Aspect Oriented Programming (AOP)
Since 2003 there has been much interest in applying AOP solutions to those enterprise
concerns, such as transaction management, which have traditionally been addressed by EJB.
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.
2.3 Architectural benefits of Spring Framework
Some of the benefits Spring can bring to a project are
 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.
3.1.1 High lights of Java EE 5
 Easier development. The focus in Java EE 5 is ease of development. With Java EE 5,
there is less code to write -- much of the boilerplate code has been removed, defaults
are used whenever possible, and annotations are used extensively to reduce the
need for deployment descriptors.
 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 Service-
Oriented 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.
3.2 Enterprise JavaBeans 3.0 and the Java
Persistence API (JPA)
The core of EJB 3.0 is a great simplification of the classic EJB programming model by
using Plain Old Java Objects (POJOs) and Java persistence API is the most exciting
work done by the EJB expert group.
Java Persistence is in many ways a replacement for EJB CMP (Container Manager
Persistence), although CMP is still fully supported in Java EE. Java Persistence is a
much simpler approach to mapping Java objects to relational databases, and benefits
greatly from work done in other products and technologies such as Hibernate, TopLink,
and Java Data Objects (JDO). Java Persistence is a significant departure from EJB
CMP, and more resembles those other technologies. Java Persistence is based on
POJOs with annotations.





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.
3.2.1 Simplified Programming Model with Java EE 5
Java EE 5 radically simplifies the development of enterprise applications by:
 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.3 Main benefits of the Java EE platform
The Java EE platform provides the following:
1. Complete web services support.
a. The Java EE platform provides a framework for developing and
deploying web services on the Java platform. The Java API for
XML Web Services (JAX-WS) enables Java technology developers
to develop SOAP-based interoperable and portable web services.
Developers use the standard JAX-WS programming model to
develop SOAP-based web service clients and endpoints. A web
service endpoint is described using a Web Services Description
Language (WSDL) document. JAX-WS enables clients to invoke
web services developed across heterogeneous platforms. In a
similar manner, JAX-WS web service endpoints can be invoked by
heterogeneous clients. For more info, see
http://java.sun.com/webservices
/
2. Faster solutions delivery time to market.
a. The Java EE platform uses "containers" to simplify development.
Java EE containers provide for the separation of business logic
from resource and lifecycle management, which means that
developers can focus on writing business logic -- their value-add --
rather than writing enterprise infrastructure. For example, the
Enterprise JavaBeans (EJB) container handles distributed
communication, threading, scaling, transaction management, etc.
Similarly, Java Servlets simplify web development by providing
infrastructure for component, communication, and session
management in a web container that is integrated with a web
server.





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.
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 C
OMPARISON
A
NALYSIS

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
4.1 Characteristics of EJB 2.x, Spring and EJB 3.0
4.1.1 EJB 2.x
a. Made developer to write a bunch of redundant artifacts.
b. Deployment descriptors difficulties
c. Long develop-test-debug cycle with little unit testing.
d. Entity beans are half-baked and non-portable.
e. Entity beans are slow. Remoting and global synchronization are overkill.
4.1.2 Spring Framework
a. POJO programming.
b. Much easier to develop, test and deploy.
c. Gives 90+% of what EJB does.
4.1.3 EJB 3.0
a. EJB 3 embraces POJO programming through annotations.
b. The verbose XML deployment descriptor has been made optional.
c. The Entity Bean concept is no longer managed by the container.
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. EJB 3 makes heavy use of “intelligent defaulting” whenever possible. This is a
similar idea to “convention over configuration” in the Rails world.









4.2 Comparison Matrix between Spring Vs EJB 3.0
Below table describes the gives the comparison details of various concepts and
services involved between EJB 3.0 and Spring framework. The column “Is required for
Leicester?” will have the information about if it is really matters or not

.
No
Concepts/ Services
EJB 3.0
Spring Framework
Is required for
Leicester?
1.
Dependency Injection
Can inject anything in
the container including
EJBs, data sources,
JMS resources and JPA
resources
Can inject almost
anything including
lists, maps,
properties and JNDI
resources.
Implementation
Choice
2.
Transaction
Management
Works right out of the
box, but only JTA is
supported
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
Robust support through
Stateful Session Beans
and Extended
Persistence Context
Indirect support
dependent on web
container session
management
Highly required
5.
Web services

Seamless support for
JAX-WS 2.0
Poor direct support,
best integration
available is via
configuring XFire for
registered beans.
Highly required
6.
Messaging
Supported out of the box
through Message Driven
Beans.
Need to add
configuration for
message listeners.
However,
JMSTemplate adds
nice abstraction over
JMS.
Highly required
7.



AOP
Simple but limited
support through
interceptors.
Robust support
through AspectJ and
Spring AOP alliance.
May be











.
No
Concepts/ Services
EJB 3.0
Spring Framework
Is required for
Leicester?
8.
Security
Integrated support for
declarative and
programmatic security
through JAAS.
Must add and
configure Acegi
security. However,
support beyond JAAS
is possible through
Acegi.
Highly required




9.
Scheduling.
Simple scheduling
possible through EJB
Timer service
Must add and
configure Quartz for
scheduling.
May be or N/A
10.














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



5 C
ONCLUSIONS AND
R
ECOMMENDATIONS

5.1 Conclusion
At this point we have learned many similarities between Spring framework and EJB 3.0. It is
totally upto the user’s 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
5.1.1 Use Spring if:
 Your application requires fine-grained control at the container level.
 Your application requires a lot of configuration beyond gluing together
components and resources.
 You need advanced AOP features.
5.1.2 Use EJB 3 if:
 You like annotations and dislike a lot of XML configuration.
 You prefer a tightly integrated solution stack that makes sensible default choices for
you and minimizes configuration.
 Your application is very stateful.
 Standardization is an important consideration.
 You use JSF and are considering using Seam.

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
4.
Java EE
Java Enterprise Edition
5.
SFSB
Stateful Session Bean
6.
POJO
Plain Old Java Object
7.
SEAM
JBoss Seam is a powerful new
application framework for
building next generation Web
2.0 applications by unifying and
integrating technologies such as
Asynchronous JavaScript and
XML (AJAX), Java Server Faces
(JSF), Enterprise Java Beans
(EJB3), Java Portlets and
Business Process Management
(BPM).
Seam has been designed from
the ground up to eliminate
complexity at the architecture
and the API level. It enables
developers to assemble complex
web applications with simple
annotated Plain Old Java
Objects (POJOs),
componentized UI widgets and
very little XML. The simplicity of
Seam 1.0 will enable easy
integration with the JBoss
Enterprise Service Bus (ESB)
and Java Business Integration
(JBI) in the future.