JavaWorld: Enterprise JavaBeans: Coming soon to a server near you

[kentw@bhssf.org (Kent Wreder)]

Title: Enterprise JavaBeans: Coming soon to a server near you - JavaWorld - June 1998

This article was mailed to you by a JavaWorld reader.

Their message: re our discussion yesterday. Kent.

---

June 1998

Get FREE JW e-mail alerts

Enterprise JavaBeans: Coming soon to a server near you

Get a first look at this new component architecture, which promises to revolutionize server-based component development

Summary
The Java platform for the enterprise currently includes a group of eight technologies that are of key importance to developers of enterprise-class applications. Among the most eagerly awaited of these technologies is Enterprise JavaBeans (EJB). The EJB component architecture promises to provide an architecture for building cross-platform, distributed server components that are capable of seamlessly performing distributed transactions. This month, we will focus on the EJB specification -- what it is and what it means to the distributed object developer. (2,900 words)

By Bryan Morgan

Mail this
article to
a friend

hile we're all familiar with the Java platform in its various incarnations (1.0, 1.1, and the upcoming 1.2 release), what you may not realize is that Sun also has defined a server-based platform for enterprise-capable Java computing. The Java platform for the enterprise currently consists of eight components designed for "medium-to-large scale business, enterprise-wide systems, multi-tier environment, distributed data sources, and serious users of middleware applications" (to quote Sun's marketing information). This platform is of great importance to the distributed objects developer because pieces of this platform rely on distributed computing architectures such as CORBA, RMI, and sometimes both.

Each technology in the enterprise platform is at a varying stage of development; some of the pieces are probably already familiar to you (RMI and JDBC), while others (like JavaIDL) are just about ready for prime time.

In addition to these three popular APIs, the Java Naming and Directory Interface (JNDI), also a piece of the enterprise platform, is shipping. JNDI is intended to give Java developers the tools required to access naming and directory services for enterprise-class applications.

The four technologies above are available now and JDBC 2.0 (a major revision to the original standard) is on the way (see Resources for JavaWorld coverage of these various APIs.). Meanwhile, the four remaining pieces are:

• Enterprise JavaBeans (EJB)
• Java Management API (JMAPI)
• Java Message Services (JMS)
• Java Transaction Service (JTS)

All of these APIs (see Resources) warrant standalone discussions; this month, however, we will focus on the technology that will undoubtedly play the largest role in your enterprise application development efforts in the near future -- Enterprise JavaBeans.

What does EJB have to do with distributed objects?
You may be wondering why you, the distributed object guru in your organization, should take the time to begin learning of future changes to the Java APIs. I can think of a number of reasons, which is partially why I'm focusing on EJB this month. The first reason is that distributed, multitier development is fully interwoven into Sun's Java server development platform. While the details may or may not be hidden from you, developing an application using the Java Transaction Service, for instance, means that you will be using a fully compliant mapping of the OMG Object Transaction Service, or OTS as it is commonly referred to. In addition, a portion of the EJB specification deals with standardizing the mapping between the EJB architecture and CORBA. While it will be possible to communicate with an Enterprise JavaBean using RMI (the default protocol), it will also be perfectly valid to use CORBA as the glue between your client applications and Enterprise JavaBeans located on a server.

The second excellent reason to pay attention to the enterprise platform is that there will finally be a standardized way to write distributed, transaction-oriented systems that do not lock you into one vendor's proprietary toolset. As a purely random example, let's take a moment to consider the methodology for building a distributed application using Oracle Corporation's Network Computing Architecture (see Resources). While Oracle provides support for developing server "cartridges" in Java that use CORBA as a communications bus, individual transaction management and data access APIs are Oracle-specific and are therefore not portable (should you need to port your application to Sybase SQL Server, for instance).