by Michael Morrison
Up to this point, everything you've learned about Java has been entirely based on what is known as the core Java API, or the Java Base API, version 1.02. This core API currently comprises the entirety of the Java programming environment. JavaSoft recently announced a broad set of extensions to extend this core API in a variety of ways. Some of these extensions will eventually become part of Java 1.1, which is the next major release of Java. Until the official release of Java 1.1, these new extensions will be released individually as standard extensions to the current Java environment. In addition, some of the new extensions will remain as extensions even after the release of Java 1.1 simply because they address development areas that aren't central to the core Java API.
This chapter takes a look at all the new API extensions and what they have to offer you as a Java developer. Most of the API extensions are very new and haven't even reached the specification stage. For this reason, this chapter is meant to give you an idea of where Java is headed with the standard extension APIs. In other words, you may want to check JavaSoft's Web site (www.javasoft.com) to get the latest scoop on the status of these APIs because they are still in the development stage.
Java release 1.02, which is the latest Java release as of this writing, is now being referred to by JavaSoft as the core Java API. The core Java API defines the minimal set of functionality a Java implementation must support to be considered Java compliant. For example, when someone undertakes the job of supporting Java on a particular platform, that person must fully implement the core Java API. This guaranteed support for the core API is what allows Java developers the luxury of being able to write Java programs once and have them run on any Java-compliant platform.
In the near future, JavaSoft plans to expand on the core API by introducing new APIs that address more applied development needs. The new APIs cover a wide range of areas and will ultimately save developers a great deal of time by establishing a consistent approach to certain development issues, reducing the need for custom coding. Some of these new APIs will merge with the new core API (Java 1.1); others will remain extensions. Regardless of their ultimate relationship to the core API, the new extension APIs are referred to as the standard extension APIs because they extend the current core API as we know it.
The standard extension APIs are divided into a set of individual APIs that target different development needs. Following are the major components of the standard extension APIs:
The rest of this chapter explains each of these APIs and how each impacts the Java software platform.
Enterprise computing has become increasingly important in recent years as more and more companies realize the importance of integrating their operations electronically. The unique possibilities afforded by the increased usage of the Internet have only served to magnify the popularity of enterprise computing. JavaSoft took note of Java's lack of support for enterprise systems and announced plans for an Enterprise API.
The Java Enterprise API is designed to allow Java programs a formal mechanism for connecting to enterprise information systems. This is a much needed feature in Java because so many corporate computer systems rely heavily on enterprise information sources. In answering this need, the Enterprise API tackles the problem on three fronts. These fronts come in the form of three API subsets:
JavaSoft has recognized the importance of these three API subsets and plans to directly incorporate them into the core Java API at some point in the future.
The first of the subset APIs of the Enterprise API is Java Database Connectivity (JDBC). JDBC defines a structured interface to Structured Query Language (SQL) databases. SQL databases are databases built on the SQL standard, which is a widely accepted standard that defines a strict protocol for accessing and manipulating data. By supporting SQL, JDBC allows developers to interact with and support a wide range of databases. This means that the specifics of the underlying database platform are pretty much irrelevant when it comes to JDBC, which is very good news to Java developers.
The JDBC API provides Java developers with a consistent approach to accessing SQL databases that is comparable to existing database development techniques. Interacting with a SQL database using JDBC isn't all that much different than interacting with a SQL database using traditional database tools. This should give Java programmers who already have some database experience confidence that they can hit the ground running with JDBC. The JDBC API has already been widely endorsed by industry leaders, including some development tool vendors who have announced future support for JDBC in their development products.
The JDBC API includes classes for common SQL database constructs such as database connections, SQL statements, and result sets. A result set is a group of data retrieved from a database after a user request. JDBC programs will be able to use the familiar SQL programming model of issuing SQL statements and processing the resulting data. The JDBC API depends largely on a driver manager that supports multiple drivers connecting to different databases. JDBC database drivers can either be written entirely in Java or they can be implemented using native methods to bridge Java applications to existing database access libraries.
You can get the latest scoop on JDBC from JavaSoft's JDBC Web site, located at http://splash.javasoft.com/jdbc/.
The Interface Definition Language (IDL) subset of the Enterprise API is aimed at providing a way to connect Java client programs to network servers running on other platforms. IDL is an industry standard protocol for client/server communications across different platforms. The primary usage of the IDL API is to transparently connect Java client programs to legacy systems. A legacy system is an outdated system that has yet to be reimplemented using current technologies. Like it or not, there are still plenty of legacy systems in use that house a great deal of important information.
The Java IDL API includes the following components:
You can get the latest information on IDL from JavaSoft's IDL Web site, located at http://splash.javasoft.com/JavaIDL-alpha2.0/pages/.
The Remote Method Invocation (RMI) component of the Enterprise API defines an interface for invoking object methods in a distributed environment. The RMI API serves a crucial purpose in the Enterprise API by providing full support for remote object communications. The RMI API makes it straightforward for Java developers to add remote computing support to their classes. For the latest information on RMI, check out JavaSoft's RMI Web site, located at http://chatsubo.javasoft.com/current/rmi/.
As the role of the Internet continues to evolve from being an information source to being a retail marketplace, the need for a secure commercial transaction protocol is also growing. Both Internet vendors and shoppers alike are eagerly awaiting the inevitable migration of shopping to the Web. Beyond shopping, there are also other important areas of financial transactions (such as investment trading) that would benefit greatly from a secure standard. JavaSoft has provided an answer to the secure purchasing problem with the Commerce API, a Java API extension that provides the overhead for Java programs to support secure purchasing and financial management.
The Java Commerce API aims to provide developers with an elegant solution to the problem of commercial transactions on the Web. The goal is to make purchasing goods a seamless yet secure part of the Web experience. To this end, the Commerce API is being pushed by JavaSoft as an open, extensible environment for financial management on the Web. The long-term plan for the Commerce API is for integration into the Java software platform partially with the core API and partially as a standard extension. It isn't clear yet which components will make it into the core API and which will remain separate.
The Commerce API consists of the following primary components:
For more information on the Commerce API, check out JavaSoft's Commerce API Web site, located at http://www.javasoft.com/products/commerce/.
The Management API is designed to answer the needs of integrated network management systems. It includes a wide range of interfaces, classes, and applets to facilitate the development of integrated management solutions. The primary goal of the Management API is to provide a unified approach to handling the complexities involved in developing and maintaining resources and services on a heterogeneous network. Using the Management API, Java developers will be able to rapidly develop network management applications supporting a wide range of systems on large and often complex networks. JavaSoft plans to keep the Management API as a separate extension from the core API.
The Management API includes the following core components:
For more information on the Management API, refer to JavaSoft's Management API Web site, located at http://java.sun.com/products/JavaManagement/.
After the success of Java and its immediate use for developing client-side applets, JavaSoft decided to take steps to make Java a more viable alternative for server-side applications. The Server API is JavaSoft's answer to the need for more complete server-oriented support in Java. The Server API provides a wide range of server functionality including support for administration, accessibility control, and dynamic resource handling. Also included in the Server API is the Servlet API, which provides a framework for extending servers with servlets. A servlet is a Java object that extends the functionality of an information server, such as an HTTP server. You can think of servlets as the server equivalents of client-side Java applets.
The Servlet API provides the overhead necessary for creating servlets and interfacing them with information servers. The Servlet API is equipped to handle the entire servlet/server relationship, with an emphasis on keeping things stable and simple. All that is required to run servlets is a server that supports the Servlet API.
JavaSoft has grouped the Server and Servlet APIs under their new Internet server framework known as Jeeves. To get more information about the APIs, visit JavaSoft's Jeeves Web site, located at http://java.sun.com/products/jeeves/.
Possibly the weakest area of the core Java API as we know it is its support for media. Currently, the Java API supports only static GIF and JPEG images and wave sounds in the AU sound format. Clearly, this limited media support won't cut it in the long run. Sure, developers can hack their own media implementations to some extent, but they can already do that in a variety of other languages and platforms. Java was supposed to make things easier, right?
JavaSoft realized this weakness and is remedying things with the Media API, which is slated to include support for a dizzying array of media types that will no doubt put Java on the map as a serious multimedia platform. The Media API includes classes that model media types such as full-motion video, audio, 2D and 3D graphics, telephony, and more. Furthermore, the structure of the API is such that many of these media types will rely on the same underlying facilities. For example, all time-based media (such as video and audio) will use the same underlying timing mechanism, meaning that synchronization won't be a problem.
The Media API is designed to be very open and extensible-which is important considering that the world of multimedia is always changing. JavaSoft plans to integrate the Media API into the Java platform both as core API additions and as standard extension APIs.
The following API subsets comprise the Media API:
The eagerly awaited Security API will hopefully remedy one of the biggest limitations of Java applets: the inability to read or write files locally. With full support for cryptography, digital signatures, and authentication, Java developers should be able to leverage security issues to some extent and move away from the seemingly overprotective solution currently in place. Cryptography encompasses the algorithms and techniques used to render data unrecognizable in the hands of unauthorized parties, thereby enforcing information privacy. A digital signature is an electronic identification technique that serves much the same purpose as a handwritten signature. Authentication is the process of verifying an action based on a security check.
The cryptographic functions built into the Security API are isolated from the programmatic interface used by applets that want to make security decisions. This layering allows the cryptographic functions to be replaced by third-party alternatives without impacting anything at the applet level, thereby giving Java developers more options when it comes to their security needs. The Security API will eventually be incorporated directly into the core Java API.
For some time now, the software development community has been pushing the idea of re-usable components. In case you've missed the hype, a component is a reusable piece of software that can be easily assembled with other components to create applications with much greater development efficiency. This notion of reusing carefully packaged software was borrowed to some extent from the assembly-line approach that became so popular in America during the industrial revolution-well before the modern computer era. The idea as applied to software is to build small, reusable components once and then reuse them as much as possible, thereby streamlining the entire development process.
JavaSoft's Java Beans technology is a platform-independent component technology based entirely on the Java platform. The Java Beans technology promises to take the component software assembly paradigm to a new level. As of this writing, the Java Beans specification is close to completion with a preliminary API release expected soon after. Java Beans is being implemented as an architecture and platform-dependent API for creating and using dynamic Java software components. Java Beans picks up where other component technologies have left off, using the portable Java platform as the basis for providing a complete component software solution that is readily applicable to the online world.
Following the rapid success of the Java runtime system and programming language, JavaSoft realized the importance of developing a complete component technology solution. Their answer is the Java Beans technology, whose design goals can be summarized by the following list of requirements:
The first requirement of Java Beans (to be compact) is based on the fact that Java Beans components will often be used in distributed environments where entire components may be transferred across a low bandwidth Internet connection. Clearly, components must be as compact as possible to facilitate a reasonable transfer time. The second part of this goal relates to the ease in which the components are built and used. It's not such a stretch to imagine components that are easy to use, but creating a component architecture that makes it easy to build components is a different issue altogether. Existing attempts at component software have often been plagued by complex programming APIs that make it difficult for developers to create components without chronic headaches. So Java Beans components must be not only easy to use, but also easy to develop. For you and me, this is a critical requirement because it means fewer ulcers and more time to embellish components with frilly features.
Java Beans components are largely based on the class structure already in use with traditional Java applet programming, which is an enormous benefit to those of us heavily investing our time and energy in learning Java. JavaSoft has promised that Java applets designed around the AWT package will easily scale to new Java Beans components. This also has the positive side effect of making Java Beans components very compact because Java applets are already very efficient in terms of size.
The second major goal of Java Beans is to be fully portable. JavaSoft is in the process of finalizing a Java Beans API that defines the specific component framework for Java Beans components. The Java Beans API, coupled with the platform-independent Java system it is based on, will comprise the platform-independent component solution alluded to earlier. As a result, developers do not have to worry about including platform-specific libraries with their Java applets. The end result will be reusable components that unify the world of computing under one happy, peaceful umbrella. Okay, maybe that's asking a little too much-I'll settle for just being able to develop a component and have it run unmodified on any Java-supported system.
The existing Java architecture already offers a wide range of benefits easily applied to components. One of the more important, but rarely mentioned, features of Java is its built-in class discovery mechanism, which allows objects to interact with each other dynamically. This results in a system in which objects can be integrated with each other independently of their respective origins or development history. The class discovery mechanism is not just a neat feature of Java, it is a necessary requirement in any component architecture. It is fortunate for Java Beans that this functionality is already provided by Java at no additional cost. Other component architectures have had to implement messy registration mechanisms to achieve the same result.
Another example of Java Beans inheriting existing Java functionality is persistence, the ability for an object to store and retrieve its internal state. Persistence is handled automatically in Java Beans by simply using the serialization mechanism already present in Java. Alternatively, developers can create customized persistence solutions whenever necessary.
Although not a core element of the Java Beans architecture, support for distributed computing is a major issue with Java Beans. Because distributed computing requires relatively complex solutions attributed to the complex nature of distributed systems, Java Beans leverages the usage of external distributed approaches based on need. In other words, Java Beans allows developers to use distributed computing mechanisms whenever necessary but it doesn't overburden itself with core support for distributed computing. This may seem like the Java Beans architects are being lazy, but in fact, it is this very design approach that allows Java Beans components to be very compact because distributed computing solutions inevitably require much more overhead.
Java Beans component developers have the option of selecting the distributed computing approach that best fits their needs. JavaSoft provides a distributed computing solution in their Remote Method Invocation (RMI) technology, which is part of the Enterprise API, but Java Beans developers are in no way handcuffed to this solution. Other options include CORBA (Common Object Request Broker Architecture) and Microsoft's DCOM (Distributed Component Object Model), among others. The point is that distributed computing has been cleanly abstracted from Java Beans to keep things tight while still allowing developers who require distributed support a wide range of options.
The final design goal of Java Beans deals with design-time issues and how developers build applications using Java Beans components. The Java Beans architecture includes support for specifying design-time properties and editing mechanisms to better facilitate visual editing of Java Beans components. The result is that developers will be able to use visual tools to assemble and modify Java Beans components in a seamless fashion, much like existing PC visual tools work with components such as VBX or OCX controls. In this way, component developers specify the way in which the components are to be used and manipulated in a development environment. This feature alone will officially usher in the usage of professional visual editors and significantly boost the productivity of applications developers.
Many developers not completely familiar with the idea of software components will likely be confused by Java Beans's relationship to Java. Hasn't Java been touted as an object-oriented technology capable of serving up reusable objects? Yes and no. Yes, Java provides a means of building reusable objects, but there are few rules or standards governing how objects interact with each other. Java Beans builds on the existing design of Java by specifying a rich set of mechanisms for interaction between objects, along with common actions that most objects must support, such as persistence and event handling.
Although the current Java component model is not bad, it is relatively limited in regard to delivering true reusability and interoperability. At the object level, there is really no straightforward mechanism for creating reusable Java objects that can interact with other objects dynamically in a consistent fashion. The closest thing you can do in Java is to create applets and attempt to allow them to communicate with each other on a Web page, which isn't a very straightforward task. Java Beans provides the framework by which this communication can take place with ease. Even more important is the fact that Java Beans components can be easily tweaked using a standard set of well-defined properties. Basically, Java Beans merges the power of full-blown Java applets with the compactness and reusability of Java AWT components such as buttons.
Java Beans components aren't limited to visual objects such as
buttons, however. You can just as easily develop nonvisual Java
Beans components that perform some background function in concert
with other components. In this way, Java Beans merges the power
of visual Java applets with nonvisual Java applications under
a consistent component framework.
| Note |
Just in case you're wondering what a nonvisual component is, it's any component that doesn't have visible output. When thinking of components in terms of AWT objects like buttons and menus, this may seem a little strange. However, keep in mind that a component is simply a tightly packaged program and has no specific requirement of being visual. A good example of a nonvisual component is a timer component that fires timing events at specified intervals. Timer components are very popular in other component development environments such as Microsoft Visual Basic. |
By using visual tools, you can use a variety of Java Beans components without necessarily writing any code. This ability to use a variety of components together regardless of their origin is an enhancement to the current Java model. You can certainly use other prebuilt objects in Java, but you must have an intimate knowledge of the object's interface. Additionally, you must integrate the object into your code programmatically. Java Beans components expose their own interfaces visually, providing a means to edit their properties without programming. Furthermore, when you use a visual editor, you can simply "drop" a Java Beans component directly into an application without writing any code. This is an entirely new level of flexibility and reuse not previously possible in Java alone.
Okay, I've rambled enough about Java Beans from the standpoint of what it does and why it's cool. Let's focus now on some specifics regarding how all this is possible. Keep in mind that Java Beans is ultimately a programming interface, meaning that all its features are implemented as extensions to the standard Java class library. The Java Beans API itself is merely a suite of smaller APIs devoted to specific functions, or services. Following is a list of the main component services in the Java Beans API that are necessary to facilitate all the features you've been learning about:
By understanding these services and how they work, you'll have much more insight into exactly the type of technology Java Beans is. Each of these services is implemented in the form of smaller APIs contained within the larger Java Beans API. For the latest information on the Java Beans API, refer to JavaSoft's Java Beans Web site, located at http://splash.javasoft.com/beans/.
The last of the standard extension APIs is the Embedded API, which defines a minimal set of Java functionality specifically targeted for embedded systems applications, such as consumer electronics devices. An embedded system is a scaled-down computer system programmed to perform a particular function within an electronic device. The Embedded API is the only API that doesn't really add anything to the Java core API. In fact, the Embedded API will more than likely be a subset of the core API because only a partial amount of the core functionality is needed in embedded applications. For example, because most embedded systems have no graphical output to speak of, the entire AWT is really unnecessary. Likewise, a network connection is unlikely in an embedded system, so there is no need to include the Java networking package.
More than likely, the Embedded API will consist of the following packages from the core API: language, utilities, and I/O. Beyond those, it's possible that Embedded API extensions could be developed to support specialized networking and output requirements. Because the Embedded API is itself a subset of the core API, it will more than likely be treated as an extension API.
In this chapter, you learned about the standard extension APIs that are planned to expand Java in a variety of directions. These APIs will no doubt boost the appeal of Java to new levels because developers will have much more reusable code to leverage when building custom applications and applets. Although this will ultimately mean more learning on the part of developers, it will also result in less time spent writing code that is best suited to a standard extension. Knowing this, many developers will be forced to rethink their current plans based on the availability of the standard extension APIs because there's no need to reinvent the wheel if it's already in the works.
As you learned in this chapter, some of the standard extension APIs will be merged into the core Java API. Much of this merging will no doubt occur in the next major release of Java (Java 1.1). Even though Java 1.1 isn't available at the time of this writing, you can begin using the standard extension APIs as they become available. Stay tuned to JavaSoft's Web site (www.javasoft.com) for the latest news on the standard extension APIs and Java 1.1.
If these new extensions to Java have gotten you excited about the future of Java, you may be eager to read on. Chapter 47, "The Scoop on JavaOS, Java Microprocessors, and JAR Files," takes a look at some interesting new technologies related to Java that you may not have heard about yet-including a Java operating system, Java microprocessors, and a new Java fileformat.