by Michael Morrison
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
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 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:
The rest of today's lesson focuses on each of these APIs and how they affect 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 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:
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 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.
| New Term |
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. |
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.
| New Term |
A result set is a group data retrieved from a database after a user request. |
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.
| New Term |
A legacy system is an outdated system that has yet to be reimplemented using current technologies. |
The Java IDL API includes the following components:
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.
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:
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.
| New Term |
A cassette is a software module that implements a specific payment protocol. |
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 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 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.
| New Term |
SNMP stands for Simple Network Management Protocol, which is a relatively simple protocol originally developed to solve communication problems between different types of networks and gather network statistics. |
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.
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.
| New Term |
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.
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 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.
| New Term |
Synchronization refers to how different time-based media elements agree with each other in time. For example, it is important for the sound track of a movie to remain synchronized with the picture. |
| New Term |
Streaming is the process of interacting with data while it is still being transferred. For example, a streaming audio player would begin playing audio as soon as a certain minimal amount of data has been transferred. |
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!
| New Term |
MIDI stands for Musical Instrument Digital Interface. It defines a protocol for communicating and storing time-based events, such as those generated by playing a musical instrument. |
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 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.
| New Term |
Cryptography encompasses the algorithms and techniques used to render data unrecognizable in the hands of unauthorized parties, thereby enforcing information privacy. |
| New Term |
A digital signature is an electronic identification technique that serves much the same purpose as a handwritten signature. |
| New Term |
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 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 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 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.
| New Term |
An embedded system is a scaled-down computer system programmed to perform a particular function within an electronic device. |
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.
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.
| What exactly is the core Java API and how will it change? | |
| The core Java API as of Java version 1.02 consists of the eight packages that are shipped with version 1.02 of the Java Developer's Kit. This API will change in future releases to incorporate some of the technologies that are emerging as part of the standard extension APIs. However, not all of the standard extension APIs will make it into the core API; some will remain as extensions. | |
| Will the Commerce API help standardize financial transactions on the Web? | |
| I sure hope so. Considering the large amount of Java development already taking place, combined with JavaSoft's desire to make the Commerce API extensible to a variety of technologies, it stands to reason that the Commerce API will be a major force in shaping the future of financial transactions on the Web. | |
| How are servlets developed? | |
| Servlets are developed in much the same way as applets, except you use the Servlet API instead of the Applet API. Most servlets probably won't have graphical interfaces, but the approach of developing servlets based on an API is still very similar to the current approach to developing applets. | |
| How will digital signatures affect Java security? | |
| It's still not clear what the total impact of digital signatures will be on Java security, but the most likely change will be the removal of the local file access restriction on applets. Using digital signatures, it will be possible to validate the origination of an applet so that users can feel safe allowing the applet more freedom on their system. |