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.
|