J2EE Puts Java To Work

Like the standard edition of Java 2, J2EE comes with the Java Development Kit (JDK) 1.2, the core language. On top of that are nine components:

Enterprise JavaBeans 1.1: This latest iteration breaks compatibility with predecessor EJB 1.0, to the annoyance of some, but that’s because of the gains that come with it. EJB 1.1 gains XML as the deployment descriptor, improved assembly and deployment, an enhanced security API, mandatory entity beans for persistence, and a number of performance enhancements.

Corba: This predecessor of EJB is the open standard for heterogeneous distributed computing. J2EE offers support for Corba through Remote Method Invocation (RMI) over Internet Inter-ORB Protocol (IIOP), which lets Corba objects talk to Java objects over the network, a Java Interface Definition Language (IDL), which lets Java objects communicate with Corba objects on the same machine, and Java Transaction Service (JTS), a Java implementation of the Corba Object Transaction Service (OTS).

JavaServer Pages: Sun’s answer to Microsoft’s Active Server Pages (ASP). JSP technology allows Web developers and designers to develop Java-drive dynamic Web pages, the same way ASP pages are generated by Windows NT Server to present dynamically-generated data. JSP uses XML-like tags and scriptlets written in Java to generate the content for the page.

Java Servlet: The Java Servlet API provides Web developers with a consistent mechanism for building server-side applets and applications, without requiring an interface or GUI. Servlets use all Java APIs, including the JDBC API.

Java Naming and Directory Interface 1.2: JNDI 1.2 is a standard, unified interface to multiple naming and directory services in the enterprise. It allows Java applications to connect to directory-enabled applications. New to JNDI 1.2 is support for event notification and LDAP v3 extensions and connects to naming and directory services from BEA, Netscape, Novell, SCO, and Sun.

Java Database Connectivity 2.0: The standard Java interface to industry standard databases. New in JDBC 2.0 are performance enhancements and new methods that allow a programmer to fine-tune the retrieval of rows from the database, support for using advanced data types and new SQL3 data types, new SQL locators, and support for storing Java objects in the database.

Java Message Service: An API supporting asynchronous enterprise messaging services, such as reliable queuing, publish and subscribe communication, and various aspects of push/pull technologies.

Java Mail: An API for setting up e-mail services in Java.

Java XML support: Used across the board. EJB uses XML for synchronous data messaging, while JSP technology generates XML pages and JMS uses XML for asynchronous data messaging.

Does the term code bloat come to mind? Sun doesn’t think so. "To do mainframe-level high availability, fault-tolerant stuff, you need a lot of services," says Bill Roth, product line manager for J2EE at Sun’s software division, in Cupertino, Calif. "This is a platform to run a stock market on."

In addition to the tools, you get blueprints with sample code for how to build applications and a compatibility test suite with 8,000 tests. The test kit covers not only API compliance tests, but also that a servlet talks to an EJB in a uniform fashion. With the kit, you can test a distributed application from client to server and ensure that it all conforms to the specification and works properly over the wire.

‘High comfort level’ with EJB 1.1 J2EE is positioned as the platform for delivering services under the network economy, which is why there are so many networking and messaging APIs and services. "It’s no longer about delivering data from servers to clients," says Roth, "but about delivering content from data stores to a whole range of devices."

EJB 1.1 is now the central technology, not the JDK, Roth adds. "J2EE is extending the reach of EJB," he says. "It’s what we had to do to make EJB successful, to specify the wire protocol, how data shows up on the Web, and how it needs to talk to message-oriented middleware and naming infrastructures."

Vendors expect EJB to be a major technology for Internet development. "EJB is going to be the most important technology in about six months," says Roseanna Marchetti, marketing manager for the Sun-Netscape Alliance’s iPlanet group of application servers and tools, created from the server business of the former Netscape Communications. "EJB will give companies a high comfort level with Java and objects on the server."

