EarthWeb sites:

Day 27

The Standard Extension APIs

by Michael Morrison

• Java API Overview
• The Enterprise API
  • Java Database Connectivity
  • Interface Definition Language
  • Remote Method Invocation
• The Commerce API
• The Management API
• The Server API
• The Media API
• The Security API
• The Java Beans API
• The Embedded API
• Summary
• Q&A
  

Throughout this book you've learned a lot about the Java programming environment and how it can be used to create interactive Web-based programs. Your knowledge of Java thus far has been entirely based on what is known as the core Java API, or Java Base API. Until recently, this core API comprised the entirety of the Java programming landscape. However, JavaSoft recently announced a broad plan for integrating various new software technologies into the Java API. These new technologies come in the form of extension APIs that integrate with the core Java API, and they are referred to as the standard extension APIs. At some point, many of these APIs will merge and become part of the core API, but for now they are all being presented as extensions.

Today's lesson takes a look at these new APIs and discusses what they have to offer, along with exactly how they will integrate with the existing core API. The main topics you cover today are

• Java software platform overview
• Enterprise and commerce API extensions
• Management and server API extensions
• Media API extensions
• Security API extensions
• Component API extensions
• Embedded systems API extensions

Most of these API extensions are very new and haven't even reached the specification stage. For this reason, today's lesson is only 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 since they are in a constant state of flux.

Java API Overview

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, he 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 addressing 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, thereby reducing the need for custom coding. Some of these new APIs will merge with the core API; 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 since they extend the current core API as we know it.

The standard extension API is broken up into a set of individual APIs targeting different development needs. Following are the major components of the standard extension APIs:

• Enterprise API
• Commerce API
• Management API
• Server API
• Media API
• Security API
• Java Beans API
• Embedded API

The rest of today's lesson focuses on each of these APIs and how they affect the Java software platform.

The Enterprise API

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 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 give Java programs a formal mechanism for connecting to enterprise information systems. This is a much-needed feature in Java since 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:

• Java Database Connectivity (JDBC)
• Interface Definition Language (IDL)
• Remote Method Invocation (RMI)

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.

Java Database Connectivity

The first of these subset APIs, JDBC, defines a structured interface to SQL (Structured Query Language) databases, which is the industry standard approach to accessing relational databases. By supporting SQL, JDBC allows developers to interact 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, so 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. JDBC Java programs will be able to use the familiar SQL programming model of issuing SQL statements and processing the resulting data. The JDBC API is largely dependent on a driver manager that supports multiple drivers connecting to different databases. JDBC database drivers can be either written entirely in Java or implemented using native methods to bridge Java applications to existing database access libraries.

Interface Definition Language

The 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 use of the IDL API is to transparently connect Java client programs to legacy systems.

The Java IDL API includes the following components:

• A client framework that allows Java IDL clients to be designed as either applets or standalone applications
• A server framework that allows Java applications to act as network servers for IDL clients
• A development tool that automatically generates stub code for specific remote interfaces

Remote Method Invocation

The 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 adding full support for remote object communications. The RMI API makes it straightforward for Java developers to add remote computing support to their classes.

The Commerce API

As the role of the Internet continues to evolve from being just an information source to also being a retail marketplace, the need for a secure commercial transaction protocol is growing to new heights. Both Internet vendors and shoppers alike are eagerly awaiting the inevitable migration of shopping to the Web. JavaSoft has provided an answer to the secure purchasing problem with the Commerce API, which is 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:

• An infrastructure
• A database
• Payment cassettes
• Service cassettes
• Administrative interfaces

The infrastructure of the Commerce API is basically the architectural framework that defines the interactions between the other components of the API. This infrastructure is also what gives the API its extensibility to support future commerce extensions.

The database component serves as a repository for user information, such as payment methods and the user's shipping address. The database component contains encryption features so that user information can be kept completely private. Alternately, commerce service providers have the option of sharing user information with one another.

The Commerce API makes use of cassettes, which are software modules that implement specific financial protocols. The two different types of cassettes supported are payment cassettes and service cassettes. A payment cassette defines the protocol for making electronic payments. Examples of payment cassettes are credit cards, debit cards, and eventually digital cash. A user could have multiple payment cassettes that represent different payment instruments, much like we carry different payment instruments in our wallets or purses. In fact, one of the classes in the Commerce API specifically models an electronic wallet.

Service cassettes are more general, and they model any type of value-added financial service such as financial analysis or tax preparation modules. For example, you could feasibly purchase a service cassette to help balance your electronic checkbook or assess the value of your stock portfolio.

The last component of the Commerce API includes administrative interfaces, which are dialog boxes and other graphical interfaces used to retrieve information from the user and to configure commerce options.

The Management API

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:

• The Admin View Module (AVM)
• Base object interfaces
• Managed container interfaces
• Managed notification interfaces
• Managed data interfaces
• Managed protocol interfaces
• SNMP interfaces
• Applet integration interfaces

