Improving bundle control in computing environment

Provided is a method for managing sets of OSGi bundles in a manner that enables a developer to control the order in which bundles are activated, both within and among OSGi start levels. Also provided is a method for eliminating multiple instances of the OSGi class loaders that are typically generated for each bundle. A bundle consolidator tool is provided that combines multiple bundles in a set of bundles into a master bundle that appears to the OSGi framework to be a single bundle. An activator method enables the developer to specify the order in which individual bundles are initiated and terminated. In addition, a single class loader thread is employed to activate the individual bundles. The bundle consolidator tool also analyzes the target bundles for name space collisions and, in the event a collision is detected, the tool is programmed to modify byte codes to eliminate the collision.

TECHNICAL FIELD

The present invention relates generally to computing systems and, more specifically, to a method for providing greater control over bundle activation in an OSGi environment.

BACKGROUND OF THE INVENTION

In 1999, the OSGi® Alliance, herein after referred to simply as “OSGi,” was initiated to develop an open specification for the delivery of services over local networks and devices. Currently, the OSGi standard is supported by over eighty (80) companies. OSGi was developed to provide services to environments such as homes, cars and offices. Some embedded devices that employ the OSGi specification include, but are not limited to, television set top boxes, service gateways, cable modems, consumer electronic devices, personal computers (PCs), industrial computers and automobiles. A specification, entitled “The OSGi Services Platform, Release 2,” was published in October 2001.

The OSGi environment is organized around a “framework” and “bundles.” The OSGi framework provides an execution environment for electronically downloadable services, or bundles. The framework includes a Java runtime engine, life cycle management, data storage, version management and a service registry. Bundles are the primary software components in the OSGi environment. They can contain Java classes and other resources, which provide libraries, services, and applications to end-users of a computing system and to other bundles. Typically, bundles are stored in a standard Zip-based Java file format, or Java Archive (JAR) file.

Currently, applications or services are often packaged as a set of bundles that interact with each other and are interdependent. Each bundle must have its own activator and deactivator methods, which are called by the framework whenever the bundle is started or stopped, respectively. The OSGi framework calls bundle activators corresponding to each bundle in a set in a serial fashion when the framework or the bundles are started. The order in which bundles are started and the activators called can be roughly controlled by means of OSGi start levels but, within individual start levels, bundles are activated in an arbitrary order. In addition, the OSGI framework creates a class loader for each bundle started.

What is needed is a method that enables a developer to control the order in which bundles are activated, both within and among start levels, so that interdependencies can be more efficiently managed. Also needed is a method for eliminating multiple instances of class loaders that are, under current practices, generated for each individual bundle. Also needed is a tool for analyzing bundles for dependencies and name space collisions and, if necessary, to modify bundles to eliminate detected name space collisions.

SUMMARY OF THE INVENTION

Provided is a method for managing sets of OSGi bundles in a manner that enables a developer to control the order in which bundles are activated, both within and among OSGi start levels. In this manner, interdependencies among bundles can be more efficiently managed. In current systems, the order in which bundles are activated can only be controlled in a limited fashion by assigning bundles to various start levels. A developer does not have control over the activation order within any particular start level.

Also provided is a method for eliminating multiple instances of the OSGi class loaders that are, under current techniques, generated for each individual bundle. The disclosed subject matter employs a single class loader to load multiple classes.

A bundle consolidator tool is provided that combines multiple bundles in a set of bundles into a master bundle that appears to the OSGi framework to be a single bundle. An activator method within the master bundle enables a developer to specify the order in which individual bundles are initiated and terminated within the master bundle. In addition, a separate thread may be created to activate the individual bundles, thus freeing the OSGi framework activator thread, which generates a class loader and calls the bundle activator for each bundle. In this manner, system performance is improved.

The bundle consolidator tool also analyzes target bundles for name space collisions and, in the event a collision is detected, the tool modifies byte codes within bundles to eliminate the collision.

DETAILED DESCRIPTION OF THE FIGURES

Although described with particular reference to an OSGi framework, the claimed subject matter can be implemented in any information technology (IT) system in which an efficient build and load process is desirable. Those with skill in the computing arts will recognize that the disclosed embodiments have relevance to a wide variety of computing environments in addition to those described below. Further, although described with respect to bundles and projects, the claimed subject matter also is applicable to modules, applications or any other type of interdependent computer logic. In other words, the disclosed technology is applicable to any situation in which there is interdependent computer code and a user or developer needs or wants to control the manner and order in which the code is initiated and/or executed.

