Network Deployment of JavaBeans

by Jim Knutson and Walter Falk


Abstract

After JavaBeans have been created to solve a specific business problem, they must be deployed. This article looks at some of the problems associated with deployment--especially network deployment--of JavaBeans and at how IBM's BeanExtender solves these problems. For example, problems arise in managing installed JavaBeans that have been packaged in JAR or zip files, and further problems result from trying to work around the original problem. Some solutions: The deployment server can manage a repository of JavaBeans stored in a variety of formats, including JAR files, zip files, and directories. And BeanExtender supports a subscription-based deployment service as well as on-demand class use, which enables clients to dynamically request JavaBeans from servers as needed.


JavaBeans Deployment

Have you ever thought about how to deploy your new JavaBeans application and wondered not only how users would gain access to it, but also how they would install it? The tools and specifications associated with deployment of JavaBeans are not without problems. Some of these problems consist of the basic need for additional tool support, and other problems are related to the Java specification itself.

The Java Development Kit (JDK) and JavaBeans specification from Sun Microsystems, Inc., provide some tools and definitions required for supporting deployment of JavaBeans. The tool support is somewhat limited, but the specification is sufficient to create the definitions necessary for exchanging JavaBeans.

The JDK provides a tool to help package Java classes and related files together into a deployable unit called a JAR (Java Archive) file. The JAR tool operates similarly to tools that produce and manipulate zip files. However, the JAR tool also knows about additional meta-data that can be included in the JAR file. This meta-data, kept in a file called META-INF/MANIFEST.MF, describes additional information about the classes contained within the JAR file, and it allows other tools to manipulate the content. The meta-data includes information such as checksums and tags indicating which classes are JavaBeans. This is important information because builder tools treat JavaBeans differently than they treat other Java classes.

After JAR files are created, they can be deployed for use by other developers and end users. JAR files are typically downloaded by the user from a Web server. The content must then be made available to the Java Virtual Machine (VM). There are two ways to do this.

The most typical way that Java classes are made available to the Java VM is by extracting the contents of the JAR file to a directory and adding that directory to the CLASSPATH. The Java VM uses the CLASSPATH to locate classes at run time. If the needed class is not found in the proper location in the CLASSPATH, an exception is thrown and execution usually halts.

A less common method of installing JAR files is to use a special class loader that locates classes stored in JAR files and makes them accessible to the Java VM. This is the method used by JavaSoft's BeanBox tool to access JavaBeans in JAR files. If the class loader cannot find the desired class, it may use other class loaders or throw an exception.


Problems with Deployment

When installing and using JavaBeans that have been packaged in JAR or zip files, problems with managing installed JavaBeans arise. Further problems result from trying to work around the original problem.

Management of installed JavaBeans is problematic in several ways. Because JavaBeans may be installed by adding the JAR file path to the CLASSPATH the same way that the JDK classes.zip is added to the CLASSPATH, rebooting is necessary on some operating systems before the change takes effect. In addition, many deployed JAR files are small; therefore they can be added to the CLASSPATH simultaneously. This is a problem on systems with limited environment space or maximum size limits for environment variables. To get around the problem, JAR file contents could be extracted to a common location already on the CLASSPATH. However, this leads to the problem of maintaining commingled products from numerous vendors. What would you do if you wanted to un-install a set of JavaBeans? You couldn't simply wipe the common location clean unless you re-installed all the other JavaBeans.

Dealing with ClassLoader objects can be a tricky problem. ClassLoader objects are useful extension mechanisms for finding class files when an object instantiation is needed. In fact, JavaSoft's BeanBox uses an extension of the ClassLoader to find and load class files located inside of JAR files. This rather useful trick allows JavaBeans inside of JAR files to be used without first having to "install" them. In other words, the JAR file contents need not be extracted to a location on the CLASSPATH and the CLASSPATH need not be updated to reference the JAR file. However, it is difficult to implement a ClassLoader extension that does not use delegation to another ClassLoader object if it cannot find what it needs. This leads to a peculiar situation in which one ClassLoader instance knows about a particular class FooClass, but another ClassLoader in the same Java VM does not. In this case, a FooClass instance may exist and work well within the ClassLoader that knows about it, but use by object instances in the ClassLoader that doesn't know about FooClass can fail. Worse yet, the normal Java code for detecting whether a cast can safely be made does not detect this condition.

Another problem that developers face is the maintenance of MANIFEST information within a JAR file. Part of this information is used by builder tools to recognize JavaBeans within a JAR file and their dependencies. Since the content of a JAR file changes over time with the addition of or removal of JavaBeans, the MANIFEST must be altered to reflect the changes. Typically, this requires manual updating, though the JAR tool does provide some support for automatic addition of MANIFEST data for unspecified items. However, the JAR tool provides no operation for removal of content from JAR files. To remove content, the JAR file must be regenerated from scratch without the items that are to be removed. In addition, the MANIFEST must be regenerated without the removed items or an error will occur. These separate and manual operations tend to lead to errors.

A bean is presented as a single entity, but in reality it consists of many related pieces. These pieces include other class files, such as a BeanInfo class, Customizer class, and ResourceBundle class. There may also be associated files, such as icons, data files, image files, sound files, and so on. If a developer wishes to re-factor the content of a JAR file to aid in file-transfer performance, all the associated pieces must be moved along with the bean. Keeping track of all the dependent information can be difficult for a developer to do manually. Fortunately, the specification for MANIFEST files has been extended to support dependency maintenance within a JAR file. However, the JDK tools do not provide default support for manipulating the dependencies.

