New York University

Computer Science Department

Courant Institute of Mathematical Sciences

 

Enterprise JavaBeans FAQs

 

Course Title: Application Servers                                                                                    Course Number: g22.3033-011

Instructor: Jean-Claude Franchitti                                                                                     Session: 6

 

 

Enterprise JavaBeans facilitate component-based development on the middle tier.

ˇ        Tools and hosting platforms are available

ˇ        Everyone but Microsoft is behind Sun Microsystems

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

ˇ        The 'Enterprise JavaBean' name is confusing because it is not a component model in the sense that ActiveX and JavaBeans are"

ˇ        EJBs are middleware abstractions that manage persistence, security and reliability for server-side business logic

 

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

ˇ        JBuilder from Inprise Corp. (formerly Borland International Inc.), Scotts Valley, Calif.

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. Support is now available in the EJB 2.0 specification.

ˇ        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. It pushes the plumbing down, abstracts it away from the developer.

ˇ        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 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 beans 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. 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.

ˇ        EJBs make it possible to work on existing systems, such as layering on top of a CICS-based system to preserve an investment, but they also give the advantage of new applications.

ˇ        The advantage of EJB, 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

COM+ vs. EJBs

ˇ        The EJB specification is in direct competition with Microsoft's Distributed Component Object Model (COM+) 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 approved RMI over IIOP

ˇ        To the advantage of EJBs, COM+ only works with Microsoft Windows NT and Windows 95/98 operating systems. A COM object can only talk to another COM object. 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+ has been around the block, and there are a number of products and tools shipping that support the model. However, a lot of tools and server platforms are currently available support EJBs. In addition to the tools and servers, actual beans need to be built before they can be used.

The tool market

ˇ        Inprise was one of the first vendors to release an EJB-compliant tool with Borland JBuilder. The latest release from the renamed company contains wizard technology for building EJBs. They also have a good integration with their Corba product [VisiBroker].

ˇ        Sybase released ts PowerJ development environment which fully support the EJB specification. The current PowerJ release does support standard JavaBean development through the use of wizard technology. 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. Some vendors have also developed wizards 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 released Apptivity and Visual Café for Java, respectively, which support EJB development.

ˇ        Forté Software Inc., Oakland, Calif., also supports the EJB specification in its Forté Enterprise Application Environment.

ˇ        Sun's Java Studio and Java Modeler support EJBs. The latter allows the transport of Java classes into EJBs.

ˇ        EJB is also being integrated into IBM's VisualAge for Java product.

ˇ        WebLogic is one of the many vendors pledging support for EJB, and the firm has released an EJB-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. delivered 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. Sybase has tried to remain standards-neutral, as evident in its support for both the EJB/Corba standard and Microsoft COM+ standard.

ˇ        Sybase's two major competitors in the database world, Oracle Corp. and Informix Software Inc., are stepped into the fray with 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 .

ˇ        Informix developed a strategy to integrate and deploy Java and EJBs with its Informix Dynamic Server. Developers are able to invoke JavaBeans from within the database, while the server acts as a container for EJB deployment.

ˇ        Other vendors support EJB 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.; Novera Software Inc., Burlington, Mass.; and Art Technology Group, Boston.

ˇ        Given that the above-mentioned vendors are implementing the same specification, a major difference between each offering is quality of service