In addition, the methods of the disclosed invention can be implemented in software, hardware, or a combination of software and hardware. The hardware portion can be implemented using specialized logic; the software portion can be stored in a memory and executed by a suitable instruction execution system such as a microprocessor, personal computer (PC) or mainframe.

In the context of this document, a “memory” or “recording medium” can be any means that contains, stores, communicates, propagates, or transports the program and/or data for use by or in conjunction with an instruction execution system, apparatus or device. Memory and recording medium can be, but are not limited to, an electronic, magnetic, optical, electromagnetic, infrared or semiconductor system, apparatus or device. Memory an recording medium also includes, but is not limited to, for example the following: a portable computer diskette, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), and a portable compact disk read-only memory or another suitable medium upon which a program and/or data may be stored.

One embodiment, in accordance with the claimed subject, is directed to a programmed method for OSGi bundle management. The term “programmed method”, as used herein, is defined to mean one or more process steps that are presently performed; or, alternatively, one or more process steps that are enabled to be performed at a future point in time. The term programmed method anticipates three alternative forms. First, a programmed method comprises presently performed process steps. Second, a programmed method comprises a computer-readable medium embodying computer instructions, which when executed by a computer performs one or more process steps. Finally, a programmed method comprises a computer system that has been programmed by software, hardware, firmware, or any combination thereof, to perform one or more process steps. It is to be understood that the term “programmed method” is not to be construed as simultaneously having more than one alternative form, but rather is to be construed in the truest sense of an alternative form wherein, at any given point in time, only one of the plurality of alternative forms is present.

Turning now to the figures,FIG. 1is a block diagram of an exemplary computing system architecture100that incorporates the claimed subject matter. A central processing unit (CPU)102is coupled to a monitor104, a keyboard106and a mouse108, which together facilitate human interaction with computing system100. Attached to CPU102is a data storage component110, which may either be incorporated into CPU102i.e. an internal device, or attached externally to CPU102by means of various, commonly available connection devices such as but not limited to, a universal serial bus (USB) port (not shown). Data storage110is illustrated storing several exemplary OSGi bundles, including a first bundle, or “bundle_1,”112, a second bundle, or “bundle_2,”114and a bundle package, or “bundle_P,”116. Bundle_1112and bundle_2114are typical OSGi bundles that are used for illustrative purposes. It should be noted that a typical application or system may include many OSGi bundles, but for the sake of simplicity only two are shown. Bundle_P116is an object that represents an application or package and is employed by a BC tool118, also stored in this example on data storage110, to generate the corresponding application or package according to the disclosed subject matter. Bundle_P116and BC Tool118are described in more detail below in conjunction withFIGS. 3-5.

CPU102is connected to the Internet120, which is also connected to a server computer122. Although in this example, CPU102and server122are communicatively coupled via the Internet, they could also be coupled through any number of communication mediums such as, but not limited to, a local area network (LAN) (not shown).

FIG. 2illustrates an exemplary computing architecture130that supports an OSGi framework136and the claimed subject matter. System130is implemented on a hardware platform, in this example CPU102(FIG. 1). Other possible platforms include, but are not limited to, such computing platforms as server122(FIG. 1), television set top boxes, service gateways, cable modems, consumer electronic devices, personal computers (PCs), industrial computers and automobiles. An operating system (OS)132manages the resources of hardware102. Examples of three OSs that support the claimed subject matter include Linux, Macintosh and the various versions of Windows, all of which, as well as others, should be familiar to those with skill in the computing arts. In this example, OS132is supporting a Java runtime environment134. Java runtime environment134supports the Java programming language, which is a product of Sun Microsystems, Inc. of Santa Clara, Calif. Java runtime environment134includes a Java runtime engine (not shown) which executes Java programs, Java programs are compiled into byte codes which are interpreted by the Java runtime environment134rather then being compiled into native machine code. In this manner, a particular Java program can be written to execute on any hardware platform102and OS132that includes the Java runtime environment134.

OSGi framework136is designed to operate in Java runtime environment134. Framework136provides the core of the OSGi Service Platform Specification. As explained above in the Background, the OSGi Service Platform Specification was first developed in 1999 to simplify the delivery of services over local networks and devices, industrial computers and automobiles. OSGi framework136provides an execution environment for, in this example, electronically downloadable services, or bundles112,114,116(FIG. 1) and BC Tool118(FIG. 1). Framework136includes program life cycle management, data storage, program version management and a service registry for bundles112,114,116and118. In this example, bundles112and114are parts of a single Java application or service defined by bundle_P116and include classes, methods and other resources, which provide functions, or “services,” to end-users of computing system100(FIG. 1) and other bundles. Typically, but not necessarily, bundles112,114,116and118are stored in a standard Zip-based Java file format, or Java Archive (JAR) file.

