Newsletter sign-up

View all newsletters

Sign up for our Enterprise Java Newsletter

Enterprise Java

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

By Bryan Morgan, JavaWorld.com, 06/01/98

While 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). From an application development standpoint, the developer does not choose to use the Oracle8 server based solely on the DBMS's characteristics. Instead, the overall Network Computing Architecture must be evaluated against another vendor's architecture (Microsoft's Transaction Server/SQL Server combo, for example) based on a very large number of tradeoffs.

 

About Us | Advertise | Contact Us | Terms of Service/Privacy

Copyright, 2006-2008 Network World, Inc. All rights reserved.