The evolution of j2EE (1)

http://www.ibm.com/developerworks/websphere/techjournal/0805_knutson/0805_knutson.html

Date:
14 May 2008

Java EE technologies, present and future

The remainder of this article looks at specific technologies included in the Java EE platform and their expectation for change:

Presentation layer

Business logic

Persistence

Integration

Other technologies

Future technologies

Presentation layer

Servlets
Servlets
should be a fairly stable technology at this point, mature and fairly
well understood. Other than addressing Web 2.0, there are no
significant changes expected. Of course, that's not to say that there
won't be any changes:

Java
EE 5 addressed some of the usability problems in the platform by
permitting metadata to be embedded in component source code. The
servlet specification did not take full advantage of this and so it is
expected to do so. However, this should only add additional forms of
metadata rather than changing any behavior.

Another
major change in Java EE 5 is the integration of the expression language
between JavaServer™ Faces and JavaServer Pages, but this integration
was designed to be backward compatible and should present no major
issues.

One
possible future change is metadata scopes. Servlets tend to declare
metadata at a module level and share it among all Web components. EJBs
tend to declare metadata at the component level. This is expected to
evolve to enable both component and module scoped forms of metadata.
Again, this is not expected to cause any incompatibility as the
existing scope behavior should be maintained.

Another
possible area of change is adding programmatic APIs to dynamically
define behavior rather than defining it declaratively. SOA seems to be
pushing this style and it is likely that all technologies will adopt
both a declarative and programmatic behavior model at some point, if
they haven't already. For the most part, this should not cause any
incompatibility. The only possible exception would be adding methods to
interfaces that must be implemented by applications. Given the current
trend in the industry of getting away from explicit interfaces (and
using annotated methods instead), this is not expected to be an issue.

JavaServer Pages (JSP) and Java Standard Tag Library (JSTL)
JSPs and JSTL are also fairly stable technologies at this point, with no significant changes expected.

JavaServer Faces (JSF)
JSF
is still a relatively new technology. JSF is undergoing a major
revision for the next round of specifications with an expected
integration between JSF managed beans and Enterprise JavaBeans™. The
risk of changes affecting existing applications will be higher here
than with other presentation technologies. IBM does have representation
on the JSF expert group and will keep a watchful eye out for problems.

One
area of future concern is be how well Ajax support in JSF will follow
the specifications for the OpenAjax Alliance. Through its
participation, IBM will try to ensure that compatibility is maintained
as the standards move forward. Ajax support in JSF will be new (when it
appears) and use of that feature will be at a somewhat higher risk than
other parts of JSF. More details will be known in early 2009.

Portlets
Although
not part of the Java EE platform, IBM WebSphere Application Server V6.1
and later provides the ability to utilize portlets. The portlet
specification is currently undergoing a revision, but IBM is the
specification lead and has a level of control over its evolution.

Version
2.0 of the portlet specification is a major revision that adds features
omitted in Version 1.0, like coordination of resource serving, and
leads the Java Portlet specification toward a path of maturity. Changes
likely for later versions will mainly be to align with changes in other
Java EE specifications, such as Servlet 3.0 or JSF 2.0, but they are
not likely to include major new functionality on the portlet side.

At
the time of this writing, Version 2.0 of the Java Portlet specification
appeared to be source and binary compatible to Version 1.0, and
switches were to be added for controlling underspecified Version 1.0
behavior that is now specified in Version 2.0. This compatibility
assertion will be validated once the specification is finalized and
sufficient testing has been performed.

Business logic

Enterprise JavaBeans (EJB)
The
EJB specifications have added new capabilities over time, but have done
so in an upward-compatible way. The EJB 3.0 specification changed the
EJB programming model syntax in a fairly dramatic way. However, the
older 2.1 and prior programming models are still available, and even
the 3.0 programming model contains backward compatibility support,
enabling clients and server components to be implemented with different
versions of the specifications.

Session
beans are fairly stable at this point and no substantial behavior
changes are expected, although new functions are likely to be added.

Message-driven beans are also fairly stable.

CMP/BMP
persistence is stable, but is likely to be deprecated in favor of Java
Persistence APIs (JPA) as a relational persistence technology, or the
Java EE Connector Architecture (JCA) for non-relational persistence.

One
possible change that might affect this in the next round of
specifications is the potential to bring session and message-driven
beans together, into a single component style with both synchronous and
asynchronous interaction styles. Given the last revision of the
specification, it is reasonable to expect sane and compatible evolution
here as well.

Persistence

JDBC
JDBC
is quite stable at this point, offering a good long term investment in
performance and compatibility, assuming you do not change your database
vendor; a database vendor change might require changes in the SQL
statements or in the locking and isolation levels you use.

Java Persistence APIs (JPA)
JPA
is the technology slated to replace EJB CMP Object/Relational Mapping
support in the Java platform. This is a new technology and so further
evolution is expected. However, it is also based on multiple vendor
implementation experiences (Hibernate, TopLink, and Kodo) and therefore
the risk of change causing incompatibilities is somewhat reduced. JPA
provides some isolation from JDBC vendor differences.

Integration

Java Message Service (JMS)
JMS has changed little in a long time and is considered a stable technology.

Java EE Connector Architecture
The
Java EE Connector Architecture has been stable for some time, but has
some issues that will be addressed in the next round of specifications.
The current architecture does not address failover or inbound and
outbound consistency; vendors have had to rely on extensions to handle
these issues. Changes in the specification to address these and other
problems are planned to be compatible, but could eventually affect
custom-written resource adapters. Adapters purchased and maintained
from other vendors should hide any affects (if any) of those changes.

