EJB components: Distributed object containers this way come
- By Jack Vaughan
Components have long been
touted as a means to distributed computing. Enterprise JavaBean servers may
move that dream closer to reality, some users suggest. Scalability and portability
are big pluses.
For some while, components
have been an academician's dream. Why? Because they represent a way of partitioning
systems so things work together more easily. But the theory of components has
been hindered in the real world of corporate development. As each door has opened
on a component Nirvana, yet another door has been found.
Microsoft has come up with
a useful component architecture, sometimes called COM+, which, in keeping with
most component definitions, provides a blueprint describing how things can work
together. But it frustrates academicians and many others because it really only
works with 'things Microsoft.'
Percolating in the background
are Enterprise JavaBeans (EJBs), which may eventually become the closest thing
yet to a heterogeneous component methodology. EJB represents an emerging industry
agreement as to what mid-tier system logic is, and how it should be represented.
Interestingly, the EJB server may become the next test-bed for open source software
Even its greatest advocates
would probably not liken the rage for EJBs to that for the Java programming
language, which started around 1995 and has not abated quite yet. EJB followed
in Java's wake and represented an industry effort — some would say an anti-Microsoft
effort — to enhance Java for corporate computing. Before EJBs, a host of Java-speaking
application servers, acting as holders of business logic on the middle tier
of three-tiered computing, were unleashed on the public.
While rarely a topic of
much discussion these days, EJBs may now be more important than when they were
the latest "hot" technology. Today's app server technology is the closest thing
yet to standardized "out-of-the-box" distributed computing, and it is the EJB
component standard that, to a large extent, makes this possible.
What amounts to an application
server these days (at least outside the Microsoft-only camp), pretty much revolves
around EJBs. Most of the premier providers offer some form of EJB support, all
the better to ensure that their offer- ings provide some type of portability,
which is, after all, Java's chief claim to fame.
These days, EJBs are usually
discussed as part of the broader J2EE proposed by Sun Microsystems and endorsed
in some way or another by many industry players. J2EE defines not just EJBs,
but Java servlets, Java Server Pages (JSPs) and other formats. J2EE is not an
open source standard at this point, although Sun has tried to forge what it
calls an open community process to promote the J2EE standard. Java servlets,
at least, have edged toward the open source software sphere, via reference specs
shared with the Apache Software Foundation. It is worth noting that some observers
anticipate some type of EJB reference standard to emerge on the Apache front
in the months to come.
Among the makers of EJB
servers are BEA Systems Inc., San Jose, Calif.; Bluestone Software Inc., Mount
Laurel, N.J.; Excelon (formerly Object Design Inc.), Burlington, Mass.; GemStone
Systems Inc., Beaverton, Ore.; IBM Corp.; Inprise Corp., Scotts Valley, Calif.;
Iona Technologies Inc., Cambridge, Mass.; Lutris Technologies, Santa Cruz, Calif.;
ObjectSpace Inc., Dallas; Oracle Corp., Redwood Shores, Calif.; Persistence
Software Inc., San Mateo, Calif.; Progress Software Corp., Bedford, Mass.; Secant
Technologies Inc., Cleveland; SilverStream Software Inc., Burlington, Mass.;
Sterling Software, Plano, Texas; Sun Microsystems Inc., Palo Alto, Calif.; Sybase
Inc., Emeryville, Calif.; Tower Technology Corp., Austin, Texas; and Unify Corp.,
San Jose, Calif.
While most of these vendors
have skilled and sizable service organizations, they may eventually become concerned
that low-cost, "open source" alternatives will become as potent in the application
server space as Linux has in the OS space. Several companies are pursuing such
solutions, including Telkel Inc., San Francisco, Lutris Technologies and BullSoft,
Billerica, Mass., which are not your garden-variety open source shops. Among
their potential customers are those that say application servers need no longer
be a rich person's game. And even among big-time corporate developers with deep
pockets, there may be those that, after battling user-CPU-pricing, would like
to cut server-CPU-based pricing down to size.
Clearly, the prominent EJB
backers are Sun, which is famous for inventing Java, and IBM, which is famous
for focusing on the enterprise. For IBM, EJB has immediately come into use as
a means of migrating users from the company's proprietary SanFrancisco component
architecture to an industry standard. But using EJB as a SanFrancisco replacement
has not always been easy. EJB has been a moving target in its infancy as important
elements of the standard have been written and added, and then re-written and
re-added. [See "Fog lifting on SanFrancisco," ADT, September 1999, p. 28.]
While several software players
have taken a swing at creating EJB servers, EJB might still be well described
as a paper spec. Which is not all that bad. Even if it is a stack of documentation,
EJB can be a reference spec for component-style development, something that
has long been under discussion. The optimistic view would hold that the wild-and-wooly
Java server will gradually give way to a well-defined EJB container to borrow
some of the terminology of Ovum Inc. expert Neil Ward-Dutton [see "Containers:
A sign components are growing up," ADT, January 2000, p. 41].
The term container has specific
meaning in the "Bean world,'' but it may be useful to think of the emerging
class of enterprise application servers as containers. Containers, that is,
with services. These services — load balancing is an important example — and
the interfaces that describe component interaction are, while not dummy-proof,
perhaps defined more adeptly than in earlier times.
EJB and J2EE
At its heart, EJB is a
component architecture that has brought real definition to the role of the application
server. It still requires tooling, but it could very well signal the end of
handcrafted APIs of yore. Great swaths of functionality can now be bought off
the shelf or assembled using fairly comprehensive blueprints.
This is not to say EJB technology
is a slam-dunk success. Check out an online distributed computing news group
and you discover that, when it comes to EJB, there are usually more questions
than answers. EJB is largely a "Java game" and the Object Management Group's
new CORBA Component Model (CCM), deemed a language-agnostic architecture that
encompasses many EJB-friendly APIs, may gain adherents among those who do not
yet have both feet in the Java camp. And Microsoft's COM+ server architecture
is certainly a potent competitor.
Alex Kalinovsky is enterprise
Java manager at Web-oriented application development firm IonIdea Inc., Fairfax,
Va. As part of its business, IonIdea had been developing and delivering functionality,
and developing and delivering it again with each encounter. "We programmed transactional
support, messaging, logging, access control and user management," said Kalinovsky.
"Prior to J2EE, we built
our own proprietary framework," said Kalinovsky. IonIdea also employed a variety
of distributed computing technologies, including Java, CORBA and Remote Method
Invocation (RMI). "A lot of that functionality is delivered today with J2EE,"
said Kalinovsky, who has used J2EE since last spring. There were also application
vendors delivering that functionality, he added. They ranged from small vendors
to big players such as BEA Systems and IBM.
"What's happened with J2EE
is that Sun and other vendors have created a common set of APIs that the Java
community can rely on," he continued. "The APIs describe what common set of
functionality the vendors shall provide."
In time, users should be
able to rely on this as a standard across vendors. However, this is where things
can get dicey. "It's not an ideal picture," noted Kalinovsky on the idea of
working with a commercial EJB app server. "Even if you architect it properly,
there will be a small portion of your app that is vendor-specific."
But EJB seems to be on a
steady course, said Kalinovsky. "Two years ago, if you started developing for
a Netscape server, you could not go to Forté. You pretty much had to rewrite
half of your apps."
Today, moves between some
EJB application servers are more readily achieved, he said. "Sometimes it's
minimal changes, but [services] are portable to a large degree."
As noted earlier, EJB is
just one aspect of J2EE, which includes messaging methods (JMS), servlet standards
(Java servlets), page generation standards (JSP), database connectivity formats
(JDBC) and the like. "EJB covers server-side business logic," said Kalinovsky.
"You cannot build an application with EJB alone."
When asked what common problems
an EJB novice should expect to encounter, Kalinovsky becomes philosophical.
"Everybody wants high-performance apps. And everyone wants to be on time and
on budget. Meanwhile, everybody wants to be more or less in line with where
the rest of the industry is going.
"But there's no single technology
that will be best for every application," he continued. "Simplicity usually
translates into a performance gain. In such cases, you may not want to use something
like EJB. If it must handle thousands of transactions per minute, and these
must be load balanced, then you need an infrastructure. Simplicity is not your
Kalinovsky suggested that
developers might want to start with departmental initiatives and other aspects
of J2EE — servlets, JDBC and the like — before tackling EJB. "Later on, if you
want to produce an enterprise application, you can add EJB. You don't have to
redo the whole application," he noted. He suggests such an approach is not as
readily available with the competitive COM+ component standard. "If you do something
in Visual Basic, you can only grow the app so much," he said.
As may be expected, ease
of programming can be relative, and the stumbling block in EJB implementation
may sometimes be architecture rather than code, said Anil Hemrajani, president
at Divya Inc., a Reston, Va.-based firm specializing in Java and Internet software
solutions. "With EJB, the coding part is extremely easy. But architecture and
design issues need to be considered carefully."
For example, scalability
is very im- portant to modern development groups, especially dot.coms. Developers
creating applications for such systems rely on farms of midrange servers that
see transactions surge or ebb as middleware services are invoked. "Portability
and scalability are a couple of the key benefits of EJB," noted Hemrajani. "The
EJB design provides scalability as long as vendors implement the spec faithfully."
Scalability aside, standards-compliant
implementations historically incur some performance degradation. EJB designs,
if not fully thought out, are probably not an exception. [In fact, one firm
has produced something of a specialty product to test Beans in the field. TestMyBeans.com,
a Teradyne company based in Waltham, Mass., has formed to meet the needs of
developers who must work through scalability problems as they find that designs
that worked on one or two machines collapse as the transaction load increases.]
EJB session and entity beans
should be particularly well measured, said Hemrajani. Entity beans may be stateful
or stateless. "If your architecture calls for a lot of stateful session beans,
this can bog down performance," he said. If your set-up allows for a fat client
(for example, something more than an HTML window), it is better to maintain
state on the client rather than on the server, he said.
"If you use a regular HTML-based
thin client, then state must be maintained on the server," added Hemrajani.
Java servlets may be an appropriate technology in such instances.
For some, the means to preserve
entity bean state may be bound via object caching of a mode supported in server
products like Persistence Software's PowerTier, Excelon's Javlin EJB Data Server
or others, he said. Because each entity bean can become a row in a database,
performance will vary depending on how DB indexes are built.
EJB in the real world
A view on how application
servers are used today can often be found at an Internet start-up. There, the
issues of advanced technology implementations quickly clash with Internet time-to-market
issues. Scalability, graceful fail-over and the ability to place numerous servers
delicately in clusters are all part of the parcel and one of the reasons some
opt for EJB servers.
Here and elsewhere, the
theoretical merits of EJB "containers" are being tested. Kumar Goswami, president
and CTO at Kovair Software Inc., San Jose, Calif., wrestled with such issues
as he worked to launch Kovair.com. Kovair.com is an ASP service that generates
unique Web sites — and unique views of Web sites — on-the-fly for companies
that partner to create strategic alliances and partnerships.
Kovair's overall site must
support a large number of clients. "Pages are spun off in multiple formats,
both HTML and WML [Wireless Markup Language]," said Goswami, "so it is important
that logic levels be maintained separately and perform robustly." Kovair.com
also deploys its system at dedicated data centers. "We're running multiple companies.
It has to be highly available. It has to be up 24x7," he added.
Central to all of this is
a great deal of business logic software, feeding or being fed by a data software
layer. "We have EJB servers, that we [associate] with a farm of Oracle databases,"
For this implementation,
Kovair turned to BullSoft and its JOnAS EJB server. "We evaluated several servers
and liked what BullSoft had to offer. We felt comfortable that BullSoft's approach
was an open source approach," said Goswami. "All the app servers were in early
phases, and we were concerned about bugs. We felt that with open source software,
if we had to, we could address problems ourselves. We didn't have to, but the
comfort was great."
One of the firm's big requirements
was to move work from one app server to another as needed. EJB provided a way
of doing this. "We also felt the EJB spec was reasonably well thought out,"
With EJB's distributed nature,
users can actually distribute beans across multiple machines. Goswami said EJB
did a lot of the transaction management that they would have had to do themselves.
"Using these servers, we
gained a lot of time. We would have had to build a lot of this functionality
ourselves. Time to market is crucial for what we're doing," he noted.
Other aspects of the J2EE
spec helped Kovair.com obtain time to market, said Goswami. "Above EJB, we employ
a servlet layer for caching and authentication. The EJB server is where the
logic is that allows us to go to HTML and WML."
Enterprise JavaBeans also
provided Kovair with database transformation and object-relational mapping methodologies.
"One of the things I liked was that we did not have to do a lot of the database
transformation work, [such as] taking the tables out of the database and turning
them into objects," noted Goswami.
"Different EJBs can work
hand in hand," he said. But, Goswami added, "I wish there was more plug-and-play
[compatibility]. People say the migration is minimal, but there is an effort
Which road will EJB travel?
Keith Bigelow, director
of product marketing at Lutris Technologies, can provide a capsule view of the
history of application servers and, more importantly, where they may be going.
"Five years ago, there really
were no app servers out there. Each application you wrote was going to be a
CGI program," said Bigelow. "The purpose of those app servers was to access
a database and to provide an HTML page as dynamic content. The goal was to take
things to and from forms without rekeying.
"There were no standards
at that time to solve this problem in a non-proprietary way," he continued.
"Most people have slowly been adopting server-side Java standards. The first
meaningful standards were Java servlets."
Bigelow said Lutris has
been consulting on the Web application server front just about from the beginning.
As part of a joint effort with Netscape in 1996, Lutris' first client was Federal
In 1999, Lutris made its
own application server tool set available to the public as open source software.
The company released the source code hoping people would update it. Lutris has
seen results as contributors have fielded wireless servers based on the technology
and pitched in on bug fixing.
Last year, Lutris allied
itself with BullSoft and France Télécom to provide a more rounded selection
of distributed tech- nologies. The goal was to combine Lutris' Enhydra Java/XML
application server, BullSoft's JOnAS EJB server and France Télécom's Jonathan
CORBA ORB to deliver a customizable Open Source application server that would
scale the entire range of Internet applications.
Bigelow agrees with those
who say Java servlets are a useful standard, but that EJB can provide values
that servlets (and Java Server Pages) do not. "EJB allows you to move to a componentized
architecture. [The beans] are designed to have public interfaces, which provide
an easy way for them to know how to interact," he said.
In contrast, said Bigelow,
servlets are a one-off-type solution. "It's rare that you reuse much servlet
code," he said. "EJBs, and COM+ as well, are all about reusing business logic."
Also, EJB can scale up from one to many instances of a service running on many
Lutris is adding EJB support
to its Enhydra Java app server to meet these enterprise issues. That application
server source code is available to the public.
"We want to commoditize
EJB," said Bigelow. Lutris' agreement with BullSoft, and overall industry interest
in open source software, could help make this happen.
Where is the EJB standard
going? It appears to have become a stable part of the overall J2EE format. Certainly,
XML linkage will be under consideration. The industry should know more next
month when Sun's JavaOne 2000 Conference is staged in San Francisco. Sun has
traditionally taken such occasions as cues to disclose software road maps. In
the meantime, the parent of Java will come under renewed pressure to make portions
of Java, and EJB, open industry standards. "Open source" EJB servers, unquestionably,
will be part of that discussion.