Java Expands Its Language Facilities to Better Support Complex Application Development
Although the hype surrounding Java has propelled this Web-based programming language and platform into the forefront of client/server application development, Java's initial capabilities left a lot to be desired. Java did small applets and applications very well (such as animation), but client/server developers found that Java was not as well suited for true business application development. It was certainly not comparable to other general-purpose languages of today such as C++.
The problem was a lack of prebuilt application components and service-level APIs, which provide developers with access to "canned" application components (such as GUI controls) and resources (such as relational data). Developers are creating full-blown applications today using Java; however, they are doing so with an excessive amount of customization and hand-coding.
To fill this void, JavaSoft (a division of Sun Microsystems Inc., Mountain View, Calif.) has come up with a set of Java API standards and products set to propel Java into the world of mainstream application development. These APIs enable developers and Java tool vendors to create Java-based applications using a set of prebuilt objects and predefined services.
Although this API effort was driven by JavaSoft, Java-enabled tool vendors and standards organizations are really the ones driving the success of the APIs. For instance, at press time ISO and JavaSoft were in the process of creating a Java language standard. Java-enabled tool vendors and standards organizations are all building their own value into Java, delivering combined value into future tools and applications.
Because these APIs are quickly becoming part of Java, it's important for developers and application architects to understand the capabilities of these APIs before they become relevant for application development. In this article I explore the basics of the major Java API development efforts and their impact on future Java-enabled application development.
There are two types of Java APIs: the Java Base API and the Java Standard Extension API. (See Figure 1.) The Java Base API provides the basic languages, utility, network, interface, and I/O, supporting applets and applications. It is the basic operating environment that operating system vendors license from JavaSoft. As its name implies, the Java Standard Extension API extends the capabilities of the Java Base API. The idea is to build some of the features of the Java Standard Extension API into the Java Base API as the features mature.
The Java Base API defines the core features for building and deploying fully functional Java applets or applications. This includes all of the "base" classes, such as java.lang, java.util, java.io, java.net, java.awt, and java.applets.
The Java API framework is open, meaning that any interested party can contact JavaSoft with an API proposal. Specifications for each interface are developed by different specialists. JavaSoft is promoting the development of these specifications and making them available for public review (see www.javasoft.com) before they become a part of the base API.
The API standard is organized by sets or groups. Each API set is implemented as one or more packages, and each package set is a group of Java classes and interfaces. In the rest of this article I discuss the groups that developers can integrate into their Java applications.
JavaBeans lets developers create dynamic Java components and reuse them within and among applications. What's more, developers can mix and match components from third-party component vendors or use the base set of components that comes with the JDK. JavaBeans is already a part of the JDK 1.0.2, and you'll also find it in the JDK 1.1 when it becomes available (an "early access" beta is now available for download). Once JavaBeans is standard, you can count on Java application development tool vendors, such as Borland International Inc. and Symantec Corp., to include it in their standard development architectures.
The JavaBeans component model can bridge to other non-Java component object models, such as Microsoft Corp.'s Component Object Model (COM), OpenDoc, and Netscape Communications Corp.'s Live Connect. Because JavaBeans is part of the Java platform, developers need not send any extra libraries to get a JavaBeans-enabled application up and running.
The JavaBeans API supports the Event Handling, Properties, Persistence, Introspection, and Application Builders API. The Event Handling API lets components link and send events to other JavaBeans components. The Persistence API lets developers store parts to the state of the parent container. The Introspection API lets developers learn about methods, interfaces, and variables for each Java class. The Application Builder API uses editors (called customizers) that give developers the means to create customized components for their applications.
The IDL, as with other distributed objects, gives the Java application developer a language- and platform-neutral way to define an interface between two or more objects. The IDL provides mappings of its application functions, allowing other objects to invoke an application service. This is the concept and technology behind CORBA-based distributed objects. The IDL will permit Java applets or applications to coexist in existing or future distributed object environments. Both Visigenic and Iona have Java-enabled distributed object solutions.
RMI lets developers create Java applets or applications that can invoke methods encapsulated within other Java virtual machines. Thus RMI enables applets to reach across a network, providing peer-to-peer client/server development using a mechanism similar to a remote procedure call (RPC). A Java application or applet can make a call to a remote Java object once it obtains the reference to the remote objects, either by using a bootstrap naming service (provided by the RMI) or by receiving the reference as an argument. Once the client/server relationship is established, it's just matter of making the remote call from the applet or application. A client can call a remote object on the server, and the server is able to act as the client of other remote Java applets or applications. RMI employs Object Serialization to control the links and support object-oriented services.
JDBC is probably the most famous portion of the Enterprise API; it promises to bring Java closer to traditional two-tier client/server. (For more background information on JDBC, see my article, "The JDBC Connection," in the October 1996 Internet Systems, page 21.) JDBC is the middleware that provides easy links to popular relational databases directly from Java applets or applications. JDBC, like its cousin ODBC, is a standard SQL database access interface, allowing Java developers to access any number of relational databases using the same API syntax simply by swapping out drivers. (See Figure 2.) JDBC also provides a common code base to enable Java application development tool vendors to build common database interfaces. Until now, Java-to-database connectivity has been pretty much a proprietary or highly customized world. Currently, a huge number of client/server tool, database, and middleware vendors are lining up to support the JDBC specification.
The JDBC API is really a set of Java classes that define all of the database connectivity functions such as connections, request statement (SQL), determining metadata, and processing the result set once it returns from the database server. JDBC will support all databases willing to produce a JDBC driver or any ODBC-ready database through a JDBC-ODBC bridge. (The JDBC-ODBC bridge is a joint project between JavaSoft and Intersolv.)
Servlets, like applets, are platform-independent. They may reside on the server or come from another server using the built-in security services of Java. Servlets can access server-side resources and services such as HTTP, and thus they can even provide database connectivity through JDBC.
The servlet architecture is simple. Once you create the connection from the client to the servlet, both the client and the servlet communicate through a custom protocol (subprotocol). An applet is downloaded from the Web server, which in turn communicates with a servlet running on a Web server. Servlets are very much like applets, but they can't interface with the user. What's more, unlike CGI processes, servlets aren't invoked for every request but instead sit in memory waiting for a request to come on from a client. The unique thing about servlets is their ability to be dynamically loaded into a running server. Thus developers can program agents that are able to roam a network, communicate with new hosts gathering information, and then return.
The servlet API serves as the glue that binds Java to HTTP server features. The API provides a method for initializing a servlet, carrying out a preprogrammed function, and then destroying itself.
The architecture is advanced: The Java Security API provides an abstract layer below the application; the application calls that layer, which in turn calls the Java Security packages that implement the security feature, such as cryptography. This means that anyone can create cryptography packages for Java, thus extending this API for a particular use. The Java Security API also provides support for Key management for secure database transactions and certificate facilities.
The beauty of the Java Security API is its ability to support new features as they become available. For example, when new algorithms become available, they can snap right into the application without affecting the base functionality of the application.
There are several components to this framework, including Wallet, Merchant, Consumer, Instrument, Shopping Cart, and Cassette. The Wallet is simply the GUI that the consumer uses for business transactions. The Consumer is the browser that links into the merchant's Web site and selects items for purchase. An Instrument is a means of paying for the goods or services; it facilitates an electronic commerce transaction and provides constructs such as protocols, authentication mechanisms, and management mechanisms. Typical instruments are credit cards. The Merchant is the entity that offers goods and services on the Web using Java applets. The applets use standard code modules called Cassettes.
A Cassette is really a Java package that consumers can download and install on their computer. Cassettes are created, distributed, and digitally signed by providers such as retail stores and banks. The digital signature enables the Cassette to trade with that particular merchant because it defines how that merchant does business.
A Java Wallet contains all of your personal information, such as the name, address, and phone number for the customer as well as payment instruments such as credit cards and e-cash. The Wallet also supports two types of applets: the payment cassettes, which are able to implement particular types of payment protocols (for example, Secure Electronic Transaction [SET], now part of Visa and MasterCard), and the service cassettes, which provide value-added services such as financial planning assistance. Wallets also provide extensibility, allowing for the easy integration of new payment and service cassettes downloaded from the Web, and a set of cryptographic services shielding these electronic transactions from snoops on the network.
When purchasing goods or services using the Commerce API, an untrusted merchant applet (such as a shopping cart) creates a Java object by creating the ActionBuider interface. This interface works with the user to gather all meaningful information. Then the ActionBuilder creates an object that implements the Action interface; the interface in turn invokes the transaction. (See Figure 3.)
The Admin View module gives developers a version of the Abstract Window Toolkit (AWT) built specifically for creating system-management applications. The Base Object interfaces enable developers to create distributed resources and services for management applications. The Managed Notification interfaces give management applications a foundation from which more complex event-management services may be layered. The Managed Container interfaces let developers group management applications to perform services as a tightly coupled group, thus allowing scalability. The Managed Data interfaces support mapping attributes of the Base Object interfaces to relational databases that use JDBC as the interface. The Managed Protocol interfaces implement the distribution and security features for the extension of the Base Object interfaces, and build on the Java security APIs and RMI. Finally, the SNMP interface lets developers extend the Base Object to contain information gathered from existing SNMP agents, thus granting all SNMP information access from the Java management application.
The Media API is composed of several components, each related to a certain type of media or media-related service. One component, the Java Media API Framework, contains a Video API, an Audio API, and a MIDI API. Other components include the Java Animation API, the Java Share API, the Java Telephony API, and the Java 3D API.
The Java Animation API supports traditional 2D animation using stacking order control. The Java Telephony API enables developers to create applications and applets that can control phone calls and access telephony-related information and services such as call transfer, caller ID, and DTMF decode/encode. The Java Media Framework API handles traditional multimedia capabilities such as audio and video using a common model for timing, synchronization, and composition.
JavaSoft still must compete for dominance in the major-market browser world. Right now Microsoft is not willing to declare defeat; in fact, ActiveX has been able to keep up with all of Java's capabilities thus far, and there is no clear winner as of yet. What's more, ActiveX can concentrate on Windows, but Java must take all platforms into account. Count on a battle of features from now until the end of the year. The emerging Java API standards are just another salvo from JavaSoft, and Microsoft is sure to return fire.
As developers, we need to look beyond the hype and conflict and consider how well Java will solve today's business problems. With the Java API, Java is able to overcome many of its earlier limitations, such as remote database connectivity, security, multimedia, and component-based development. What's more, the openness of the Java API means that anyone with a good idea can build value into the API. However, it's going to take a few months before we work all of the kinks out of the API and successfully integrate it with the popular tools to make the Java API more accessible. For those of us who have custom-coded our way through the existing Java incarnation, the advent of the Java API is a welcome sight.
You can count on additional releases of the Java API and its subcomponents in the near future. You can also count on new API components to come along shortly. Java will finally prove itself as a language and platform for the enterprise. It's about time.
