In-Depth

J2EE on the March

The new features of J2EE have one thing in common: They are designed to bring commonality to the different application servers.

• By Andy Patrizio
• 06/01/2001

These new features, such as improvements to Enterprise JavaBeans (EJBs) and new eXtensible Markup Language (XML) APIs, are available on many J2EE application servers now, but they are unique implementations to each platform and incompatible from one server to the next. These new APIs and features bring cross-platform commonality.

"We are definitely bringing portability not only to the application server market, but to the whole middleware market," says Ralph Galantine, product line manager for J2EE at Sun. "A few years ago, this market was a whole collection of initials and acronyms like CORBA, MOM, data access middleware, CSCS and transaction processing monitors."

"The basic message we're delivering is [that J2EE] continues to improve on interoperability and portability of apps between the different platforms," says Bob Bickel, senior vice president of development for Bluestone Software.

"Part of what standards are about is standardized interfaces for customers," he says. "J2EE doesn't define all of the features. People have problems where they try to do XML messaging today, and the XML spec isn't there, so vendors like ourselves, do our own processing. When J2EE comes out, we'll move over to those standards."

A notable straggler is Oracle, which is working on a server that passes the 6,000 compatibility tests, according to Sun. As for Microsoft, forget it. Any attempt at Java support by Microsoft ended in flurry of lawsuits.

J2EE has nine components, most of them developed individually over the past few years. In late 1999, Sun finally wised up and did two things; packaged all of these pieces together and began the process of integrating them and putting them on a concurrent development cycle, rather than releasing each piece individually. There was a time when Sun had products on a near-weekly release cycle, which drove developers crazy.

With the update to J2EE, first released in early 2000, Sun is updating key features in the platform for better performance in enterprise-scale applications, particularly distributed applications that run on multiple machines. By beefing up EJBs, deeper integration of XML, connectors to ERP applications and new messaging features offer a solid foundation for Web-based services.

In the past year, Sun has certified a dozen application server vendors as J2EE-compliant. These vendors—AT&T, BEA Systems, Hitachi, iPlanet, Sybase, Iona Technologies, Silverstream Software, Inprise, Bluestone Software, IBM, Fujitsu and Talarian—make up 90 percent of the application server market. As a result, Sun says J2EE-based application servers have become a standard application platform, replacing proprietary application platforms systems.

EJB 2.0
EJBs get a major facelift in J2EE 1.3, with the EJB 2.0 spec. Interoperability through the CORBA messaging protocol, Internet Inter-Orb Protocol (IIOP) and using the Java Message Service (JMS) are now mandatory in deploying EJB 2.0 applications.

The IIOP requirement will allow beans on different servers to communicate directly. Previously, an EJB on one server could not talk directly to an EJB on another server; it had to go to a bean or an application running on a client, and then back to that second server.

The reason for this is because only client-side beans had IIOP support, not server-side EJBs. Direct communication without the middleman will mean increased performance since the middleman, or in this case middle client, is knocked out.

The Java Message Service API remains essentially the same in J2EE 1.3 as it did in J2EE 1.2, only now it's a requirement for EJB programming, because messaging queuing is required to build asynchronous enterprise messaging services, such as reliable queuing, publish and subscribe communication and various aspects of push/pull technologies.

Asynchronous communication is a sort of fire-and-forget way of interoperating between applications. In a synchronous application, such as a database query, the client application is locked until it gets back the results of its query. With asynchronous applications, a database query can be sent off and the client is freed up while it waits for the response.

"It's great that it's becoming part of the standard architecture," says Gerry Seidman, president of IAM Consulting, a Java development consultancy in New York City. The best analogy to asynchronous messaging is e-mail, he points out. The mail client sends out the mail and releases its connection with the SMTP/POP3 server, while it waits for new messages to arrive.

"It's easier to write scalable systems when you're asynchronous," says Seidman. "Things go from Phase A to Phase B to Phase C over a long period of time. It's not that you hit 'O.K.' and things happen. Some things queue down a line and you need messaging, especially in a disconnected world."

There is also a new type of EJB, a message-driven bean. A message-driven bean is a bean that runs on the server and is activated by a message. It has no state for a specific client, but a client accesses a message-driven bean by sending messages to the destination for which the message-driven bean is a message listener. This means the beans are not tied to any one client or any one server, but rather, it's a neutral bean that can be called by any client.

Seidman calls the EJB 1.1 spec "virtually useless, in that it's a productivity tool for writing servers, but in terms of the promise of persistence management, it's garbage." The problem with EJB 1.1 is that persistence was managed by the EJB, not the containers in which they reside. To do a database call meant writing SQL code manually for the database beans—and writing SQL code can be a nightmare.

It also made data management difficult. For example, a purchase order would have multiple entry lines, such as name, address, city, state, etc. In EJB 1.1, to delete a purchase order meant not just deleting the order entry but all of the individual lines for that entry.

Another major change to EJB 2.0 is improved container-managed persistence. This allows the data being processed by the EJB to be cached on the application server. In the previous versions, data was not kept on the application server, it went from the client to the database. This will mean improved performance due to less database access calls being required.

With container-managed persistence, instead of writing SQL code, you create your EJB-to-database connection with an interface tool that shows all of the field names in a bean on one side and all of the columns in the database on the other side. The developer simply points and clicks to draw connections between the bean fields and the database columns. The container handles all of the database connectivity, SQL code, JDBC calls, and when an item like a purchase order is deleted, all of its related data is removed in one fell swoop rather than line-by-line.

