Java Web services: What’s not to like?

The overarching message at this year’s JavaOne conference is that the train has arrived at the (Java) platform. As of version 1.4, you can go just about anywhere you want. Whether you’re developing an architecture for a two-tier (client/server), three-tier (client/Web server/app server), or even a four-tier solution (client/client cache/Web server/app server), the Java platform makes it possible to develop a scalable, high-performance solution. You could always plug in a non-Java solution at any point in the architecture. But why would you want to?

Of course, you still have to work around the bugs. That’s life in the big city. No implementation is ever perfect; the most you can ask is that the APIs are complete enough to do what you need to do and that, when you’ve worked around the last bug, the app meets its performance requirements. The good news is that Java delivers in those two important respects.

Basically, the message here is that pretty much anything you needto do, you can do. That fact could help explain why, as Sun Vice President Richard Green mentioned in his keynote address, the curves representing the numbers of Java and Visual Basic developers have now crossed. It used to be that 70 percent of developers used Visual Basic and 30 to 40 percent used Java. Those numbers have turned around; now 70 percent use Java and 30 to 40 percent use Visual Basic. Those are impressive numbers, but when you’re talking about a well-designed, object-oriented language that happens to be free, what’s not to like?

The Java platform provides a top-to-bottom, end-to-end solution for a Web services architecture. From the client end to the server end, from rich clients at the top of the heap to the smallest clients in the world, Java libraries can simplify the development process. Sun has introduced new and improved APIs designed for developing Web services. Let’s take a look at them.

End-to-end solutions

The table below summarizes the APIs overviewed by Sun Distinguished Engineers Graham Hamilton and Tim Lindholm in Tuesday’s technical keynote address.

The client capabilities include a number of APIs. Which one you use depends on the kind of client you develop for. We’ll take a look at those in the section Top-to-bottom solutions.

For client-side servers that cache Webpages and application data for faster access, typically on a local network, communications and performance are the essential capabilities. The Java APIs for XML (JAX) in the JAX Pack provide XML-based mechanisms for communications. For the all-important performance capabilities in a caching system, the new I/O APIs (java.nio) discussed later in this article have a major impact.

As they are for the cache tier, performance and scalability are paramount for all the server-side layers, so the APIs discussed in The performance picture should interest you. But the functionality provided by the APIs is also essential. Those APIs will soon be collected into a “one-stop shopping” API bundle named the Web Service Pack, which will include:

Tomcat

You can download one bundle and have everything you need in one place to get your initial implementation up and running.

JavaServer Pages (JSP)

In addition to including filters, the new JSP 1.2 APIs can be written in all-XML format. The API will still support the original JSP tags (<%@ ... %>), but you can now use pure XML tags with namespaces as well (<jsp:page> ... </jsp:page>). The use of XML tags will make it possible to validate the JSP pages, generate them from other sources, transform them with Extensible Stylesheet Language Transformation (XSLT), and author them using standard XML editors.

JavaServer Faces

When you need a truly rich client, you can use Swing to create a Java application and Java Web Start to deploy it. But what about when you need to interact with an ordinary browser? The JavaServer Faces API (aka Moonwalk) promises to provide an elegant solution for implementing interactive functionality on incompatible browsers. That API, too, is discussed later in this article.

JAX Pack

The collection of Java APIs for XML, the JAX Pack, supports the standard APIs for Web services:

• XML:Everyone’s favorite language-defining mechanism.
• Simple Object Access Protocol (SOAP):An XML-based protocol for interacting with objects on remote systems.
• XML protocol (XMLP):The W3C specification for interacting with remote objects, based on XML. This work in progress is expected to be based on SOAP.
• Web services definition language (WSDL):An XML-based language for specifying the services offered by remote servers. WSDL specifications are in turn compiled into communications objects for various platforms in much the same way that CORBA IDL specifications are used.
• Universal description, discovery, and integration (UDDI):A registry mechanism that catalogs the services available from various suppliers along with their specifications. Prospective users/customers then find and download the specs, create their communications objects, and build apps that take advantage of the services.

The Web Service Pack APIs also support more sophisticated APIs that Sun hopes will become standard. One example is ebXML, which provides more powerful mechanisms for component sharing via registries, among other capabilities.

The JAX Pack itself consists of a series of APIs:

