Coping with Java's Heterogeneity - ELCA

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

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

121 εμφανίσεις

6
i nsi d
e
j azoon
J a z o o
n
Na v i g a t o r
/2 0
0
7
©
n
e
t
z
me d i e
n
a g
Coping with Java’s Heterogeneity
A System Integrator’s
perspective
How many thousand development
tools exist for Java? Already Source
-
forge lists more than 4,000, there are
countless Web and Ajax frameworks
and there are more than 40 under Ja
-
karta Commons. Besides, many par
-
ties try out new ideas and re-imple
-
ment industry best practices in Java.
This is a big win for the platform, as
its tools get better and better. Sample
innovations that brought an added
value to the platform include the O/R
mapping model of Hibernate, the de
-
pendency injection of Spring, or as
-
pect-oriented programming (AOP)
of AspectJ. In these cases, the inno
-
vations have already found their way
into the Java EE 5 specification (as
Java Persistence API (JPA), the EJB
@Inject annotations and EJB Inter
-
ceptors).
For technology enthusiasts, the
stream of Java innovations is a
source of fun. Many new approaches
are tried out; other components are
combined in new ways. Whenever
a promising technology idea comes
up, the community responds quick
-
ly and brings it to Java. As an exam
-
ple consider the responses to the Ru
-
by on Rails framework (e.g. Trails or
Grails), more dynamic scripting lan
-
guages (e.g. Groovy or JRuby) or the
annotations (metadata) for Java (e.g.
Commons Attributes). It may take a
while until “the next best thing” is
available in the Java platform, but
when people see benefits, it is likely
that it will be made available. The fact
that the Java platform is so well es
-
tablished reduces maturity and per
-
formance concerns about the runt
-
ime environment.
When software architects decide
which Java technologies to use for a
new project, the situation does not
look as bright. For a new project,
they may end up recommending
Spring (from springframework.org),
Eclipse (eclipse.org), Ant (apache.
org), Log4j (apache.org), Common
logging (apache.org), JDK (sun.
com), Hibernate (jboss.org), Facelets
(dev.java.net), Junit (Junit.org), and a
Java EE implementation. They come
from many different sources and it
takes time to make all those build
-
ing blocks work together in a project.
What typically requires integration
effort are configuration problems or
conflicts among components. For
system integrators like ELCA, legacy
software and other technology con
-
straints need also be taken into ac
-
count. With an increasing number of
architects, the heterogeneity tends to
increase as well.
The area of web-frameworks is a
good example of how platform het
-
erogeneity is particularly signifi
-
cant. What do you use: Struts, Spring
MVC, Tapestry, plain JSPs and Serv
-
lets, or JSF? Even worse: An IT ana
-
lyst has counted 80 (!) Java frame
-
works for Ajax. No rapid consolida
-
tion is expected. So let us make a
rough estimate: if maybe 5 frame
-
works will make it to the forefront
in 3 years, you have 5/80 chance to
choose one of them. Your chances
increase if you consider their qual
-
ity and momentum. How about the
projects using the 75/80 «loosing»
frameworks? What shall they do?
The same applies to scripting lan
-
guages, where the choice includes
Groovy, Bean Shell, JRuby, JPython,
Rhino (Javascript).
For software architects, this heter
-
ogeneity has some negative implica
-
tions:
• They need to work more to evalu
-
ate tools, and still have a higher risk
to choose an inappropriate technol
-
ogy
• They need to put more effort into
educating the developers
• Tools tend to be less mature than
they should be, because the availa
-
ble development capacity is distrib
-
uted over many different technolo
-
gies
• Integration is more difficult, be
-
cause there are more technologies
around
• More legacy technology will need
to be maintained in the future
In short, this heterogeneity inflates
both costs and risks.
What could the Java community do
about this complexity?
• One idea would be to replace the
community-driven Java communi
-
ty process by a “dictator” that elimi
-
nates the heterogeneity. This dictator
could focus on his single vision of the
platform. If we look at the evolution
of the .NET framework, we are basi
-
cally confronted with this situation:
Microsoft decides for the whole com
-
munity what its technologies will be.
Even open-source technologies have
little chance to have a big platform
impact: There are significantly fewer
.NET open source projects that gain a
huge acceptance, and in addition to
this, Microsoft has already “under
-
mined” successful open-source initi
-
atives by adding a similar technolo
-
gy as part of the default components.
For instance, this has occurred with
the NUnit framework.
This situation has benefits for
.NET developers: There are much
fewer discussions about the technol
-
ogies one will use, as there is basical
-
ly one predefined technology stack.
Following the innovation is much
easier, and you know which tools
you need to learn. Java would proba
-
bly loose a lot through this approach.
Some technologies chosen by a dic
-
tator may not be well received (con
-
sider e.g. the not well-received Enti
-
ty Beans).
Another possible outcome is that
the platform evolution speed would
be drastically reduced as the open-
source driver would eventually dis
-
appear. The fun which is part of the
Java community would also be great
-
ly reduced.
• An alternative idea is to “go meta”,
or in other words to specify one’s ap
-
plication in a metamodel (that gen
-
eralizes – let us say - the abstractions
for Ajax frameworks) and then gener
-
ate Java code from it. The metamod
-
el may be defined in any convenient
notation: UML models, a XML for
-
mat, or another textual representa
-
tion. A small and potent team main
-
tains the mapping to the underlying
technologies. The metamodel pro
-
tects other developers from the plat
-
form heterogeneity.
Model-driven architecture (MDA)
or model-driven software engineer
-
ing (MDSE) are approaches that are
based on this idea. There are many
interesting uses of this, but to spec
-
ify some processing often the Java
programming language “notation”
is often preferred. The approach al
-
so tends to become heavy, as there is
yet another abstraction layer. Some
-
times leaking abstractions further
limit its applicability.
• Integration frameworks are yet
another idea. I use this term here
to describe frameworks that create
the foundation to combine other
frameworks more easily. For exam
-
ple the Spring framework integrates
with a lot of third party tools (cur
-
rently there are more than 90 exter
-
nal jar files included with the basic
spring distribution). Spring provides
some basic unifying foundation such
as configuration, life cycle manage
-
ment of the contained components,
some resource management, uni
-
fied exception handling, or transac
-
tion and session management. This
significantly reduces the complex
-
ELCA’s standard stack for Java developments as it is contained in EL4J
graphic source: http://EL4J.sf.net
Philipp H. Oser,