Bundle_P116, implements aspects of the claimed subject matter by providing a processing “shell” for bundle_1112and bundle_2114. In other words, rather than executing bundle_1112and bindle_2114individually to provide the functionality of the corresponding application or service, a user executes bundle_P116, which then initiates bundle_1112and bundle_2114in an order determined by the developer. In addition, bundle_P116includes a bundle initiator thread (seeFIG. 3) for initiating bundle_1112and bundle_2114. In this manner, bundle_P116eliminates the need for OSGi framework136to create and execute individual class loaders for bundle_1112and bundle_2114.

OSGi bundles112and114include Java classes and other resources (not shown) which provide functions to end users of system100and provide components, or “services,” to other bundles. Bundles typically implement zero or more services. Bundles112and114may include such things as, but not limited to, class files for the Java programming language as well as other data such as, but not limited to, hypertext markup language (HTML) files, help files and icons. Like other OSGI compliant bundles, bundles112and114each include a manifest file142and144, respectively, which describes the contents of the corresponding bundle112or114and provides information that framework136requires to correctly install and activate the corresponding bundle112and114. Bundles112and114also include a special class, or “bundle activator,” (not shown) that provides methods to start and stop the bundle112and114.

It should be noted that, although bundles112and114are typical OSGi bundles, the included bundle activators are not employed when bundles112and114are initiated in a manner in conformity with the claimed subject matter. Rather, the bundle activators of bundles112and114are used only if one or both of the bundles are activated individually rather than as part of the application or system of which they are a part. In the alternative, bundles112and114may not even include bundle activators if their only function is as part of the corresponding application or service. In addition, bundles112and114include, in manifest files142and144, information about any resource dependencies the corresponding bundle112or114may have.

FIG. 3is a class diagram150showing some exemplary attributes and methods of a memory object corresponding to bundle_P116(FIGS. 1 and 2). It should be noted that an actual implementation of bundle_P116may include additional attributes and methods not shown here. Although bundle_P116meets all the specifications for OSGi bundles, bundle_P116is specifically designed to implement aspects of the claimed subject matter.

Memory object150includes a title section152, which merely states the name of object150, i.e. “Package,” an attribute section154, which contains memory elements, or attributes, associated with memory object150, and a method section156, which includes functions, or methods, that are executed in conjunction with memory object150.

PackageID attribute158is a variable of type PackageID that contains a reference to a particular instance of object150. Each instance of object150has a unique value for attribute158that allows each instance to be uniquely identified. PackageID attribute158is employed to locate information concerning the corresponding object and to execute relevant methods on object150. PackageName attribute160is a variable of type String that stores the name of a particular application or package associated with a particular instantiation of object150.

BundleList attribute162is a variable of type Vector that represents a list of particular bundle IDs that comprise the application or package associated with object150. For example, in the following description memory object150is associated with an application that includes bundle_1112(FIGS. 1 and 2) and bundle_2114(FIGS. 1 and 2) and, therefore, bundleList162includes bundle IDs that uniquely identify bundle_1112and bundle_2114.

The order in which bundles are listed in bundleList162determines the order in which the bundles are activated. In other words, when a particular bundle is added to the list, the bundle is inserted into the list in a position corresponding to the order in which the developer intends for the bundle to be activated. In the alternative, bundleList160stores a variable (not shown) in conjunction with each bundleID that corresponds to the desired order of activation. BC Tool118provides an OrganizeBundle function196(seeFIG. 4) that provides the tools for a user or administrator to specify the bundle activation order.

Timestamp attribute164is a variable of type DateTime that stores a value corresponding to the date and time the application or package corresponding to packageName attribute160was last generated, if ever. ResolveCollisions attribute166is a variable of type Boolean that indicates whether or not name space collisions detected by BC tool118(FIGS. 1 and 2) in the application or package represented by package name160and memory object150should be automatically resolved, or corrected, when BC tool118either checks for conflicts or generates the corresponding application or package (seeFIGS. 4 and 5). ConsolidatedLoad attribute168is a variable of type Boolean that indicates whether or not BC tool118(FIGS. 1 and 2) should employ a single class loader to load all bundles referenced bundleList162or to simply call activators associated with each bundle, thereby generating a individual class loader for each bundle. Attributes166and168are explained in more detail below in conjunction withFIG. 4.