• Java APIs for XML Parsing (JAXP):Covers the standard Simple API for XML (SAX), Document Object Model (DOM), and XSLT.
• Java API for XML Binding (JAXB):A mechanism for compiling XML data type definitions into Java classes capable of reading XML into Java objects and writing them back out again.
• Java API for XML-based Messaging (JAXM):A SOAP-based protocol for sending messages.
• Java API for XML Registries (JAXR):An umbrella specification that provides a unified interface for UDDI and ebXML registries and conceivably other registries as well.
• Java API for XML-based Remote Process Communication (JAX-RPC):A SOAP-based protocol for requesting operations on remote servers.

In addition to the standard JAX Pack, a couple of additional XML technologies are potentially useful to the application developer:

• XSLT compiler (XSLTC):A tool for compiling XSLT transformations into Java bytecode — transformation objects, or translets, are optimized for high speed translations of XML data into the desired output format.
• JDOM (Java-based DOM):A truly object-based object model that makes it easy to create and manipulate a structured tree of objects. JDOM allows reading and writing in XML.

With the Web server tier handling communications to the client side, the remaining server-side layer is the application server tier. That layer allows business logic modules encoded as Enterprise JavaBeans (EJBs) to be reused among applications. More to the point, it provides a single point of control for updates, which eliminates a major headache when it comes to upgrading applications.

The upcoming version of the Java 2 Platform, Enterprise Edition (J2EE 1.3, due in the fall of 2001), will support EJB 2.0 and JAXP, along with the Java Message Service (JMS) API, which includes facilities for both point-to-point and publish/subscribe communications.

Top-to-bottom solutions

There is a broad array of potential Java clients, ranging from desktop systems capable of running sophisticated GUI apps down to tiny smart cards. The Java platform’s new and improved APIs give you the tools you need to get your job done.

Of course, there is a range of systems on the server side too, but here the difference is more a matter of degree than of kind. On the server side, the primary consideration is scalability — the ability to make an app handle more and more traffic on larger and more complex constellations of systems.

I discuss scalability questions in the next section, which covers the latest performance optimizations of the platform. In the remainder of this section, I will look at the APIs that are available for the different kinds of clients.

Desktop applications

As always, you can use Swing GUI objects and Java’s built-in networking protocols to create a sophisticated frontend for an application. But the major stumbling block has always been deployment.The app had to be packaged and installed on the user’s system, and the JVM had to be installed as well. In addition, it was a nightmare trying to get all users upgraded at once so you could install a new server. The only alternative was to simultaneously support both old and new versions of the client (shudder).

Applets were one solution, but they lacked important functionality. Besides, they took a long time to download, especially those that were anything more than trivial applications. With an applet, you didn’t have to worry about updating the client system, but that wasn’t enough of an advantage to make it a compelling solution.

Enter Java Web Start. This elegant solution handles downloading and installs the correct version of the JVM so the user doesn’t have to. It also stores the application locally, so it only has to be downloaded once. Since the installation is also automatic and a click in a Web browser launches the initial run of the app, it is easier on the user than practically any other installation mechanism. The downloaded apps can run offline as well.

If all this were the sum total of Java Web Start’s features, it would more than justify its existence; but there’s still more. Java Web Start provides for secure file reads, file writes, and printing, by ensuring that these actions only take place through a user-controlled dialog. In essence, you get the ease of applet deployment coupled with the functional capability of an application.

In addition, the system automatically downloads application updates, so the server doesn’t have to worry about out-of-date clients. For large applications, it is even possible to create incremental updates. In short, it is now possible to create both a powerful and easily deployed frontend for a sophisticated application.

Browsers

The new XML format for JSP pages will help make more sophisticated JSP-based applications possible, but even more important will be the increased functionality offered by JavaServer Faces.

Designed by a team led by Amy Fowler, Sun’s AWT and Swing architect, the JavaServer Faces API will provide a collection of GUI tools that will run on common browsers using standard HTML. You’ll be able to create the most interactive, functional pages that HTML can support.

Most importantly, the Faces API will hide browser differences. Incompatibilities and differences in functionality between browsers and browser versions have long plagued the Web developer. But the JavaServer Faces API will take care of generating the HTML that any particular browser understands so you can ignore browser differences and focus on the functionality the app needs to provide.

JavaServer Faces stands to replicate the success of the Java platform — not in being a platform-neutral API (i.e., a lowest common denominator implementation), but in being a platform-spanning API — one that provides the greatest possible functionality that can be implemented across all platforms, even if necessity dictates that such functionality be implemented differently on each platform

Mobile devices