Lead Architect
of ELCA
Author
Despite the substantial trend to
-
wards consolidation, the market in
the area of systems supporting the
content life cycle is extremely com
-
plex and heterogeneous. Once de
-
veloped from the need of managing
web sites or documents in a simple
way, content management systems
(CMS) have grown continuously and
now increasingly reach into strategic
areas of business. Today, companies
require a stable content infrastruc
-
ture, on the basis of which it is pos
-
sible to run the varied business-criti
-
cal web applications. However, there
is not really an infrastructure market
in this area at present. The reason for
this is that there are no sufficient in
-
dustry standards on which to build.
In fact, there are numerous proprie
-
tary systems that can only be linked
with each other with great difficul
-
ty. For instance, if you compare this
with databases or application serv
-
ers – systems that serve as an infra
-
structure for numerous applications
– the difference becomes clear. This
is where the content repository API
for Java technology (JCR) standard
comes in, which is specified in the
context of JSR-170 and was released
in version 1.0 in June 2005. It pro
-
vides a standardised API for access
-
ing content repositories.
Content repositories
A web application like, for instance,
an employee portal on the intranet,
works due to the content that is pro
-
vided to the users via this platform,
which they need to perform their
tasks. The users need access author
-
isations in order to be allowed to use
and alter content; they want to be
able to search directly for content or
be informed about the current news
in “their” area. This makes clear that
it is not only about merely providing
data, but that this data also has to be
equipped with certain services. For
instance, this includes access con
-
trol, a search function and version
control. Applications using content
require few, but extremely important
services again and again. The idea of
JCR is to separate them from the ap
-
plications and make them available
via a standardised API. Thus, these
functions no longer need to be im
-
plemented into the application again
and again, but are called simply via
The architecture of Jackrabbit provides an individual persistence manager for every workspace, which is
responsible for storage in the database or the file system. The index is stored separately.
7
i nsi d
e
j azoon
Java Content Repository
Standard: Content for
everyone
The standard for a content repository API for Java technology describes a clear
interface between application and content storage. The definition and standardi
-
sation of such an interface facilitates the cross-system utilisation of content and
thus unlocks potential which could only be tapped with great effort up to now.

J a z o o
n
Na v i g a t o r
/2 0
0
7
©
n
e
t
z
me d i e
n
a g
ity for an application using some of
these tools together through (1) the
existing integration of the compo
-
nents and (2) a unification of how to
use them.
Another more recent integra
-
tion framework of this kind is jMaki,
which helps integrate widgets of dif
-
ferent Ajax frameworks. Spring’s tre
-
mendous success is a strong indi
-
cation for the sensed benefit of this
idea.
• A fourth idea to reduce the com
-
plexity is to define a standard tech
-
nology stack that one uses for projects
unless there are other constraints.
At ELCA, the stack includes for ex
-
ample popular technologies such as
Spring, Hibernate, Seam, Facelets,
Eclipse, Common logging, Maven 2,
and Log4j. (If you are interested in it,
this stack is integrated in the open-
source EL4J framework http://EL4J.
sf.net).
How do we select the components
in the stack? We look out for qualita
-
tively good frameworks that have mo
-
mentum, i.e. have an active commu
-
nity around. In the past we have also
had to drop certain technologies.
Along with the standard technol
-
ogy stack we provide application
templates: skeletal applications that
show how all the technologies are
used and how common issues are re
-
solved. There is, for example, such a
template for new Web applications.
The ideas to use a standard technol
-
ogy stack and an integration frame
-
work is also used e.g. in the AppFuse
project.
Whenever we can, we apply the last
two ideas (an integration framework
and a standard technology stack) in
our projects. Sometimes, technolo
-
gy constraints require us to slight
-
ly adapt our standard stack. But the
positive effect has been proven in al
-
most 40 medium- to large-scale Java
projects over the last few years.
The Java community is going in the
right direction to convert its hetero
-
geneity issue into strength. It’s cru
-
cial that the huge energy from the
numerous community initiatives to
improve the Java tools is not lost. So
-
lutions such as integration frame
-
works à la Spring and standard tech
-
nology stacks make the complexity
manageable.
If we keep the flexibility to intelli
-
gently combine winning Java tech
-
nologies, the technology excitement
around Java will go on and it remains
a winning platform!
(For more depth on this subject,
please attend my Jazoon Keynote
Speak on Tuesday.)
Dr. Gerd Handke is Director of
Product Management at Day Soft
-
ware and there responsible for
the Communiqué product line of
content centric applications.
Author