| By Ajit Sagar | Article Rating: |
|
| July 1, 1998 12:00 AM EDT | Reads: |
11,061 |
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
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:
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 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.
Published July 1, 1998 Reads 11,061
Copyright © 1998 SYS-CON Media, Inc. — All Rights Reserved.
Syndicated stories and blog feeds, all rights reserved by the author.
More Stories By Ajit Sagar
Ajit Sagar is a principal architect with Infosys Technologies, Ltd., a global consulting and IT services company. Ajit has been working with Java since 1997, and has more than 15 years experience in the IT industry. During this tenure, he's been a programmer, lead architect, director of engineering, and product manager for companies from 15 to 25,000 people in size. Ajit has served as JDJ's J2EE editor, was the founding editor of XML Journal, and has been a frequent speaker at SYS-CON's Web Services Edge series of conferences, JavaOne, and international conference. He has published more than 125 articles.
- Patterns for Building High Performance Applications
- It's the Java vs. C++ Shootout Revisited!
- Asynchronous Logging Using Spring
- Java for Programmers (2nd Edition)
- Cross-Platform Mobile Website Development – a Tool Comparison
- Three Buzzwords That Every CIO Hears but One They Should Listen To
- Write Once Run Anywhere or Cross Platform Mobile Development Tools
- Immersing into JavaScript Frameworks
- Workday Reportedly Prepping to Go Public
- Cloud Expo New York: The Java EE 7 Platform - Developing for the Cloud
- Book Review: Sams Teach Yourself Java in 24 Hours
- OpenOffice.com Lives
- Book Excerpt: Introducing HTML5
- Adobe Sends Flex to the Apache Foundation
- Five Years Waiting for JRE 7: Is It Justified? (Part 1)
- Book Excerpt: Java Application Profiling Tips and Tricks
- i-Technology in 2012: Five Industry Predictions
- Patterns for Building High Performance Applications
- It's the Java vs. C++ Shootout Revisited!
- OpenXava 4.3: Rapid Java Web Development
- The Next Web Architecture
- Asynchronous Logging Using Spring
- Java for Programmers (2nd Edition)
- Is Write Once Run Anywhere Ever Going to Be a Reality?
- A Cup of AJAX? Nay, Just Regular Java Please
- Java Developer's Journal Exclusive: 2006 "JDJ Editors' Choice" Awards
- JavaServer Faces (JSF) vs Struts
- The i-Technology Right Stuff
- Rich Internet Applications with Adobe Flex 2 and Java
- Java vs C++ "Shootout" Revisited
- Bean-Managed Persistence Using a Proxy List
- Reporting Made Easy with JasperReports and Hibernate
- Creating a Pet Store Application with JavaServer Faces, Spring, and Hibernate
- Why Do 'Cool Kids' Choose Ruby or PHP to Build Websites Instead of Java?
- What's New in Eclipse?
- i-Technology Predictions for 2007: Where's It All Headed?




