Given that telecommunication companies now look to independent software vendors for their systems, the time has never been better to develop applications for mobile devices. You can use the Mobile Information Device Protocol (MIDP), part of the Java 2 Platform, Micro Edition (J2ME), for that task. Unlike the Java 2 Platform, Standard Edition (J2SE), which continues to grow in size and functionality, J2ME remains a stripped-down, minimal platform suitable for small clients.

Wired devices

For wired/embedded devices that need to connect to the Web, Personal Java fills the bill. For those that don’t, the Foundation Profile in J2ME provides the required functionality.

Smart cards

Finally, there are the Java Card APIs, used in approximately 90 percent of all smart card applications. Smart cards can carry data, which makes them ideal as phone cards and the like, where the convenience factor is high and the risk is small in the event of loss.

The performance picture

Given that the APIs offer you the capability to create the programs with the functionality you need, the next question is: How will those programs perform? Or, to be more exact, how quickly will you be able to make them perform once you identify the bottlenecks and start optimizing?

Performance has always been the Achilles’ heel of interpreted languages — even those that precompile their bytecode, like Java. And since many applications live and die by their performance characteristics, this is no small issue.

The platform gained major improvement in performance with the HotSpot Virtual Machine — the dynamically optimized runtime engine that is able, at times, to exceed the performance of an optimizing compiler. (Note: Since HotSpot optimizes at runtime, it can take advantage of runtime information that even the best optimizing compiler does not have. For example, if a loop variable dictates that the number of iterations will be small, HotSpot can unwind the loop.)

But with CPU performance optimized, the major bottleneck became the I/O subsystem. The new I/O package, java.nio, addresses that bottleneck.

As a result of efforts led by Sun Senior Staff Engineer Mark Reinhold, the new I/O package available in JDK 1.4 provides several major improvements in I/O performance and functionality:

Memory-mapped I/O

Graphic cards and other high-speed devices need direct memory access so no time is wasted copying data between buffers. Previously, Java’s virtual machine was isolated from such optimizations, but the new I/O package provides that capability.

A demo shown during Green’s keynote Monday morning simulated a plane flying over the Grand Canyon. Using 300 MB of LandSat data and the old I/O package, the plane lurched forward for a few feet, paused in mid-air, waited for a second, and then lurched forward again. Realtime it was not. When the demo shifted to use the memory-mapped I/O in the new I/O package, eliminating the copies from the graphics buffer, the balky, halting bursts of movement magically turned into a smooth flight. It wasn’t a jet-engine fighter plane, mind you, but more of a prop-engine Cessna. Still, it smoothly banked and glided over the landscape in an impressive simulation of the real thing.

Nonblocking I/O

The lack of nonblocking I/O has proved to be a major sore point for server-side performance. With nonblocking I/O, the platform looks to see if any data can be read or written and, if not, the program moves on. With blocking I/O, by contrast, the thread is forced to sit and wait for data to appear before the program can proceed. This produces nightmares for multiclient server applications. It means you must dedicate a thread for each user, which quickly consumes memory and adds runtime overhead.

With nonblocking I/O, a single thread can handle I/O from thousands of clients. That makes it possible to write scalable applications that can handle large volumes of data.

Interruptible I/O

For realtime applications, the ability to safely and quickly interrupt an I/O operation is paramount — and you’ve got to know how much of the interrupted I/O operation has been completed so you can restart it at the right point later. The new I/O package addresses both of these issues. When a gamer presses a key, for example, or when another factory unit arrives on a conveyor belt, the program may need to stop what it is doing and devote its attention to the new input. Interruptible I/O makes it possible to write programs that do just that.

File transfers

Finally, the new I/O package provides high-performance bulk data operations for files. For example, Reinhold’s tests showed that the transfer operation can drive in a file copy that is almost twice as fast (1.96 times, to be precise) as it would have been under the old I/O package. This level of performance is close to that provided by a native compiler, which delivered a speed increase of a factor of just over two (2.16). (Given that version 1.4 is still in beta, Reinhold feels sure that performance will be even closer to native speed before the package ships.)

Each of these improvements in I/O capabilities opens up new vistas of opportunity for the Java platform, allowing it go where it has never (successfully) gone before.

Summary

The new APIs released by Sun provide a top-to-bottom, end-to-end solution for a Web services architecture. I return to the question posed in the beginning of my article: “You could always plug in a non-Java solution at any point in the architecture. But why would you want to?” The increased functionality and improved performance provided by the APIs discussed here should adequately answer that question for you.

Source: www.infoworld.com