JavaMail and JavaBeans Activation Framework (JAF)
JavaMail's
evolution has been somewhat quiet, possibly because there is a smaller
percentage of developers using it than, say, servlets or EJBs. This
architecture tends to have more implementation classes that could be
affected by evolution, making it more difficult to evolve and maintain
source compatibility. However, in general, it appears to be mostly
stable at this point and no changes are currently foreseen. JAF is used
for MIME type handling and is generally considered as stable as
JavaMail.

Java API for XML-based RPC (JAX-RPC)
JAX-RPC is likely to be deprecated in Java EE 6, and therefore any new development needs to consider the option of using:

JAX RPC: a technology that is stable, but does not work for all cases and will be going away, or

JAX-WS: a new technology that is likely to change, but is a reflection of where the industry is moving.

Java API for XML Web Services (JAX-WS)
JAX-WS
is the second generation of a Web services API, taking strategic
precedence over JAX-RPC. It was defined as a new technology in order to
avoid backward compatibility issues that would have hampered the
evolution of the specification. There have already been some issues
around the evolution of JAX-WS, due to decisions of the W3C standards
committees, that have led to revisions removing the support of some
requirements of the specification. The Web services area is likely to
evolve even more. Currently, there is a desire to standardize the
qualities of service related to a Web service (such as reliable
messaging or transactions), in addition to a focus on RESTful Web
services (via JAX-RS – JSR 311). All of this is still relatively new
and shakeouts are likely to occur as the industry gains more experience
in these areas.

From a maturity perspective,
JAX-WS has benefited greatly from the JAX-RPC experience. The lessons
learned from JAX-RPC and fed into JAX-WS have produced a reasonably
effective and mature specification. The inclusion of both JAX-WS and
JAXB in Java SE 6 (the JDK/JRE) will likely stabilize these
technologies even further.

Java Architecture for XML Binding (JAXB)
JAXB
is also new, but similarly evolved from the previous JAXB 1.0 delivery.
Combining that experience with leveraging input from JAX-RPC and JAXB's
inclusion into JAX-WS, JAXB is better positioned in its second release
(like JAX-WS is over JAX-RPC) to be a stable and compatible technology.
While it maintains the same name as its predecessor, its implementation
and much of what it is trying to accomplish has been rewritten based on
lessons learned from its past deficiencies. It could evolve further as
the platform tries to address more consistent mappings between Java
objects and other representations, such as protocol marshalling or
persistence. Expectations are that backward compatibility will be
maintained for those mappings.

SOAP with Attachments API for Java (SAAJ)
SAAJ
is a fairly stable rendering form for Web service messages. Apart from
its extension of leveraging standardized DOM APIs, it has undergone
little change since its initial release.

Java API for XML Registries (JAXR)
JAXR
is another technology that was introduced and adopted by the Java EE
platform too rapidly. JAXR was based on providing an abstraction over
UDDI V2 and ebXML V2, but V3 versions of those standards were produced
almost simultaneously, rendering JAXR somewhat obsolete out of the
gate. The industry is still evolving in this space somewhat, so any
further evolution of JAXR is also likely to be out of date when
complete. Once the industry settles down a bit, JAXR will likely either
evolve dramatically or be replaced by another technology.

Other technologies

Java EE Management
Java EE Management has been fairly stable and its stability is expected to continue.

Java EE Deployment
This
technology should be avoided, as it is insufficient for the task and is
likely to go away or be replaced by a substantial revision in the
future.

Java Authentication and Authorization Service (JAAS)
JAAS
provides the core of security services for the Java EE platform. It is
generally stable, but there are known differences in behavior across
vendors regarding JAAS subject propagation. This will attempt to be
clarified in a future Java EE platform specification so that industry
consistency may be achieved.

Java Authorization Contract for Containers (JACC)
The
changes in Java EE 5, enabling metadata declarations via annotations,
have required changes to JACC to enable the handling of annotated
security declarations. JACC 1.0 providers are not likely to be able to
provide appropriate security behavior with security annotations in use,
although existing applications that do not use annotated security
declarations should continue to run fine.

Future technologies

Of
course, the future is uncertain, but you can expect some technologies
to continue influencing the Java EE platform. The technologies listed
below should be approached with caution from a compatibility
standpoint, since it is likely that they will evolve dramatically.

JAX-RS - RESTful services
The
industry has recognized that it is not always efficient to have a
formal Web service for loosely coupled services. However, this is new
for the industry and not a lot of experience has been built up yet
around this hot topic. As best practice patterns emerge, it can easily
be imagined that the specification could change dramatically.

WebBeans
The
Java EE 6 content proposal includes the addition of a new technology
called WebBeans. Originally proposed as a way to integrate JSF managed
beans and EJBs, it has since evolved into a distinct component model
meant to encompass many other component models. There is very little
experience in this space (although WebBeans was intended to be modeled
on JBoss Seam, it has gone well beyond that experience). The closest
example might be to look at the years of deliberation that went into
producing the first SCA specification, which also serves as a component
model that encompasses many other component models. Unless the scope of
WebBeans is reduced dramatically in the near future, its specification
is likely to evolve dramatically.

Timer and Workmanager
These
specifications drive enterprise qualities of service into asynchronous
(that is, threaded) programming styles. They are based on joint work
done by IBM and BEA (CommonJ) and have somewhat reduced risk based on
multiple vendors having delivered these technologies, but these
specifications have rebased the API on the Java Concurrency Utilities
for threaded work management. It remains to be seen whether the
industry will accept this or require additional changes, but the risk
of their use is likely to be smaller than WebBeans. Using existing
Asyncronous Beans APIs within WebSphere Application Server will provide
the best long term stability and compatibility -- at least until these
specifications stabilize.