HomeDigital EditionSys-Con RadioSearch Java Cd
Advanced Java AWT Book Reviews/Excerpts Client Server Corba Editorials Embedded Java Enterprise Java IDE's Industry Watch Integration Interviews Java Applet Java & Databases Java & Web Services Java Fundamentals Java Native Interface Java Servlets Java Beans J2ME Libraries .NET Object Orientation Observations/IMHO Product Reviews Scalability & Performance Security Server Side Source Code Straight Talking Swing Threads Using Java with others Wireless XML
 

Let's take a minute to recap the discussion we've had so far in The Cosmic Cup. The Java platform is the software platform for the computing environment defined by Java. The Java platform APIs define the application programming interface for the Java platform, which consists of categories of APIs that address different segments of computing and related industries.

However, several APIs defined under the scope of Java APIs don't fall under any of the formal categories defined under the Java platform, namely Base Platform, Commerce, Security, Media, Enterprise and Server. In last month's column these APIs were mentioned as "Nonstandard Java APIs." This month we'll focus on these APIs.

Before we begin, I'd like to point out that this is not a category formally defined by JavaSoft; it is a category I have defined for the purposes of our discussion, to provide complete coverage of the scope of APIs defined under Java. Note also that for the moment we will forgo discussion of Java technologies that focus on hardware devices, embedded Java and Java operating system APIs (JavaOS). We will also postpone discussion on APIs that focus primarily on browser-based interfaces. These two kinds of APIs warrant independent discussions, and I will cover them in future articles for The Cosmic Cup.

Nonstandard APIs
The APIs defined under the "nonstandard APIs" category supplement the APIs formally defined under the Java platform APIs. They are based on some of the platform APIs and enhance the functionality of the APIs they extend. Figure 1 illustrates the APIs discussed in this article. These APIs are:

  • JavaBeans Activation Framework (JAF)
  • InfoBus
  • JavaMail
  • JavaSpaces
  • JavaHelp
These APIs, and the roles of each API in Java and platform APIs related to each API, are provided in Table 1. The following section briefly examines the APIs listed in the table.

Figure 1
Figure: 1 

Table 1

JavaBeans Activation Framework
This framework (formerly known as Glasgow) enhances the functionality of JavaBeans by adding data awareness to the data types used in JavaBeans-based component design. The standard Java platform does not provide a consistent strategy for determining the data types of a software component, binding typed data to a component or an architecture to support these features. JAF overcomes these shortcomings in the JavaBeans component model.

JAF uses MIME (Multipurpose Internet Mail Extensions) types to encapsulate and determine the data type. Using JAF, developers can write JavaBeans-based components that provide added functionality to Web browsers, office suites and other Beans-based environments. The JAF technology proposes data typing and a registry to hold definitions of these data types. It implements the following services:

  • Determines the type of arbitrary data based on MIME types
  • Encapsulates access to data based on the data's MIME type
  • Discovers operations available on a particular data type
  • Instantiates the software components that correspond to specific operations on a particular piece of data

The major pieces of the JAF are:

  1. DataHandler class: This class provides a consistent interface between JAF-aware clients and other subsystems. It encapsulates a data object (which is an instance of the typed data) and provides methods that can act on this object.

  2. DataSource interface: This interface encapsulates an object that contains the data. The encapsulated object can return a string that defines the MIME type for the data, as well as a stream that provides data access. Classes extending the DataSource interface can be implemented for common data sources like the Web, file systems, IMAP, ftp, etc. The interface can also be extended to allow per-data-source user customizations. The DataSource is set in the DataHandler class. Once this is done, clients can determine the operations available on the data. JAF provides two convenience DataSource class implementations: FileDataSource, which allows access to data in a file, and URLDataSource, which allows access to data at a URL.

  3. CommandMap interface: This interface allows consumers to determine the "commands" available on a particular MIME type. It also provides an interface to retrieve an object that can operate on an object of a particular MIME type. The CommandMap maintains a list of available operations on a particular data type. JAF defines a framework for the CommandMap that allows components to determine which commands are available on the system.

  4. Command Object interface: This interface is extended by JavaBean components in order to interact with the JAF services. This enables the JavaBeans to directly access their DataSource and DataHandler objects to retrieve the data type and act on the data.
