technical trends n product reviews n performance benchmarks n application server market
Why does the EJB model fail when it comes to
enterprise-scale projects?
By JeanJean-Christophe Cimetiere - CEO
(jcc@techmetrix.com)
This Trend Markers’ issue is dedicated to
EJBs. We’ll try to make you better understand what exactly is missing in the EJB
model.
the standard for business object models.
We believe that EJB may succeed where
CORBA has thus far failed: in providing a
standard enterprise component model
that is truly embraced by the entire industry (except Microsoft!). However, if this
does indeed happen it won’t be overnight.
Lots of vendors claim that EJB, or to
broaden the issue the J2EE platform, is
(Continued on page 2)
EJBs from a critical perspective
By Philippe Mougin
Consultant and Distributed Object Expert
(pm@techmetrix.com)
Introduction
Promoted by SUN and many other major
editors such as Oracle and IBM, Enterprise JavaBeans enjoy big technical and
marketing investments. In this article we
examine EJB’s potential to perform what
is commonly called object-oriented modeling, an approach that consists in building
IT systems by modeling business entities
in the form of software modules called objects. This object-oriented (OO) approach
relies on two fundamentals: the Abstract
Data Type theory and a technology known
as dynamic binding.
Is EJB a good choice for business object
modeling? Answering this question is extremely important since corporations
need to make the strategic choice between using a classical relational approach or OO modeling for their new software development. Hence, the reader
should keep in mind that focus of this article is OO modeling with EJB. We agree
that EJB technology (especially so-called
Session Beans) may be used in other contexts.
After an in-depth evaluation of this technology, we think that Enterprise JavaBeans are still too immature to be considered for business object modeling. We be(Continued on page 4)
In this issue
December 1999
Volume 1, Issue 2
Why does the EJB model fail when it comes to enterprise-scale projects?
1
EJBs from a critical perspective
1
SilverStream 2.5 Performance Review
3
4
2
Why does the EJB model fail when it comes to enterprise-scale projects? (cont.)
(Continued from page 1)
You're fooling yourself if you think that vendors’ EJB-compliant tools will allow you to
move EJB components between application
servers. Think back to the client/server era,
when vendors claimed that their products
were able to jump from one DBMS to another in a wink, without needing to change
a line of code…
Today vendors are focusing
on accompanying you
towards OO development…
This leap was certainly a tricky technical
task for development tool editors, but it
was far easier than switching EJB components. You must understand that the
“portability” of EJB components in no way
constitutes a reason to adopt this standard
today. We take a detailed look at this point,
among others, in this issue.
The knowledge acquired while building an
EJB component is the benefit seen the
most quickly. Because even if EJB technical
implementation differs among editors, the
methodology, distributed object modeling,
and the language, Java (of course) remain
the same.
But are you aware of just how much it costs
to hire EJB experts (if you can find them) or
to train your “Cobol-comfortable” staff?
Offering reliable application servers has
been the main concern of vendors over the
past three years. Today vendors are focusing on accompanying you towards OO development by providing a high-level development tool, which hides the complexity
from beginners, is productive for non-OO
developers and quenches OO experts’
“thirst for adventure.”
To illustrate this last point, we can take the
example of SilverStream. This editor takes
care of non-OO programmers while actively
following the path of distributed objectmodeling programming.
In order to help their customers and educate people, SilverStream recently opened
“SilverStream DevCenter” (http://
devcenter.silverstream.com). The DevCenter focuses a large part of its discussion on
J2EE, one of the key points in the soon-tobe-released version 3.0 of the company’s
principal product.
To get a little taste, read the excerpt of our
recent performance benchmark conducted
with SilverStream Application Server, version 2.5.n
Coming next month...
Get the millennium off to a good start by being up-to-date on the hottest new technology
issues. Here’s a glimpse at the January 2000 TrendMarkers:
www.trendmarkers.com
•
A look under the hood of IRMs
•
WebSphere Performance Review
December 99
4
3
SilverStream 2.5 Performance Review
By Franck Gonzales and Nicolas Farges Consultants
(fg@techmetrix.com; nf@techmetrix.com)
With the launch of a new series of Product
Reviews, TechMetrix Research goes beyond
rough performance results. In order to provide information about application server
behavior, these new reviews include a Performance Benchmark and detailed information gathered during intensive use of the
products. SilverStream version 2.5 is the
second in our series.
the same machine (a multi-process mode
would have been preferable).
Performance
SilverStream proves reactive to workload; it
presents a high transaction rate.
Server performance decreases when faced
with intensive loads (from 358 to 295
pages/second with 50 and 200 robots, respectively), but performance remains more
than acceptable.
With SilverStream installed on our platform,
200 robots simulate a load equivalent to
that generated by roughly 1000 concurrent
users.
The debasement in response time is linear,
according to the number of robots. This
shows that server resources are used optimally no matter the load.n
295: This is the number of dynamic HTML
pages delivered per second by the SilverStream application server during the running of a "mixed" scenario (stringing together of 8 modules) with concurrent use
of the application by 200 robots.
Reliability
The TMBench-compliant application proved
to be entirely reliable running on the SilverStream Application Server, even as the intensive workload placed on the server increased during the tests.
Server configuration was rather particular:
three servers functioned in cluster mode on
Test platform used for evaluation.
Related links on www.techmetrix.com:
www.trendmarkers.com
•
50-page Product Review about SilverStream 2.5 is available. This article is an excerpt of this document.
•
FREE product profile of SilverStream is also available in our Application Server
Directory.
December 99
4
4
EJBs from a critical perspective (cont.)
(Continued from page 1)
lieve this for two reasons. Firstly, the EJB
implementations on the market today are
immature: they do not offer the functions
needed to develop business systems and
they provide the developer with very low
productivity. Secondly, the specification in
itself suffers from some terrible technical
and theoretical problems.
Is EJB a good choice for
business object modeling?
Answering this question is
extremely important since
corporations need to make
the strategic choice
between using a classical
relational approach or OO
modeling for their new
software development.
SUN is pushing its platform, Java 2 Enterprise Edition (J2EE), which brings together
Servlets and JDBC and other technologies
such as Java Server Pages (JSP) and
JavaMail. In this context, Enterprise JavaBeans (EJBs) play a very important role: relying on other J2EE elements, EJBs form a
business component model.
In short, one can say that EJBs would like
to surpass the basic Java object model by
integrating new functions that are important to business systems. In particular,
EJBs provide functions in terms of:
•
•
•
•
•
These problems are looked at in greater detail after a quick introduction regarding the
EJB specification and the technical context.
Objectives and position of
Enterprise JavaBeans
In the business world, Java is ever more
present server-side while HTML dominates
client side. Java development tools and application servers multiply and it is commonplace to choose Java as development language rather than C/C++, PL-SQL, Smalltalk or Visual Basic. This breakthrough was
in most part due to two technologies:
frameworks that allow Java programs to access relational databases, and dynamic
production of HTML.
Today, Java application servers integrate
new functions allowing us to go even farther when developing business systems.
www.trendmarkers.com
•
Object naming: how to obtain a handle on a service.
Object security: who can use which
object and how?
Object persistence: how are objects
stocked in a lasting manner?
OTM: how can one implement ACID
transactions, with the possibility of
Rollback, while manipulating objects
and not relational base tables?
Distribution: how to allow access to
objects from remote applications in
the most efficient and transparent
manner as possible.
Workload support, by implementing
various technologies.
This component system must allow business object modeling. For example, in the
case of an airline we can imagine the EJBs
representing planes, passengers, reservations, etc. All of these components should
be portable on the different environments
that support EJB technology.
From the developer’s point of view, an EJB
is presented as a file group bringing together:
•
•
•
•
Java classes
Java Interfaces
Deployment information
Metadata
(Continued on page 5)
December 99
4
5
EJBs from a critical perspective (cont.)
(Continued from page 4)
It is important to know the particular EJB
concepts and vocabulary to understand
this evaluation. It is particularly helpful to
specify the notions of Session Bean and
Entity Bean, which describe two possible
EJB types:
•
•
Session Beans represent objects,
whose access supports the security,
transaction and distribution models.
The Session Bean framework integrates the idea of context management, which enables external conversational interactions to be established
in the case of multiple-client access.
Session Beans can implement
“ business services ”.
Entity Beans also integrate security,
transaction and distribution frameworks. Unlike Session Beans, they support persistence. EJBs are used to implement what are commonly called
“ business objects ”; they are designed
to allow business entity modeling.
Therefore, Entity Beans are of the most
interest to us in this evaluation because we want to explore EJB technology’s capacity to implement business
object modeling into an information
system.
EJB implementations
In order to judge EJB implementations of
the leading tools in the field, we tried to implement a simple object model in collaboration with the editors of the following EJB solutions:
• IBM WebSphere 2.0.2 Advanced Edition
• BEA WebLogic Application Server 4.0.2
(we then updated our evaluation using
WebLogic Server 4.5.1)
• Gemstone/J 3.0
• Oracle Application Server 4.07
• Inprise Application Server
www.trendmarkers.com
We relied on several development tools
that are specifically adapted to EJB creation:
• IBM VisualAge for Java Enterprise Edition 2.0
• Symantec VisualCafe 3 Database Edition, Visual Cafe Enterprise Suite 3.1
• Inprise JBuilder 2 for Application Server
As seen in the following diagram, the object
model to implement is very simple:
Automobile
*
1
Model
idModel : String
manufacturer : String
description : String
-----------------------idModel () : String
manufacturer() : String
description() : String
setIdModel(String idModel)
setManufacturer(int manufacturer)
setDescription(string
description)
idAut: String
model: Model
cylinder: int
price: int
slogan: String
------------------------idAut() : String
model(): Model
cylinder (): int
price():int
slogan():String
setIdAut(String id)
setModel (Model model)
setCylinder (int cylindr)
setPrice (int prix)
setSlogan(String slogan)
lengthGarantee():int
Inheritance
AutomobileNew
LengthGuarantee():int
AutomobileUsed
condition : String
-----------------lengthGarantee():int
state() :String
setState(string state)
The object model includes inheritance and
association between different classes of
objects. The model had to support the four
following points:
•
•
•
•
persistence
OTM
distribution
referential integrity
The verdict: Having previously worked on
several projects using OO modeling, we
have experienced just how difficult it is to
succeed without a good tool. The high standards of appreciation that we set during
our evaluation were thus justified.
We noticed that the EJB implementations
evaluated do not allow implementation of
this very simple model. None of these four
points is satisfactorily supported by the
EJBs tested.
(Continued on page 6)
December 99
4
6
EJBs from a critical perspective (cont.)
(Continued from page 5)
Of course, this does not cast doubt over the
global quality of these products, known for
other technologies such as servlets, relational database access and JSPs. However,
since none of the four points was supported, we maintain that EJB technology is
still immature.
Note: A complete description of this evaluation is available in TechMetrix Research’s
Java Application Server Report and Product
Reviews.
Gemstone/J
Contrary to a widespread idea, Gemstone/J
does not satisfactorily support Entity
Beans, which makes it impossible to implement our object model using EJB. In fact,
Gemstone recommends using its non-EJBbased PCA architecture (Persistent Cache
Architecture). This PCA architecture functions and allowed us to implement the
model. It is thus possible to use a part of
EJB technology, Session Beans, to present
clients with an EJB facade. Session Beans
can then manipulate the business model,
which is implemented via the PCA. In terms
of productivity, Session Bean development,
deployment and administration prove to be
extremely cumbersome with Gemstone, especially since the documentation is also insufficient. However, Gemstone offered excellent technical support during our evaluation.
WebLogic Application Server
The EJB implementation proposed by WebLogic Application Server is insufficient, as
is the one offered in the new version 4.5.1.
WebLogic, which is based on the 1.0 specification, offers poor support for Entity
Beans (especially concerning object/
persistence associations), development is
cumbersome and there are important malfunctions of EJB-associated utilities. As was
the case with Gemstone, the product’s editor BEA provided great technical support
and allowed us to attend internal training
sessions for WebLogic consultants.
Inprise Application Server
JBuilder, Inprise’s development tool, allowed us to develop EJBs, but the Inprise
Application Server was not able to run them
because it doesn’t have an EJB Container.
The next release of the product should offer wider support. At the beginning of October 1999, during the Internet World conference, Inprise announced that this draft of
the product is currently in beta version.
WebSphere/VisualAge for Java
WebSphere 2’s EJBs do not allow for implementation of even a very simple business
object model either. The tools appear to
propose persistence and transactions, but
since integration between VisualAge and
WebSphere is not perfect, in the end it’s a
failure. WebSphere users indicate that IBM
engineers confirmed that the WebSphere 2
EJB implementation is still at a preliminary
stage. It is interesting to read more about
this subject in the IBM Redbooks (www.
redbooks.ibm.com).
Oracle Application Server
We could not implement our model because Oracle Application Server does not
offer support for Entity Beans.
On this point, Oracle’s position must be examined carefully. Indeed, even though Oracle is an Enterprise Java Bean supporter,
the company does not share SUN’s vision
about this technology. In particular, Oracle
is fiercely opposed to Entity Beans as a
general model for business objects. In the
future, it is likely that Oracle will integrate
Entity Bean support into its application
server to be in sync with EJB specification,
but will not recommend using it for general
and large-scale object modeling.
Other products
We also looked into other products such as
(Continued on page 7)
www.trendmarkers.com
December 99
4
7
EJBs from a critical perspective (cont.)
(Continued from page 6)
Persistence PowerTier from Persistence
Software, which wished to wait for the next
version of its product before taking part in
our evaluation (note: this release is now
available).
In some cases, the situation is surprising.
For example, Haht Software announced
that EJBs were integrated into its application server HahtSite. In reality, its last version HahtSite 4.0 offers nothing of the sort.
Product conclusions
In conclusion, we maintain that, generally
speaking, the following problems remain:
•
•
•
Almost totally impossible to implement
even a simple object model
Cumbersome development
Complex deployment, non-portable
EJBs , non-portable clients
EJB specification
The EJB specification is destined for editors
of application servers or development environments. This specification describes the
different element interactions that need to
be present in an EJB-compatible implementation. This specification ensues from the
fact that programs using EJBs must be
portable. The editors of EJB-compatible
servers must therefore conform to some
very strict rules.
The specification is a document of more
than 300 pages and is currently in version
1.1 (EJB specification of 8/11/99). The
specification is classified as “ preliminary ”.
Even though it has been globally improved
since version 1.0, considering its objectives, the specification still has some considerable technical and theoretical problems.
There are two reasons for this. First of all,
numerous points of the specification are
incomplete; consequently EJB semantics
are under-specified. This results in incompatibility of EJB environments and a lack of
The EJB specification is
destined for editors of
application servers or
development environments.
This specification describes
the different element
interactions that need to be
present in an EJBcompatible implementation.
important functions. Secondly, in its current
state, some points of the specification create real problems for object model implementation. One must keep in mind that today there are object technologies that have
the same objectives, but that have already
proved themselves and do not have these
problems (object databases, object/
relational-mapping frameworks, OTM).
Below are several prominent problems of
the current specification:
Limited function of large-grain objects
For each instance of an EJB business object, there are a certain number of system
object instances ("EJB object", "EJB context" and often other helper or wrapper objects). In this way, at runtime system layers
encapsulate each business object instance. A business object in the form of an
EJB must never be directly referenced, but
always via these layers, which ensure security functions, transaction management, object distribution, thread management, etc.
Even in non-distributed mode, these objects reference one another by passing
through this layer. For each object interaction, each method call, all the security and
(Continued on page 8)
www.trendmarkers.com
December 99
4
8
EJBs from a critical perspective (cont.)
(Continued from page 7)
distribution transactional machinery is
used. Moreover, it is common to transfer
the control between threads since EJBs are
often executed within several threads. All of
these mechanisms take a lot of time and
require memory resources.
Business
Object
Transaction, security,
distribution etc.
Business
Object
Transaction, security,
distribution etc.
ber of objects, these objects having to communicate between each other by sending
messages in order to complete tasks. Reentrant communication is not uncommon. For example, it is common that
an object A send a message to object B
and that the latter also sends a message
since it needs to communicate with A in order to accomplish its task. Many objectprogramming design patterns use this type
of function.
Object A
Object B
Each business object is encapsulated within several
service layers. Method calls must pass by these layers.
Method Call
Because it is so cumbersome, this system
is not adapted to the development of finegrained business objects, in other words,
business objects with a large number of instances and methods that are often called.
The EJB specification is very clear: “ The
overhead of an inter-component call will
likely be prohibitive for object interaction
that are too fine-grained. ”. This considerably limits the application field of EJB technology.
It is thus recommended to use EJBs only
for “ big ” objects, whose methods are not
often called. These objects are obviously
made up of smaller (fine-grained) objects,
which shouldn’t be implemented in EJB
form. But we cannot specify within the EJB
framework how these fine-grained object
relationships must be managed or how
they must be saved in the database
(persistence). The current situation is thus
problematic in relation to the original goal
of EJBs, which is to provide a business
component model. Indeed, such a model
must include fine-grained support. We cannot imagine how the problem could be resolved without radical evolution of the
specification.
No Support for Reentrancy
An application developed with object technology is constituted at runtime by a numwww.trendmarkers.com
Waiting
Nested Call (reentrancy)
Code executed
Waiting
Nested call returned
Waiting
Call returned
Example of reentrancy call
But, the manner in which EJB technology,
particularly in terms of threading, functions
make it a programming mode that is difficult to implement. Thus, the EJB specification indicates that programming such callbacks is illegal for Session Beans and extremely dangerous for Entity Beans.
If such programming cannot be avoided,
the specification points out that programmers need to be extremely prudent. However, there is a more specific guide in neither the specification nor in any product
that we have tested; this renders the situation intolerable.
Under-specification of object associations
Although version 1.1 of the EJB standard
improves on this point in comparison to
version 1.0, the notion of association be(Continued on page 9)
December 99
4
9
EJBs from a critical perspective (cont.)
(Continued from page 8)
tween objects remains considerably underspecified.
Critical aspects are not supported, for instance, management of referential integrity
and partial loading of object graphs in
memory.
Incompatibility with the standard Java
model
The specification introduces incompatibilities between the EJB component model
and the standard Java object model. In
some cases, this makes it impossible to
use frameworks designed for the standard
Java object model with EJBs. This is why
the EJB model does not ensure ascending
compatibility with the Java object model.
Here is an example of incompatibility concerning the concept of object identity. In order to determine if two Entity Beans are
identical, the specification indicates that
one must always use the method isIdentical(). Use of the operator "==", the equals()
method and the hashcode()method is not
allowed. The problem stems from the fact
that here we get away from the standard
Java model, which uses these methods in a
traditional manner. The numerous existing
frameworks that are based on this model
for the notion of object identity cannot easily be used with EJBs.
Under-specified distribution model
The specification remains extremely blurry
on the semantics of remote access to EJBs,
which in itself will inevitably create problems in practice. Nonetheless, it often mentions RMI/IIOP (RMI on the IIOP protocol instead of the traditional JRMP). It is also
mentioned that EJB-compatible servers can
use RMI/IIOP to handle distributed object
service. This technology must allow Java
objects to communicate remotely between
one another, for example, communication
between a client and a server. It must also
www.trendmarkers.com
handle communication between Java objects and non-Java objects that are implemented according to the CORBA model,
which permit, for example, a CORBA C++ or
Smalltalk client to invoke EJB services.
The problem is that RMI/IIOP technology is
very young. It is just beginning to be diffused, even if some products have included
its preliminary version.
RMI/IIOP is often presented as offering the
same semantics as RMI, but this is not exactly the case. Indeed, RMI/IIOP and RMI
semantics diverge on several points, the
most important being without a doubt object life cycle management. While RMI is
based on a distributed Garbage Collection
system, RMI/IIOP offers nothing of the sort.
The manner in which the object life cycle
and application connections are managed
has a strong impact on development. This
is why, generally speaking, RMI/IIOP programming cannot be the same as RMI programming. Moreover, it is obvious that on
this point RMI/IIOP will have to provide a
solution.
Client
Client
Client
Client
RMI/IIOP
EJB
Client
Client
An EJB can be referenced by several
remote objects. EJB life cycle
management must take these
references into account.
Furthermore, RMI/IIOP is based on a recent
OMG specification regarding the transfer of
object by value (OBV).
In practice, this OBV specification is not
sufficient since binding with most of the
CORBA-supported languages is not adopted
yet (for some, propositions haven’t even
(Continued on page 10)
December 99
4
10
EJBs from a critical perspective (cont.)
(Continued from page 9)
been made). This means that multilanguage interoperability is merely theoretical for the moment. Even more serious, the
current OBV specification is extremely complex and suffers from significant technical
problems (see Steve Vinoski’s “New Features for CORBA 3.0”, Communications of
the ACM, Volume 41, No.10). Vinoski
writes, “The OMG is currently reviewing its
technology a d o p t i o n procedures with the
goal of preventing similar hasty and illadvised addition to CORBA in the future.”
No support for inheritance at the
component level
The component model defined by the EJB
specification does not support inheritance.
During development, a component is presented as a package made up of classes
and Java interfaces, XML files full of information, and metadata about the package.
During runtime, a component can be instantiated several times. Each instance of
a component is presented in the Java virtual machine as a group of Java-class instances interacting between one another.
This group includes the classes that are
automatically generated by the EJB environment during component deployment.
An EJB component is thus much more than
a standard Java object. It integrates rules
concerning security, transactions, persistence, etc. Although inheritance exists between Java classes and can still be used,
there is no inheritance between EJB components. This point may not pose a serious
problem, but it helps us have a better
global understanding of EJB technology.
Non-portability
EJBs are often presented as a portable
component model, meaning that it would
be possible to create or buy an EJB and
make it work straight away on any environment that is compatible with the specification.
www.trendmarkers.com
Enterprise JavaBeans do
deserve merit for separating
portable aspects from nonportable aspects, while
trying to reduce the latter as
much as possible.
This is misleading. Indeed, the norm clearly
leaves many technological issues to the
discretion of each editor of an EJB environment. It’s customary that, for each environment, the EJB be configured in a specific
manner (for example, which concerns object/relational mapping). This configuration
described by the specification as the
“ deployment ” step can be quite complex.
Enterprise JavaBeans do deserve merit for
separating portable aspects from nonportable aspects, while trying to reduce the
latter as much as possible. Nonetheless,
the non-portable aspects have not disappeared.
We should note that this point is not necessarily crippling and that concurrent component models are not more portable than
EJBs, and are often less portable. Nevertheless, it would be rash to present EJBs as
portable components.
Static glue
Note: We begin this section with an explanation of static and dynamic glue. We then
provide the EJB specification’s chosen solution.
In order to ensure proper functioning of different services (security, transactions, distribution, etc.) EJB technology is based on
the use of “ systems ” objects, which encapsulate, or even mix with, business objects. The goal of these objects is to offer
the services mentioned above in the most
transparent manner possible. For example,
for calls between distributed objects, one
uses intermediary objects (stubs and skele(Continued on page 11)
December 99
4
11
EJBs from a critical perspective (cont.)
(Continued from page 10)
tons [or remote interface]), which automatically handle network message routing and
many other service tasks. All these objects
make up what we call the “ glue ”. They permit business objects that one develops to
function together, by following the semantics defined by the EJB model. They do not
need to be programmed by the application
developer, but are provided by the system.
This glue technique has been widely used
for a long time in object technologies. One
finds it for example at the core of COM/
MTS, CORBA, RMI and in object/relational
mapping frameworks, object databases
and parallel programming models.
One can define two types of glue: static and
dynamic. Static glue, a technique adopted
by the EJB specification is ad hoc glue, for
which the code is generated in relation to
the application classes. Dynamic glue is generic glue that can adapt to any new class.
One of the consequences is that with a
static glue system, one will have as many
“ Stub ” classes to deploy client-side as
there are EJB components server-side.
However, with a dynamic glue system,
there is only one “ Stub ” class, which can
adapt to all situations, client-side or serverside.
Business
Object
Transaction, security,
distribution etc.
Each business object is encapsulated within several
service layers. The code of these layers is specific to the
business object class: the code must be generated for
each business class.
With EJBs, for each component, a group of
classes is generated to handle different
services. This code must be generated at
each addition and often each time a component is modified. The resulting code
must be deployed at adequate places in
the system, which often includes client stawww.trendmarkers.com
tions. Furthermore, sometimes one would
like server-side EJB components to call client-side object methods. In this case as
well, code generation, followed by deployment must take place. Java includes ways
of making this step somewhat automatic.
Nonetheless, experience proves that in
practice, this deployment poses some very
serious problems. In addition, static glue
weighs down the system and makes it
more complicated for EJB-server
implementers and application developers.
Indeed, the glue is never transparent for
the latter.
The choice of a static glue system for EJB
technology will largely determine, in the
long term, the technical capacities and
ease-of-use of this technology. If one can,
with reason, argue that some basic characteristics of Java language push in favor of
this choice, the fact remains that it is an
aspect that will have tremendous influence
on the success of Enterprise JavaBeans as
a standard component model for businesses.
Our experience with projects using object
technology incites us to think that the cumbersomeness and complexity brought
about by static glue is a very serious obstacle to large-scale enterprise use. CORBA
runs into this same problem and we think it
is one of the main reasons that it hasn’t
been more widely adopted. Recent OMGadopted technologies like IDLScript, which
are based on dynamic glue, may change
the situation for CORBA. Microsoft COM
suffers from the same problem and has
thus far managed to deal with it using its
Automation interfaces (as illustrates the
success of VB in corporations).
We strongly believe that dynamic glue is going to be one of the next big trends and
that EJB will have a hard time challenging
these dynamic component systems to
come.
(Continued on page 12)
December 99
4
12
EJBs from a critical perspective (cont.)
(Continued from page 11)
In the future, there are two possibilities.
Firstly, problems within this technology cannot be overcome and EJBs, in particular the
use of Entity Beans, remain marginal. Does
this signify the failure of J2EE? Yes, in
terms of one of J2EE’s initial goals. But this
would not affect the other technologies
that make up the platform (servlet, JDBC,
RMI, etc.) because these technologies,
which are quite likely be adopted, do not
depend on EJBs.
In the second case scenario, the specification and the products evolve in response to
companies’ needs in terms of the object
approach. EJBs could thus become the
principal component models of the market.
Other issues
There are many other issues that will have
to be addressed by the specification, for instance, problems with transaction isolation
levels and polymorphic use of finder methods.
Conclusion
We have presented a critical report about
the current state of EJBs. It is easy to find
documents that present this technology’s
assets and it would be very useful to consult them in order to get a global idea of
the question. We think that choosing this
technology for the implementation of a serious object model could lead to considerable disappointment, notably due to the
technology’s immaturity. The worrying gap
between marketing material and the reality
of EJB technology today increases this risk.
In any case, when making such a choice
the elements highlighted in this report
should be taken into account. Within the
framework of object modeling, alternatives
such as some object databases or object/
relational frameworks can be considered.
We will continue to follow the development
of this technology very closely in coming
months.n
Related Links
• The best EJB information can be found on:
http://archives.java.sun.com/archives/ejbinterest.html
•
Sun’s EJB forum:
http://forum.java.sun.com/forum
•
Also check out:
http://www.ejbnow.com
http://www.ejbportal.com
TrendMarkers is a publication of:
TechMetrix Research
6 New England Executive Park, #400
Burlington, MA 01803
Phone: 781-270-7486
Fax: 781-270-7487
E-mail: trendmarkers@techmetrix.com
www.trendmarkers.com
December 99