All Categories :
Java
Chapter 46
The Standard Extension APIs
by Michael Morrison
CONTENTS
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:
- Enterprise API
- Commerce API
- Management API
- Server API
- Media API
- Security API
- Java Beans API
- Embedded API
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:
- 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 (JDBC)
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/.
Interface Definition Language (IDL)
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:
- 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
You can get the latest information on IDL from JavaSoft's IDL
Web site, located at http://splash.javasoft.com/JavaIDL-alpha2.0/pages/.
Remote Method Invocation (RMI)
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:
- Infrastructure. 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.
- Information database. 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.
Alternatively, commerce service providers have the option of sharing
user information with one another.
- Payment cassettes. The Commerce API makes use of cassettes,
which are software modules that implement specific financial protocols.
A payment cassette defines the protocol for making electronic
payments. Examples of payment cassettes include 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. This is the second kind of software
module used by the Commerce API to implement specific financial
protocols. Service cassettes serve to 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 you balance your electronic checkbook or assess the value
of your stock portfolio.
- Administrative interfaces. This component of the Commerce
API includes dialog boxes and other graphical interfaces used
to retrieve information from the user and to configure commerce
options.
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:
- Admin View Module (AVM). The AVM 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.
- Base object interfaces. The base object interfaces
define the core object types 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.
- Managed container interfaces. 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.
- Managed notification interfaces. The managed notification
interfaces define a core foundation of managed event notification
services. Developers are free to create more advanced application-specific
notification services by extending these services.
- Managed data interfaces. The managed data interfaces
provide a means of linking managed object attributes to relational
databases using JDBC. In doing so, the managed data interfaces
establish a transparent link between management resources and
external databases.
- Managed protocol interfaces. 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.
- SNMP interfaces. The Simple Network Management Protocol
(SNMP) interfaces extend the managed protocol interfaces to provide
support for SNMP agents. SNMP is a relatively simple protocol
originally developed to solve communication problems between different
types of networks and gather network statistics. Because SNMP
is the most popular management protocol in use, its support through
the SNMP interfaces is an important part of the Management API.
- Applet integration interfaces. 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.
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:
- Media Framework 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. 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.
Also included in the Media Framework API is support for streaming,
compression, and live data sources. Streaming is the process
of interacting with data while it is still being transferred.
For example, a streaming audio player begins playing audio as
soon as a certain minimal amount of data has been transferred.
- 2D Graphics API. 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.
- Animation API. The Animation API uses the 2D Graphics
API as a basis for its implementation of animated 2D graphics
objects, or sprites. The Animation API also relies on the
Media Framework API for maintaining timing and synchronization.
- 3D Graphics API. 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 very 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.
- Video API. 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.
- Audio API. 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.
- MIDI API. The MIDI (Musical Instrument Digital Interface)
API brings timed musical events to Java by way of the popular
MIDI standard. MIDI defines a protocol for communicating and storing
time-based events, such as those generated by a musical instrument.
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!
- Share API. 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.
- Telephony API. The Telephony API provides Java with
the ability to interact with telephones. Most of the important
telephone functions are supported in this API, including teleconferencing
and caller ID, among others.
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.
The Goal of Java Beans
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:
- Compact and easy to create and use
- Fully portable
- Builds on the inherent strengths of Java
- Leverages robust distributed computing
mechanisms
- Supports flexible design-time component
editors
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.
How Java Beans Relates to Java
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.
The Nuts and Bolts of Java Beans
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:
- GUI-merging APIs. The GUI-merging APIs provide a means
for a component to merge its GUI elements with a container document,
which is usually just the Web page containing the component. A
container document is a document (typically one in HTML)
containing Java Beans components that serves as a parent for all
the components it contains. Most container documents have menus
and toolbars that display any special features provided by the
component. The GUI-merging APIs allow the component to add features
to the container document's menu and toolbar. These APIs also
define the mechanism facilitating space negotiations between components
and their containers. In other words, the GUI-merging APIs also
define the layout properties for components.
- Persistence APIs. The persistence APIs specify the
mechanism by which components can be stored and retrieved within
the context of a containing document. By default, components inherit
the automatic serialization mechanism provided by Java. Developers
are also free to design more elaborate persistence solutions based
on the specific needs of their components.
- Event-handling APIs. The event-handling APIs specify
an event-driven architecture that defines how components interact
with each other. The Java AWT already includes a powerful event-handling
model, which serves as the basis for the event-handling component
APIs. These APIs are critical in allowing components the freedom
to interact with each other in a consistent fashion.
- Introspection APIs. The introspection APIs define the
techniques by which components make their internal structure readily
available at design time. These APIs consist of the functionality
necessary to allow development tools to query a component for
its internal state-including the interfaces, methods, and member
variables that comprise the component. The APIs are divided into
two distinct sections based on the level at which they are being
used. For example, the low-level introspection APIs allow development
tools direct access to component internals, which is a function
you wouldn't necessarily want in the hands of component users.
The high-level APIs use the low-level APIs to determine which
parts of a component are exported for user modification. Although
development tools will undoubtedly make use of both APIs, these
tools will use only the high-level APIs when providing component
information to the user.
- Application-builder support APIs. The application-builder
support APIs provide the overhead necessary for editing and manipulating
components at design time. These APIs are used largely by visual
development tools to provide a means to visually lay out and edit
components while constructing an application. The section of a
component providing visual editing capabilities is specifically
designed to be physically separate from the component itself.
This arrangement is so that standalone runtime components can
be as compact as possible. In a purely runtime environment, components
are transferred with only the necessary runtime component. Developers
who want to use the design-time component facilities can easily
acquire the design-time portion of the component.
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.
Contact
reference@developer.com with questions or comments.
Copyright 1998
EarthWeb Inc., All rights reserved.
PLEASE READ THE ACCEPTABLE USAGE STATEMENT.
Copyright 1998 Macmillan Computer Publishing. All rights reserved.
SHOPPING
JOB BANK
REFERENCE
JOURNAL
COMMUNITY
ABOUT US