In-Depth

Sun's Java Studio on target

• By Jason J. Meserve
• June 26, 2001

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."

Inside Beans

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) crashes.

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 for release.

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:

1. Java Transaction Service (JTS) -- handles distributed, two-phase commits to databases and provides open access to multivendor transaction systems.
2. Java Management API (JMAPI) -- a set of Java classes and interfaces that allow developers to build system, network and service management applications.
3. Java Naming and Directory Interface (JNDI) -- just what the name implies. Allows applications to find EJBs and specific containers.
4. 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.
5. Java Messaging Service (JMS) -- a Java-based publish-and-subscribe middleware system.
6. 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 model."

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," Dietzen said.

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," said Bowles.

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."