Sun's Java Studio on target
- By Jason J. Meserve
Are Enterprise JavaBeans the silver bullet for component-based development on the
middle tier? Since the specification is only two months old, it will be a while before anyone knows for sure. Tools
and hosting platforms need to be built before any dreams are realized. But with seemingly everyone but Microsoft
behind the newest Sun Microsystems' specification, it will surely be interesting.
Given the number and weight of the players supporting the architecture, Enterprise JavaBeans (EJBs) can be said
to be coming online with the force of a train. Although still a very new technology, many are counting on EJBs
to enable deployment of components on a range of servers.
What are EJBs and how do they differ from plain JavaBeans? The plain JavaBean specification is a client-side
component model for linking together bits of code like building blocks, to form an applet or Java application.
Typically, JavaBeans are graphical user interface components, such as a button or calendar box, that can be plugged
into a Java program. Theoretically, all a JavaBean needs to operate is a Java Virtual Machine, found as part of
a standard Web browser. JavaBeans are readily available, with a number of tools supporting their use, including
Java Studio from Sun, PowerJ from Sybase Inc., Emeryville, Calif., VisualAge for Java from IBM, and JBuilder from
Inprise Corp. (formerly Borland International Inc.), Scotts Valley, Calif.
"The 'Enterprise JavaBean' name is confusing because it is not a component model in the sense that ActiveX
and JavaBeans are," said Scott Dietzen, vice president of marketing for WebLogic, San Francisco. "EJBs
are middleware abstractions that manage persistence, security and reliability for server-side business logic."
In a rail system, a train needs a track on which to operate. EJBs, in turn, need a container in which to live
and function. Containers can take the form of middleware (such as IBM's TXSeries) or an application server (such
as WebLogic's Tengah). Containers manage a given class of EJBs by providing security and protocol transaction support.
The container also manages the EJB's state. Data in a given bean may be needed only for a single transaction or
could be replicated across multiple transactions.
EJBs, as initially defined, exist in two flavors: Session beans and Entity beans. Session beans act on behalf
of a single client and are typically used to update data in a database. They can be "transaction-aware"
and usually expire when the client is shut down. Conversely, Entity beans may be shared by multiple clients, are
involved in transactions and are persistent. The latter are also more durable and can withstand server (container)
It may be worth noting that Entity beans, which were a required part of early EJB draft specifications, were
labeled optional in the final release, according to Jason Woodard, program manager for Java technical marketing
at IBM, one of the major contributors to the EJB spec. "[IBM] pushed for it as a requirement, but other vendors
did not see it as a priority," Woodard said. "Over time it will become a requirement in subsequent releases
of the specification," he added. Support is expected in the EJB 2.0 specification, which has no set timetable
Clients cannot talk directly to the EJBs. The container wrappers the bean and exposes the application interfaces
for a given EJB via a proxy "EJB object." EJB objects limit what interfaces clients have access to, keeping
the management and control interfaces used by the container hidden. Another bean, known as "home," acts
as a directory to find all of the other EJBs within an application.
"EJBs allow developers to build business applications as components and lets them focus on the business
logic," said Shandra Achanta, a product line manager at JavaSoft, repeating a mantra spoken by all EJB supporters.
"It pushes the plumbing down ... abstracts it away from the developer." [Ed. note: Sun Microsystems recently
realigned its business organization. JavaSoft is no longer an individual operating company; it is now known as
the Java division of Sun Microsystems.]
The "plumbing" an EJB hides includes network protocols and six Java application programming interfaces
(APIs) released by Sun:
- Java Transaction Service (JTS) -- handles distributed, two-phase commits to databases and provides open access
to multivendor transaction systems.
- Java Management API (JMAPI) -- a set of Java classes and interfaces that allow developers to build system,
network and service management applications.
- Java Naming and Directory Interface (JNDI) -- just what the name implies. Allows applications to find EJBs
and specific containers.
- Java Interface Definition Language (JIDL) -- provides mapping between EJBs and Corba, as well as a lightweight
object request broker (ORB) that supports Corba's Internet Inter-ORB Protocol (IIOP). JIDL is part of the upcoming
JDK 1.2 release. Sun is quick to point out that while EJBs and Corba are tightly integrated, EJBs are not based
on the Corba specification. EJBs are protocol-neutral.
- Java Messaging Service (JMS) -- a Java-based publish-and-subscribe middleware system.
- Java Database Connectivity (JDBC) -- the Java kin to ODBC for database connectivity in a thin-client environment.
All of these services are hidden in the eyes of the developer, allowing the concentration of effort on business
logic. Part of their supposed magic is "introspection" -- the ability to describe their own behavior
at runtime, something that only a compiler could see in the past.
What makes them so special?
In the early 1990s, PowerBuilder from Powersoft -- now a division of Sybase Inc., Emeryville, Calif. -- gave
Windows developers the "data window," a simple, code-free means of programming database access into an
application. A number of vendors have created similar rules-based programming models that allow designers to focus
on the business logic and not on the mundane hand-coding and underlying API calls. However, the difference between
those systems and EJB/Java-based applications is portability.
Java's biggest motto is "write once, run anywhere." Everyone has heard it and probably goes to bed
thinking about it. When applied to business logic, in the form of EJBs, it no longer matters where the logic is
hosted, be it in a two- or three-tier environment. It can be moved between tiers, or tiers can be added and removed.
EJBs are platform-independent and can be moved to a different, more scalable platform should the need arise. If
the Pentium NT box hosting the mission-critical application server is beginning to slow, the business logic housed
in EJBs can be moved to a high-powered Unix box without the need to rewrite the logic's underlying code. The same
EJB can also be used across different vendors' containers, since all are bound by the same specification.
"We can work on existing systems," said Bill Roth, a program manager at Sun, "such as layering
on top of a CICS-based system to preserve an investment, but [we can] also give the advantage of new applications."
Few I/S shop have experience with the infant EJB technology. But Java applications have begun to go online and
might indicate the paths EJB development may take. Terrison Gregory, director of decision support applications
at Pacific Bell Video Services (PBVS) in San Ramon, Calif., likes the idea of reuse and being able to preserve
existing systems. Gregory is in the process of rolling out a new Java-based customer contact application, called
Tracs, that is on the customer service front line. Originally, a "heavily modified" client/server system,
Tracs helped customer agents qualify incoming calls and guide them through the sales process for Pacific Bell's
new wireless cable service. But users had a difficult time learning the system, and servicing it from an I/S perspective
was arduous at best, given that the support center is 100 miles away.
Gregory and one other programmer used Vision Jade from Vision Software Tools Inc., Oakland, Calif., to build
the new Tracs and improve the system's workflow to better match its users. While Tracs does not take advantage
of EJBs at the moment (development began before EJBs existed), Gregory does see it fitting into a future release
of the application later this year.
"The advantage of EJB, which I see as part of a whole movement toward software components, is that [the
spec supports] ready-made components that you don't have to test or develop, and can plug in without needing internal
knowledge of ... just how to integrate it," said Gregory. "That's a quantum leap in terms of development."
A two-horse race
Of course the EJB specification is in direct competition with Microsoft's Distributed Component Object Model
(DCOM) and the Microsoft Transaction Server (MTS), which handles objects in much the same way EJBs are handled.
Theoretically, EJBs should run on MTS and support DCOM, but there is a long history between Microsoft and Sun that
could make it difficult. EJBs are said to be protocol-independent, but they currently rely on Java's Remote Method
Invocation (RMI) protocol to communicate. The Object Management Group (OMG), the Framingham, Mass.-based overseer
of Corba, is in the final process of approving RMI over IIOP, according to IBM's Woodard.
To the advantage of EJBs, COM/ DCOM only works with Microsoft Windows NT and Windows 95 operating systems. "A
COM object can only talk to another COM object," said Onno Kluyt, a senior project manager for JavaBeans.
"In reality, they can only talk to another Win32 [COM object]."
In contrast, EJBs can talk to other beans and Corba objects over a litany of platforms, including legacy systems.
Some suggest the advantage of Microsoft's component model is maturity. COM/DCOM has been around the block, and
there are a number of products and tools shipping that support the model. Only a handful of the tools and server
platforms currently available support EJBs, and most of these only comply with earlier drafts of the specification.
Vendors that have lined up behind EJB say it will be late this year before most of their tools and servers are
1.0-compliant. In addition to the tools and servers, actual beans need to be built before they can be used.
Hitting the tool market early
Inprise was one of the first vendors to release an EJB1.0-compliant tool with the May launch of Borland JBuilder
2.0. The latest release from the renamed company contains wizard technology for building EJBs. "EJB is a big
part of the tool and we worked closely with Sun on the spec," said Gillian Webster, Inprise's director of
product marketing for Internet products. "We've also got good integration with our Corba product [VisiBroker],
which we were looking at."
While Inprise has jumped out of the gate quickly, it will not be long before some of the other household names
in Java development jump into the fray. For example, Sybase announced that Version 2.1 of its PowerJ development
environment will fully support the EJB 1.0 specification.
The current PowerJ release does support standard JavaBean development through the use of wizard technology.
According to Deanna Farrar, Sybase's director of product marketing, fully compliant EJBs can be built by hand with
the current release of PowerJ, but there is not an environment built in to fully support that type of development.
"Most tools make the developer write the interfaces," Farrar said. "We're developing a wizard to
build the bean infrastructure and to keep the developer focused on business logic."
Both Progress Software Corp., Bedford, Mass., and Symantec Corp., Cupertino, Calif., have announced that future
versions of their products, Apptivity and Visual Café for Java, respectively, will support EJB 1.0 development.
Forté Software Inc., Oakland, Calif., has also announced support for the specification in an upcoming release
of its Forté Enterprise Application Environment. Obviously, Sun's Java Studio and newly announced Java Modeler
will support EJBs. The latter will allow the transport of Java classes into EJBs.
IBM's Woodard said his company is easing EJB into its VisualAge for Java product. "We see a lot of value
in tools that create an environment that supports mission-critical applications, so there is a longer [development]
cycle for such tools," explained Woodard. "[With JavaBeans] it was good to get out fast so developers
could use, play and get comfortable with the technology. In the enterprise arena, we'll bring EJB in as a consistent
However, "man does not live on EJB alone," said Web- Logic's Dietzen. "You need all the other
support facilities and APIs to do off-the-shelf plug and play."
WebLogic is one of the many vendors pledging support for EJB, and the firm has already released a 1.0-compliant
version of its Tengah application server. Written entirely in Java, Tengah's EJB offering includes distributed
transactions, the JTS API for "careful transaction management," automatic persistence and replication
of beans over multiple servers. Tengah also supports the optional Entity bean in its implementation. Currently,
Tengah supports only RMI-based communication because "it is a bit easier to program for the Java developer,"
San Mateo, Calif.-based Persistence Software Inc. has also jumped quickly out of the gate with the announced
general availability of their PowerTier application server with full EJB compliance. Persistence claims to speed
overall transaction time by storing the most frequently used transactions and objects in a cache that adheres to
the "80/20 rule" -- 80% of the time only 20% of an application and its data are used.
Sybase's Jaguar Component Transaction Server (CTS) was originally based on the EJB 0.5 specification. "Right
now we have a proprietary interface with the core [EJB] technology, but we're moving toward 1.0 compliance,"
said Sybase's Farrar. She expects a fully 1.0-compliant version of Jaguar to be shipping by year's end. Sybase
has tried to remain standards-neutral, as evident in its support for both the EJB/Corba standard and Microsoft
COM/DCOM (soon to be COM+) standard.
Sybase's two major competitors in the database world, Oracle Corp. and Informix Software Inc., are also stepping
into the fray with planned EJB implementations. Oracle's Application Server and AppBuilder Java development tool
-- based on technology licensed from Inprise --- support what Oracle calls JCorba, a precursor to EJB. JCorba will
eventually evolve into EJB compliance in later releases, said Bill Dwight, vice president of object tools for the
Redwood Shores, Calif.-based database giant.
At Sun's JavaOne, held in San Francisco this past March, Informix announced a strategy to integrate and deploy
Java and EJBs with its Informix Dynamic Server. Developers will be able to invoke JavaBeans from within the database,
while the server will act as a container for EJB deployment. General availability of the technology is slated for
year's end, according to company officials in Menlo Park, Calif.
Other vendors recently announcing EJB support in their server lines include Netscape Communications Corp., Mountain
View, Calif.; Lotus Development Corp., Cambridge, Mass.; UniKix Technologies, Phoenix; Bluestone Software Inc.,
Mount Laurel, N.J.; GemStone Systems Inc., Beaverton, Ore.; NetDynamics Inc., Menlo Park, Calif.; Novera Software
Inc., Burlington, Mass.; and Art Technology Group, Boston.
Given that the above-mentioned vendors will all be implementing the same specification, what will be the major
difference between each offering? "Quality of service implementations will differentiate EJB-supporting vendors,"
said Frederic Bonnard, product manager at Netscape. "It will be great for developers, as they will have a
standard way to develop Java applications in the middle tier."
Can beans survive?
Some of EJB's perceived weaknesses could, in the long run, turn into strengths. "As with any 1.0 spec,
it is still 1.0," said IBM's Woodard. "There is room for tightening things, such as container interfaces,
to make sure components deploy across different vendors' containers."
Many say they would ultimately like to see Sun turn Java and its related specifications over to a neutral governing
body such as the OMG or International Standards Organization (ISO). "[Drafting specifications] is mostly a
technical process either way, but there are benefits to having a real, mutual standards body," said Adrian
Bowles, president of Alt Research, Westport, Conn.
The key for the ever-hurried development market looking to use EJB technology is patience. Bowles believes it
will be 12 months before mainstream developers must look at EJBs seriously. But he would recommend to his clients
that EJBs should be part of any major component strategy. "A future look at any application life cycle that
includes integration with commercialized components shows EJB is a real hope for a commercial component market,"
Looking ahead, there are a couple of things to watch for that should make EJBs more robust and accepted: first,
in a presentation given at JavaOne, Sun's Roth alluded to a certification program for EJBs; second, a bridge to
the COM/DCOM world of Microsoft has been discussed. In the first case, certification would be a step forward. It
would give some assurance to developers looking to integrate third-party beans into their own application. In the
second instance, a bridge to Microsoft technology would be useful, as COM/DCOM is a platform that cannot be ignored.
"Whether it comes from us or our partners," said Sun's Achanta, "there will be a bridge to MTS."