Method section156of object150includes an “InsertBundle” method170and a “DeleteBundle” method172. Methods170and172are merely example of two methods that are employed to implement the claimed subject matter. It should be noted that other methods or utility functions (not shown) may also be provided such as, but not limited to, methods to retrieve and set variables such as timestamp164, resolveCollisions166and consolidatedLoad168, to do memory collection and to activate and deactivate the bundle.

DeleteBundle method172is employed to remove a reference to a particular bundle form bundleList162and thus remove the bundle from the package or application that a particular instantiation of memory object150represents. DeleteBundle method172is called with one parameter, a bundleID parameter of data type BundleID. BundleId parameter references the particular bundle that a developer desired to remove from the package or application.

FIG. 4is a block diagram of an exemplary bundle consolidation (BC) tool memory object180corresponding to a bundle consolidation (BC) tool118(FIGS. 1 and 2) employed in conjunction with the claimed subject matter. Memory object180illustrates some exemplary attributes and methods. It should be noted that an actual implementation of memory object180and BC Tool118may include additional attributes and methods not shown here. Although BC Tool118meets all the specifications for OSGi bundles, BC Tool118is specifically designed to implement aspects of the claimed subject matter.

Memory object180includes a title section182, which merely states the name of object180, i.e. “BC Tool,” an attribute section184, which contains memory elements, or attributes, associated with memory object180, and a method section186, which includes functions, or methods, that are executed in conjunction with memory object180.

Attribute section182includes a “bctID” attribute188, which is a variable of type BCToolID that contains a reference to a particular instance of object180. Each instance of object180has a unique value for attribute188that allows each instance to be uniquely identified. BctID attribute188is employed to locate information concerning the corresponding object and to execute relevant methods on object180. Instantiations of object180are stored in data storage110(FIG. 1) of computing system100(FIG. 1).

Method section186of object180includes a “GeneratePackage” method190, a “CheckPackage” method192, a “ResolveCollision” method194, an “OrganizeBundle” method196and an “ActivateBundle” method198. Methods190,192,194,196and198are merely example of several methods or functions that are employed to implement the claimed subject matter. It should be noted that other methods or utility functions (not shown) may also be provided such as, but not limited to, methods to retrieve and set variables (not shown) and to do memory collection or cleanup.

According to the claimed subject matter, method190loads the packages listed in bundleList162(FIG. 3) of memory object150in the order specified within bundleList162. In addition, if serializeLoad attribute (FIG. 3) is set to a value of TRUE, method190employs a single class loader to load all bundles referenced in bundleList162, thus reducing the overhead of loading the application or package corresponding to the particular instantiation of memory object150, which in this example is bundle_P116(FIGS. 1and2). In one embodiment, method190executes CheckPackage method192, explained in more detail below, prior to loading any packages to ensure that no name space issues occur during loading. GeneratePackage method190is explained in more detail below in conjunction withFIG. 5.

CheckPackage method192is called with one parameter, a packageID parameter of data type PackageID. PackageID parameter is employed to uniquely identify a particular application or package represented by an instantiation of packet object150that the developer desires to check for name space collisions. Method192returns a vector that references package IDs158that have name space collision issues. In the event that method192does not detect a name space collision issue, method192returns a NULL value.

ResolveCollision method194is called with two parameters, a packageID parameter of data type PackageID and a bundleList parameter of data type Vector. The packageID parameter is employed to uniquely identify a particular application or package represented by an instantiation of packet object150in which the developer desires to resolve name space collisions detected during execution of CheckPackage method192. Method194determines whether or not the corresponding package150referenced by the packageID parameter has resolveCollisions attribute166set to a value of TRUE or FALSE to determine whether or not to proceed with an attempt to resolve a name space collision resolution. In one embodiment, method194modifies byte codes of appropriate bundles to remove name space collisions. The Vector parameter is a list of package IDs corresponding to packages detected during execution of CheckPackage method192that have name space collision issues that need to be resolved.

OrganizePackage method196is called with one parameter, a packageID parameter of data type PackageID. PackageID parameter is employed to uniquely identify a particular application or package represented by an instantiation of packet object150in which the developer desires to specify the order of activation of the corresponding bundles. In one embodiment, method196generates a graphical user interface (GUI) (not shown) that is displayed on monitor104(FIG. 1) and enables the package developer to rearrange the bundles associated with a target package and then stores the result in conjunction with bundleList162of the target package.

ActivatePackage method198is called with two parameters, a packageID parameter of data type PackageID and a bundleID parameter of data type BundleID. PackageID parameter is employed to uniquely identify a particular application or package represented by an instantiation of packet object150in which the developer desires to activate a corresponding bundle. BundleID parameter is employed to uniquely identify a particular bundle associated with the package identified by the packageID parameter which the developer desires to activate. The procedure for activating bundles is explained in more detail below in conjunction withFIG. 5.