Many vendors seem to approve of the break from EJB 1.0. "What we saw very quickly was that the ability to deploy on EJB 1.0 was a pipe dream," says Blake Stone, chief scientist at Inprise, in Scotts Valley, Calif. "It varied wildly from implementation to implementation. The XML-based deployment descriptor is much more rich than the 1.0 equivalent."

"There were some things Sun did where you couldn’t maintain platform compatibility," adds Christopher Keene, CEO of Persistence Software, which worked with Sun on the EJB specification. "XML lets you customize deployments on the fly by changing the code with any editor. You needed special editors to edit the deployment descriptors in 1.0."

Vendors say EJB’s acceptance will come from 1.1 being far more transportable and platform independent, which is what Java promised all along. "EJB 1.1 offers more hope for transportability and interoperability and portability between different servers," says Bob Bickel, senior VP of development for Bluestone Software, which makes Sapphire/Web, an application layer for Web servers used to build e-commerce applications. "If I create an EJB in WebLogic’s server, there’s a pretty good chance that EJB will run on Bluestone’s, Silverstream Software’s, or IBM’s EJB servers, whereas the 1.0 spec would not do that. Persistence is a whole lot more solid in 1.1 than 1.0. There will be a lot more commonality in servers."

In some instances, some hard feelings may emerge over the incompatibility between EJB 1.0 and 1.1, says Bickel. "If you have an EJB 1.0 app, you have to convert every one of your Beans, take your entire server down, and redeploy all of those Beans," he says. "Think about what that means. I’m not taking down Beans on one machine, I’m taking down multiple machines. That could mean taking 100 machines down. What do I do during that period of time?"

Support for EJB will come when application server vendors rev their products, Bickel says. That is happening quickly. The Sun-Netscape Alliance had planned to have the iPlanet Application Server 6.0 fully J2EE compliant and ready for full certification by late December.

Database giants Oracle, Sybase, and Informix had all planned to support J2EE in their Internet and distributed database products by year’s end. The tools vendors are also quickly getting on the J2EE bandwagon. Rogue Wave will support J2EE in its Studio.J tool suite. Bluestone announced complete support across its entire product line, and Inprise plans to support J2EE in both its tools (JBuilder) and application servers.

Not only had SilverStream planned to support J2EE by year’s end with its SilverStream Application Server, but the company recently acquired GemLogic, a provider of XML-based business-to-business commerce solutions, and ObjectEra, the developer of a J2EE-compliant object request broker of the same name.

Fewer hassles with XML XML is used throughout J2EE as the unified messaging system. It eliminates most of the communications hassles encountered in Corba, DCE, or even EDI. "The failure of EDI was that far too much effort was expended solving the same problem over and over," says Stone. "XML solves the common stuff and lets you focus on the business logic."

EDI did not have very good data description or error handling, Stone says. Its method for transferring data was store-and-forward, not asynchronous, real-time communication. XML, on the other hand, is a standard method that uses HTTP to encode data, send, and decode it on the other end in real time.

One company looking into J2EE for transaction processing is PayMyBills.com, an online payment service for consumers. While business-to-consumer on the front-end, it’s business-to-business on the back end. EDI just doesn’t cut it, the company says. "EDI is just a store-and-forward standard," says Bob Whyte, CTO of PayMyBills.com, in Long Beach, Calif. "It doesn’t support real-time transfer, it’s featureless, and not very data-rich."

PayMyBills.com is working with a pre-release version of iPlanet Application Server 6.0, and is finding financial companies and banks are all interested in J2EE as an alternative to EDI. "Everyone’s been grappling for a standard to wrap their arms around, and it appears J2EE is getting widespread adoption," Whyte says. "When we approach these financial companies and say we’re using J2EE, their eyes light up and they say, ‘You’re doing that, too?’ This will be leaps-and-bounds over what exists today in terms of business-to-business standards."

JSP: a sleeper technology Aside from EJB, J2EE has a technology that’s been somewhat overlooked, but that some developers think will make a big difference: JavaServer Pages.