The JavaBeans Activation Framework is implemented as a standard extension. Sun provides a reference implementation of JAF for the draft 1.0 specification.

InfoBus
InfoBus enhances the functionality of JavaBeans by enabling dynamic exchange of data between JavaBeans components by defining a small number of interfaces between cooperating Beans and specifying the protocol for use of those interfaces. The JavaBeans model allows developers to construct applications by connecting components programmatically and/or visually. However, the specifications do not suggest methods by which these Beans should dynamically exchange data.

Both the InfoBus and JAF enhance the JavaBeans model, but in different ways. JAF supports data exchange using MIME types, and thus provides support for exchanging typed data. It also supports dynamic determination of the commands associated with the data. InfoBus defines sophisticated data models that have known interfaces to act on the data. It also defines the event mechanism and the protocol for data exchange within a single JVM.

The InfoBus protocols are based on a notion of an information bus. All components that implement these interfaces can plug into the bus. As a member of the bus, any component can exchange data with any other component in a structured way, including arrays, tables and database rowsets. The main components of the InfoBus are:

  1. InfoBus class: This class is at the heart of this technology. An instance of the class is the meeting place where members can join. InfoBus instances can be "named" within the scope of a JVM. The class maintains a static list of existing InfoBus instances, bus members, producers and consumers, and enables communication among them for announcing and locating data items.

  2. InfoBusDataProducer interface: .This interface is used to indicate that an object provides data on the InfoBus. Producers announce the availability of new data items.

  3. InfoBusDataConsumer interface: This interface is implemented by objects that are seeking data from an InfoBus. Often these are visual components that will display the data item, but they can also act as filters where they modify the data and then forward it to other consumers.

  4. InfoBusMember interface: This interface must be implemented by classes that want to join an InfoBus. Typically, data producer and data consumer objects implement this interface.

  5. DataItem interface: This is the base interface for data items. A very lightweight component, it is the basic data unit for data interchange.

  6. InfoBusItemAvailableEvent interface: Event objects implementing this interface are broadcast on behalf of a producer to tell consumers about the availability of a new DataItem.

  7. InfoBusItemRevokedEvent: Event objects implementing this interface are broadcast on behalf of a producer to let consumers know that a previously available DataItem is no longer available.

  8. InfoBusItemRequestedEvent: Event objects implementing this interface are broadcast on behalf of a consumer to let producers know about the need for a particular DataItem.

The InfoBus architecture and API were developed by Lotus Development Corporation, Inc., and Sun Microsystems, Inc. The specification is a final specification as Version 1.1 and will be a standard extension in JDK1.2.

JavaMail
The JavaMail API provides a set of abstract classes that model a mail system. In other words, it provides a platform- and protocol-independent framework on which to build Java-based mail and messaging applications. It includes common convenience classes, which encapsulate common mail functions and protocols. The JavaMail API incorporates concepts from IMAP, MAPI, c-client and other messaging systems.

JavaMail clients use the JavaMail API and Service Providers to implement the JavaMail API. The JavaMail architecture consists of the following layers:

  • The Abstract Layer, which declares interfaces and classes to support mail handling
  • The Internet implementation layer, which implements parts of the Abstract Layer using Internet standards
  • The JAF Layer, which uses JAF to encapsulate data using MIME types and to handle commands for that data