The specification has not yet dealt with the issue of inter-JAR dependencies. While it is not yet clear whether additions to the specification would be the best way to handle the problem, it is clear that as bean component reuse becomes prevalent, this will become a major issue.

Currently, there is little support from builder tools for maintaining collections of JavaBeans in JAR or zip files. Support exists both in direct import of JavaBeans from JAR files and in producing JAR files as deployable units. This will change over time, but for now developers lack support.


Packaging Solutions

The BeanExtender team at IBM has solved these deployment-related problems. Some of the solutions can be classified as tool-enablement, some as design work-arounds.

The packaging of JavaBeans into a JAR file and manipulation of a JAR file's content is best done by an automated tool that understands how to maintain relationships between the contents. BeanExtender supports dependency management and MANIFEST file maintenance. This support is accomplished through a pair of related classes called ManagedBean and RepositoryModel. A ManagedBean object represents a bean and all the associated pieces of it, such as the bean's .class file,
BeanInfo .class file, Customizer .class file, ResourceBundle .class file, icons, images, etc.

A RepositoryModel class is an abstracted representation of a persistent store of ManagedBean objects. Specializations of a RepositoryModel include JAR repositories, zip repositories, directory repositories, and even network-accessible repositories. All of these repository types allow for the direct manipulation of their content, and they represent places that a Java VM might look for .class files. Adding a bean to a repository is as simple as creating a ManagedBean object and setting references to each piece on which it depends and then adding it to a repository. MANIFEST file maintenance is automatically handled by the repository to always reflect the current content.

The abstraction of a RepositoryModel and a ManagedBean makes it easy for builder tools to deal with a variety of collections of JavaBeans without having to deal with the details of the storage format. From a builder tool's point of view, there is no difference between dealing with a directory of JavaBeans and dealing with a JAR file of JavaBeans other than the path name by which they are referenced. This has two benefits: First, it makes it much easier to write a tool to use and manipulate JAR files or other collections of JavaBeans. Second, it makes it much easier to write smaller tools that effectively take JavaBeans as input, manipulate them, and produce JavaBeans as output. These tools can then be treated as bean components themselves and can be composed and combined into more sophisticated tools, since their inputs and outputs are common.

IBM's BeanExtender solves the installation problems associated with deploying JavaBeans in a number of ways. BeanExtender supports direct use of JavaBeans within a JAR file, which means that you don't have to first extract the JAR file content or explicitly add it to your CLASSPATH. Normally, this would cause additional problems, as explained earlier, due to the use of a special class loader. However, BeanExtender avoids these problems by managing a well-known location on the CLASSPATH and automatically extracting the contents of the JAR file into that location.


Deployment Solutions

BeanExtender currently supports two methods of deploying JavaBeans across a network: subscription-based services and on-demand class loading.


The BeanExtender subscription service allows a developer to publish JavaBeans on a server host. A client can browse subscribable groups of information, which are typically sets of JavaBeans, from any number of servers. When a subscription is made, the client can define how often the subscribable group should be checked for updates. The local copy will be updated when the client detects a change on the server.

An alternative to making a local copy is BeanExtender's on-demand class loading. On-demand class loading waits until a class is actually needed at run time before obtaining the implementation from a network server. This feature is useful in a variety of ways: Subscribing to a set of Beans does not guarantee that the set is complete enough to run. There may be dependencies on additional classes or files not contained within the set. On-demand class loading frees the bean provider from repackaging the run times of dependencies with the JavaBeans that are being deployed. This reduces the disk storage footprint by reducing the number of copies of run times, and it saves on download time. Furthermore, on-demand class loading eliminates the need for local storage before running a bean; this feature is ideal for network computers accessing applications.


Conclusion

Although it is in the early stages of development, BeanExtender provides solutions to many of the problems associated with the deployment of JavaBeans. These technology solutions continue to mature and are expected to appear in several IBM products. Evaluation copies of BeanExtender can be found on the IBM Alphaworks home page at http://www.alphaWorks.ibm.com. Additional information regarding BeanExtender can be found on the IBM BeanExtender Technology Web page at http://www.software.ibm.com/ad/javabeans/beanextender/.




About the Authors

Jim Knutson is the technical lead and manager of the BeanExtender development group at IBM Austin, Texas. Mr. Knutson worked at several companies, including the Microelectronics and Computer Technology Corporation (MCC) in Austin, Texas, before joining IBM in 1993. He has a BS in Computer Science and a total of 20 years of computer industry experience.

Walter Falk is the development and product manager of the IBM Component Technology organization located in Austin, Texas. He has a master's degree in Computer Science and 11 years of industry experience in development of and management of advanced OO frameworks and component models. Since early 1997, Mr. Falk has been responsible for IBM's component technology development, including JavaBeans and Enterprise JavaBeans.




Java is a trademark of Sun Microsystems, Inc.

Other companies, products, and service names may be trademarks or service marks of others.

Copyright    Trademark



  Java Feature Java Home  
IBM HomeOrderEmployment