For developers that go the Microsoft route, it’s relatively easy to dynamically generate Web pages from a database with Microsoft’s ASP technology. If you don’t want to go with Microsoft, for whatever reason, your alternative is an equally proprietary solution, such as Allaire’s Cold Fusion.

JSP will handle the client role, since EJBs don’t draw a Web page, they perform the back-end functions. "More people will use J2EE for JavaServer Pages," says Bickel. "If you think about it, people are most familiar with HTML. JSP is simple and elegant, the masses can use it, and it will be very widely used-much more than EJB, simply because people understand tagging better than how to write Java."

Other vendors agree. "It’s an important part of the puzzle, because it gives you a natural way of integrating the services layer with the presentation layer," says Persistence’s Keene.

JSP will really take off when the Apache Group releases Jakarta, a derivative of the Apache server with native JSP support, predicts Inprise’s Stone. "That’s going to be the key to getting JSP out into major websites," he says. "Big e-commerce sites will use JSP to serve specific issues, but use in volume issues will happen when it becomes a part of Apache."

J2EE in its entirety is everything Microsoft offers as well-a language, messaging, transactions, scripting, database connectivity, and so forth. But Microsoft’s solution is all-in-one with Windows NT Server, while J2EE comes on multiple platforms, NT included. With the two products on an equal keel technologically, the cross-platform option is J2EE’s main strength and what Sun and developers all agree make it a more viable option.

"It’s being layered on the fastest enterprise products out there, where straight COM has scalability problems," says Roth, adding that Microsoft has only one transaction model and one business object model-MTS-whereas J2EE has a choice of transaction and business object models.

Where COM+ is tied to Microsoft’s own transaction and messaging technologies, EJB sits as a layer atop a variety of ORBs, TP monitors, and message-oriented middleware brokers, so the developer just writes Java code, rather than ORB-specific code. "You don’t care about the ORB anymore," says Roth. "The ORB is a required protocol, like TCP/IP. Corba is as important as TCP/IP and just as boring. We did EJB because writing Corba is hard."

Where shortcomings exist Although it covers a lot of territory, J2EE has its shortcomings, which may end up being handled independently by vendors or end-users. Some of these shortcomings are very specific to a particular use or market, while others will matter to developers of all kinds of applications. The shortcomings are apparent several areas:

Connectors: The Java Message Service API is at this point optional. JMS, which communicates with message-oriented middleware, is done but not required because Sun couldn’t get an agreement from partners on a reference implementation, according to Roth. It will be in the next major release of J2EE.

Security: Microsoft is trumpeting single sign-on in Windows 2000, but that’s something J2EE doesn’t offer yet. Sun is seriously considering adding a security API called the Java Authentication and Authorization Service (JAAS) for the next release.

Distributed Transactions: Because JTS is brand new, it’s not fully implemented across back-end systems, and Sun’s reference implementation in J2EE is not capable for a production system. So JTS simply needs time to grow.

EJB: There are still some issues in EJB that need to be fixed, such as communication with remote machines. Java 2 supports RMI over IIOP, which should allow one Bean to call another using Corba’s IIOP protocol, but Bickel says it doesn’t work well through firewalls. Also, there are still compatibility issues between EJB servers, so direct communication between the two, even if it works over IIOP and the firewall, is not guaranteed. The more loosely coupled solution is to put a message in XML message format and transmit it via a standard secure protocol such as MQSeries or HTTPS, he says.

Another shortcoming in EJB, which is being worked on, is that the EJB container needs to be smaller and more portable, so it can be moved across any and all platforms with no modification, says Keene.

But developers seem satisfied with what Sun has produced. "We believe it’s pretty complete," says Marchetti. "We believe you can build incredibly successful large-scale apps with it."

Andy Patrizio regards Java 2 Enterprise Edition as the best realization of Sun Microsystems’ programming language. Patrizio can be reached at andyp@mediaone.net.

© 1999 FAWCETTE TECHNICAL PUBLICATIONS, all rights reserved.