The main interfaces and classes in the JavaMail API are:
  1. Part interface: This interface defines the attributes required to define and format data.
  2. Message class: This is an abstract class that implements the Parts interface and defines a set of attributes and a content for a mail message. The attributes specify addressing information and define the content structure and type. The content is a DataHandler object (from the JAF API). Message subclasses can implement several standard messages. A Message may contain multiple parts, each with its own attributes and content.
  3. Folder class: The Folder object stores Message objects. It can contain other Folders or Message objects.
  4. Store class: This class defines a database that holds a folder hierarchy together with its messages. It also specifies the access protocol for accessing Folders and retrieving messages and methods to access a database, and fetch folders.
  5. Transport class: This class models the transport agent that routes a message to its destination address. It provides methods for sending a Message object to a list of recipients.
  6. Session class: This final concrete class defines global and per-user Mail-related properties that define the interface between a mail-enabled client and the network. It allows JavaMail components to set and get specific properties, a default authenticated session object that is shared between desktops. It also acts as a factory for Store and Transport objects.
  7. MailEvent class: This class provides the base class for all JavaMail events. It is based on the JDK 1.1 event model.
The JavaMail API is implemented as a Java standard extension. Sun's reference implementation of the JavaMail software implementation is currently available as Version 1.0b.

JavaSpaces
JavaSpaces technology provides a tool for building distributes protocols. It uses RMI and object serialization features of Java to solve two related problems in distributed computing - distributed persistence and the design of distributed algorithms. JavaSpaces technology will be used in workflow systems, customer management systems, trading services, agent systems, supply chain management, publish and subscribe services, resource allocation management, etc.

JavaSpaces typically provides services for the middle tier of a typical three-tier client/server application. However, they can run in any tier of an n-tier distributed model. A JavaSpace offers a place for communication between distributed objects on clients and servers in a network. It may also be viewed as an event-driven distributed cache that also supports behavior transfer.

A JavaSpace holds Entries. An entry can be written into a JavaSpace, which copies the Entry into local storage. Entries can be looked up using Templates.

The main parts of a JavaSpace are:

  1. Entry: This is a typed group of object references represented by a Java class.
  2. JavaSpace interface: This interface allows operations on Entries held in the JavaSpace object. The operations supported are write, which writes an entry into the space; read, which returns an entry that matches the template or an indication that no match was found (this basically returns a copy of the entry); take, which returns the actual entry that matches the template or an indication that no match was found (it also removes the entry from the JavaSpace); and notify, which notifies a specified object when entries that match the given template are written into the JavaSpace.
  3. Transaction: This groups multiple operations on an Entry. The operations are applied as a batch of operations.
The JavaSpace specification is in the final version 0.999.

JavaHelp
JavaHelp software is both an API and a platform-independent, extensible help system written entirely in Java. This system provides capabilities for navigating, searching and displaying help information, thus allowing end users to learn how to use an application, applet, component, operating system, device, or Web page. The JavaHelp software can also be used to distribute online documentation in a heterogeneous environment, such as a corporate intranet or Internet.

JavaHelp is currently available as an early access release, version 1.0. It is expected to be publicly available after the release of JDK 1.2.

Conclusion
In this article we examined the APIs that enhance the functionality provided by the standard Java platform APIs. We briefly examined the roles played by individual APIs that fall under this category and looked at the pieces that define these APIs. Links for detailed information on all these APIs may be obtained from Sun's Java Website at http://java.sun.com/products.

Cosmic Reflections
No API is an island. One interesting aspect of the APIs discussed here is that they extend the standard Java APIs to specific domains. In some respects they may be viewed as "helper" APIs. It remains to be seen what new helper APIs will be defined in future incarnations of Java and what aspects of existing APIs they will enhance.

About the Author
Ajit Sagar is a member of the technical staff at i2 Technologies in Dallas, TX. He holds a BS in electrical engineering from BITS Pilani, India, and an M.S. in computer science from Mississippi State University. Ajit focuses on networking, UI, and middleware architecture development. He is a Sun certified Java programmer with eight years of programming experience, including two in Java. You can e-mail him at [email protected]

 

All Rights Reserved
Copyright ©  2004 SYS-CON Media, Inc.
  E-mail: [email protected]

Java and Java-based marks are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States and other countries. SYS-CON Publications, Inc. is independent of Sun Microsystems, Inc.