The Admin View Module is an extension of the Java Abstract Windowing Toolkit (awt) that is enhanced to provide specific support for creating integrated management applications. The classes implemented in the AVM serve as a basis for developing sophisticated graphical user interfaces. For example, the AVM includes support for graphical tables, charts, graphs, and meters.

The base object interfaces define the core object types that are used for distributed resources and services in a management system. Using the base object interfaces, developers can define abstractions for a variety of attributes associated with a managed enterprise environment.

The managed container interfaces define a means for grouping together managed objects for better organization. This organization facilitates a more group-oriented approach to keeping up with managed resources, which can be a great benefit in complex systems.

The managed notification interfaces define a core foundation of managed-event notification services. Developers are free to develop more advanced application-specific notification services by extending these services.

The managed data interfaces provide a means of linking managed object attributes to relational databases via JDBC. In doing so, the managed data interfaces establish a transparent link between management resources and external databases.

The managed protocol interfaces use the Java Security APIs and Java RMI to add secure distributed object support to the core functionality provided by the base object interfaces. In turn, the SNMP interfaces extend the managed protocol interfaces to provide support for SNMP agents. Since SNMP is the most popular management protocol in use, its support via the SNMP interfaces is an important part of the Management API.

Finally, the applet integration interfaces component of the Management API specifies how Java applets can be integrated with the Management API to provide management solutions. Applet developers use the applet integration interfaces to build management support into their applets.

The Server API

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. JavaSoft plans to keep the Server API an extension separate from the core API.

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.

The Media API

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. 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 could do that already 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, and telephony. 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 like 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 the fact that the world of multimedia is ever 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 Media Framework API
• The 2D Graphics API
• The Animation API
• The 3D Graphics API
• The Video API
• The Audio API
• The MIDI API
• The Share API
• The Telephony API

The Media Framework API handles the low-level timing functionality required by many of the other media APIs. This API includes support for timing and synchronization, both of which are critical to media types that must function together in harmony. Also included in the Media Framework API is support for streaming, compression, and live data sources.

The 2D Graphics API extends the functionality of the awt classes to provide wider support for 2D graphics primitives and a variety of different graphical output devices, such as printers. Another important addition to the 2D Graphics API is the definition of a uniform graphical model that brings many graphics functions into one structure. The Animation API uses the 2D Graphics API as a basis for its implementation of animated 2D graphics objects, or sprites. It also relies on the Media Framework API for maintaining timing and synchronization.

The 3D Graphics API provides the overhead necessary to generate high-performance 3D graphics. This API implements 3D graphics by supporting a model of 3D graphical objects that can be rendered at high speeds. The 3D Graphics API also includes support for VRML, which is a popular 3D modeling language. To pull off all this functionality, the 3D Graphics API relies heavily on the functions provided by many of the other media APIs.

The Video API brings full-motion video to Java. The API provides the framework for managing and processing video in either a streaming or stored scenario. Similar to the Video API in some ways, the Audio API also provides support for both streaming and stored media. However, the media supported by the Audio API consists of either sampled or synthesized audio. The Audio API even contains classes for implementing 3D spatial audio.

The MIDI API brings timed musical events to Java by way of the popular MIDI standard. MIDI is an efficient way to represent both musical pieces as well as more general timing resources. Expect to hear the Web much differently once this API catches on!

The Share API is probably the most interesting of the media APIs, simply because it's the least obvious. It defines a means by which live, multiparty communication can take place over a network. The Share API provides support for both synchronization and session management. I wouldn't be surprised to see multiplayer games and "chat" applets take on a new feel once this API is out.

The last of the media APIs is the Telephony API, which gives Java the ability to interact with telephones. Most important telephone functions, including teleconferencing and caller ID, are supported in this API.

The Security 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. The Security API will eventually be incorporated directly into the core Java API.

The cryptographic functions built into the Security API are isolated from the programmatic interface used by applets wanting to make security decisions. This layering allows the cryptographic functions to be replaced by third-party alternatives without impacting any-thing at the applet level, thereby giving Java developers more options when it comes to their security needs.

The Java Beans API

The Java Beans API defines an open standard for implementing dynamic Java software components, which are tightly packaged classes designed for reusability. Because the Java Beans API is given prominent coverage in tomorrow's lesson, I'll spare you the juicy details for now. However, I will tell you now that the Java Beans API is planned to merge with the core Java API at some point.

The Embedded API

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. The Embedded API is the only API that doesn't really add anything to the Java core API. In fact, the Embedded API will likely be a subset of the core API since only part of the core functionality is needed in embedded applications. For example, since 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.

It is likely that 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. Since the Embedded API is itself a subset of the core API, it will probably be treated as an extension API.

Summary

Today you have learned about the standard extension APIs that are planned to expand Java in a variety of different directions. These APIs will no doubt boost the appeal of Java to new levels, since 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, as there's no need to reinvent the wheel if it's already in the works.

Tomorrow you'll continue to learn about Java extensions by looking at some other technologies that are going to affect Java in the near future.

Q&A