Improved XML Support
Java 2 Enterprise Edition gains three new APIs specifically for handling XML data, as well as an overhaul to the JavaServer Pages (JSP) [see Lou Marco's "Java Server Pages in a Nutshell"] API. JavaServer Pages is an extension of the Java Servlet technology, the server-side applications for Web servers to perform tasks, instead of a scripting language. JSP is Java's answer to Microsoft's Active Server Pages (ASP) in the creation of dynamic Web content.

The new JSP API will now support hooks for filtering data either coming into or going out of the JSP. This means filters can be written to transform data into the proper format for a client device. For example, a site can determine if the end user is on a PC, handheld device or Internet terminal, then apply an eXtensible Style Sheet Transformation (XSLT) to format the data for that client.

Orlando Caro, senior engineer for Encore Development, a custom application developer, is looking forward to the XSLT support. "Transformations are one of the most tedious pieces to do, and XSLT takes the tediousness out of it," he says. "Once you set it up, it's done. Personally, I do not like to do screens. Back-end developers in general do not like to do front-end development. This allows you to break apart the development of the app from the user interface."

Also coming are the three XML APIs—Java API for XML Parsing (JAXP), Java API for XML Data Binding (JAXB) and the Java API for XML Messaging (JAXM). JAXP is an XML parser, and the most important of the three APIs. JAXP is used to parse and transform the XML data between applications.

JAXM is used specifically for b-to-b exchanges by routing XML documents by messaging. The API will support reliable delivery of messages, a variety of data types, security of the data being sent and an audit trail. Up to now, Java had no standard API for exchanging XML messages over the Web, so application server vendors either provided their own, developers had to find a third-party product or they simply went without.

JAXB supports mapping of XML data between two Java apps. JAXP only handles the parsing of the data, while JAXB will handle the relationship between two applications. Data binding automatically maps the components of an XML document to in-memory objects, such as EJBs. This allows Java programs that manipulate XML content to be written at the same conceptual level as the content itself, rather than at the parser level.

JAXP is the only API that will ship with 1.3. JAXM and JAXB will be available by the end of the year and will work seamlessly with 1.3. Sun expects to ship all three APIs with J2EE 1.4, whenever it ships.

Connectors
The final new piece of the puzzle is the J2EE Connector Architecture. The connector architecture is a standard means for J2EE applications to connect to enterprise and legacy applications, such as Enterprise Resource Planning (ERP), mainframe transaction processing (TP) and database systems. This will allow Java applications to fetch and put data to and from SAP R/3 systems, DB2 databases or Oracle systems.

These adapters will support XML data transfers through JAXP, so all manner of XML data exchanges can be done. It will be possible for business partners to exchange data with a Java application server receiving the data, transforming it into XML and connecting to the company's enterprise systems, with no modification of the back-end systems required.

However, Sun won't be writing the connectors, the third-party ERP and mainframe developers are. Sun will simply provide the spec. It hasn't made a formal announcement of companies supporting the connectors, but expect the big names like SAP, Baan, PeopleSoft, Oracle and IBM to be on board.

Much of J2EE's other elements remain largely unchanged. The CORBA support is largely the same as it was in the 1.2 version, aside from the IIOP connectivity between two servers. JSP is unchanged, as is Java Naming and Directory Interface 1.2 (JNDI), the interface to multiple naming and directory services.

Java Database Connectivity 2.0 (JDBC), the standard interface to databases, remains the same, as is Java Mail, an API for setting up e-mail services in Java.

Java Web Star
An important development in the Java world that is not part of J2EE, but something to be considered for any major Java deployment, has to be Java Web Start (JWS). JWS allows for the deployment of client-side applications from a server. Previously, any Java applications either had to be manually installed on each individual client, or the client had to be downloaded every time the user restarted their machine. In either case, that's not very efficient.

JWS, through the underlying Java Network Launch Protocol (JNLP), allows Java applications to be set up for delivery on a server and the end user can install them simply by clicking on a hot link. JWS then downloads the application, all relevant Java Runtime code and installs it all on the end user's computer. Every time the application is run, it checks with the server for any code updates. If there are updates, it downloads the code and installs it automatically.

Each application runs in its own memory space and uses a specific version of the Java Runtime Environment (JRE), and multiple applications can run concurrently with no interference. So, if a new application is deployed that uses Java Runtime 1.3 while previous applications use 1.2, that application runs in its own memory space and the JRE 1.3 code never touches the other applications running JRE 1.2.

If this idea sounds familiar, it's what Microsoft is saying it wants to do with the .Net strategy. J2EE and .Net, when you peel back the technology particulars and look at them conceptually, are alot alike.

Java Web Start is the only product that uses JNLP, but Sun says it's seeing interest from Java licensees to use JNLP as a network transport mechanism for their products. The first was Sitraka Inc., formerly the KL Group, which licensed JNLP for its DeployDirector client software deployment software.

But as yet, J2EE is not committed to JWS because the 1.3 spec is frozen and nearing completion, according to Blake Connell, group product marketing manager for Java 2 Standard Edition, which does use JWS. JNLP could make its way into a dot-release of J2EE 1.3, however. "Administrators can automate the deployment process of an application with JNLP," he says. "JNLP sets up the server types Java is looking for and points users to a site to download and install the application. So, it automates the packaging side of application deployment."

J2EE 1.3 is under final review with Sun licensees and is expected to be released in the third quarter of this year.