FIG. 5is a flowchart of a Generate Package method200executed in conjunction with the claimed subject matter. Method200corresponds to GeneratePackage method190(FIG. 4) of BC Tool object180(FIG. 4). Method200starts in a “Begin Generate Package” block202and proceeds immediately to a “Receive Package” block204. During block204, process200is initiated by a call to GeneratePackage method190of BC Tool118and the package received corresponds to the packageID parameter passed to method190when method190is called. As explained above in conjunction withFIG. 4, the received package is an instantiation of memory object150(FIG. 3) that represents an application or package that the user is loading into, in this example, computing system100(FIG. 1).

During a “Check for Collision” block206, process200makes a call to CheckPackage method192, including a reference to the packageID corresponding to the package received during block204to determine if there are any name space collision issues with respect to the received package. During a “Collision Detected?” block208, process200determines whether or not a name space collision was detected during block206and, if so, proceeds to a “Resolve Set?” block210. During block210, process200determines whether or not resolveCollisions attribute166(FIG. 3) of the package received during block204is set to a values of TRUE. If attribute166is set to TRUE, process200proceeds to a “Resolve Collision” block212during which process200calls ResolveCollision method194of BC Tool118with the appropriate information stored in the two parameters. Process200then returns to block206during which processing continues as described above.

If during block210process200determines that resolveCollisions attribute166of the package received during block204is not set to a value of TRUE, then control proceeds to a “Throw Exception” block224during which process200takes appropriate action to notify the user or administrator who initiated process200that an unresolved name space collision has occurred. Although not illustrated, process200may proceed to block224is at any point during blocks206,208,210or212if process200determines that a detected collision is unresolvable.

If during block208process200determines that there are no unresolved name space collisions, control proceeds to a “Retrieve Bundle” block214. During block214, process200retrieves from memory a package listed in bundleList162(FIG. 3) of the package received during block204. The particular package retrieved depends upon the order selected for loading. As explained above in conjunction withFIG. 3, there are several ways in which the preferred loading order may be specified. One example is to retrieve the bundles in the order they are listed in bundleList162, assuming that the bundles were stored with that particular method in mind. Another example is to retrieve the bundles based upon priority codes stored in conjunction with the bundleIDs.

During a “Load Consolidated?” block216, process200determines whether or not the consolidatedLoad attribute168(FIG. 3) of the package receive during block204is set to a values of TRUE. If attribute168is not set to TRUE, process200proceeds to an “Activate Bundle” block218during which process200calls the activator associated with the bundle retrieved during block214. In other words, in the typical fashion, the activation of the bundle causes a class loader to be spawned specifically for the bundle, which is the typical technique for loading classes, i.e. a class loader is generated for every bundle. If during block216process200determines that attribute168is set to a value of TRUE, process200proceeds to a “Call Activation” block220during which a single class loader, associated with BD Tool118, is employed to load the bundle as well as any subsequent bundles that are also designated for a consolidated load. In other words, a single class loader thread is employed to activate the individual bundles, thus freeing the OSGi framework activator thread, which typically generates a class loader for each bundle. In this manner, system performance is improved. The difference between Activate Bundle218and Call Activation220is that with respect to block220much of the overhead associated with the multiple threads of block218is eliminated. The functionality of blocks216,218and220is incorporated within ActivateBundle method198(FIG. 4) of memory object180(FIG. 4).

It should be noted that the described subject matter enables the choice of a typical, bundle-by-bundle load or a consolidated loading process to be specified with respect to each bundle. In other words, an attribute (not shown) either of a particular bundle or an attribute (not shown) stored in conjunction with a BundleId within bundleList162can specify whether or not the corresponding bundle uses the bundle's own activator or the consolidated loader of BC Tool118.

Once the bundle has been activated, or loaded, either during block218or block220, process200proceeds to a “More Bundles?” block during which process200determines whether or not there are any bundles listed in bundleList162that remain to be loaded. If so, process200returns to block214retrieves the next bundle and processing continues as described above.

Finally, if process200determines during block222that all bundles in bundleList162have been loaded or if control has completed with respect to Throw Exception block224, process200proceeds to an “End Generate Package” block229in which process200is complete.

While the invention has been shown and described with reference to particular embodiments thereof, it will be understood by those skilled in the art that the foregoing and other changes in form and detail may be made therein without departing from the spirit and scope of the invention, including but not limited to additional, less or modified elements and/or additional, less or modified blocks performed in the same or a different order.