In-Depth

EJB components: Distributed object containers this way come

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

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

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

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

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

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

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

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.

Most   Popular