Dynamic resolution of dependent components

1 DYNAMIC RESOLUTION OF DEPENDENT COMPONENTS

FIELD

The present disclosure generally relates to plug-ins.

BACKGROUND

A plug-in is a computer program that interacts with a host application, such as a web browser, an email client or a server-side application component, to provide certain specific functionality. In various contexts, a plug-in may also be referred to as a plug-in component, a plugin, a pluggable component, a runtime component, or by other names. Typically, dependencies of a plug-in that represent references to extemal entities must be resolved during compile-time.

SUMMARY

According to one general implementation, plug-in dependencies are resolved during the runtime of a host application, and an interface between the host application and the plug-in is selected, based on using meta information stored in a manifest associated with the plug-in. In this manner, the plug-in may be dynamically loaded, unloaded, and/or re-loaded by the host application, without requiring the program code of the host application to reference dependent components of the plug-in.

According to another general implementation, a computerimplemented process includes, during a runtime of an application, dynamically accessing, for a plug-in invoked by the application, a manifest listing classes capable of providing an interface for the plug-in, and dependent components that provide functionality to the plug-in, and dynamically instantiating a class instance of at least one of the listed classes. Furthermore, the process includes dynamically resolving the listed dependent components, and dynamically loading the plug-in.

Implementations may include one or more of the following features. For example, the process may include dynamically re-loading or unloading the plug-in during the runtime of the application, such as by un-resolving the listed dependent components and de-instantiating the class instance. The interface may be an Application Programmable Interface (API). Instantiating the class instance may further include instantiating first and second class instances of the at least one of the listed classes, where the first and second class instances are isolated at a component instance level. The first and second class instances may be instantiated using first and second class instance factories, respectively, where the isolated first and second class instances are non-identical despite the at least one of the listed classes being the same.

In further examples, the process may further include communicating, via the interface provided by the instantiated class instance, a request from the application to the plug-in to perform functionality provided by the dependent components, the request identifying the plug-in using a unique identifier or resource locator. The process may also include, during the runtime of the application, dynamically selecting the at least one of the listed classes based on a version of the interface, the application, or the dependent components, where the selected at least one of the listed classes is instantiated as the class instance.

In further examples, the manifest may further include an identifier or name of the plug-in, a version of the plug-in, a provider of the plug-in, information regarding a license of the

2

plug-in, a digital signature of the plug-in, and redirection information pointing to a location of the plug-in. The classes capable of providing the interface between the application and the plug-in are listed as class descriptors, where each class descriptor further includes an identifier or name of the class, a plain text description of a functionality of the class, information regarding a license of the class, a digital signature of the class, and redirection information point to a location of the class. Resolving the listed dependent components may further include pre-loading or caching the listed dependent components, where the plug-in may be loaded based on instantiating the class instance and further based on resolving the listed dependent components. At a compile-time of the plug-in, the program code of the host application may not reference dependent components of the plug-in.

According to another general implementation, a device includes a processor configured to, during a runtime of an application, dynamically access, for a plug-in invoked by the application, a manifest listing classes capable of providing an interface for the plug-in, and dependent components that provide functionality to the plug-in, and to instantiate a class instance of at least one of the listed classes. The processor is further configured to resolve the listed dependent components, and to load the plug-in.

According to a further general implementation, a computer program product is tangibly embodied in a machine-readable medium. The computer program product includes instructions that, when read by a machine, operate to cause data processing apparatus to, during a runtime of an application, dynamically access, for a plug-in invoked by the application, a manifest listing classes capable of providing an interface for the plug-in, and dependent components that provide functionality to the plug-in, and to dynamically instantiate a class instance of at least one of the listed classes. The computer program product also includes instructions that operate to cause the data processing apparatus to, during a runtime of an application, dynamically resolve the listed dependent components, and to dynamically load the plug-in.

The details of one or more implementations are set forth in the accompanying drawings and the description, below. Other potential features and advantages of the disclosure will be apparent from the description and drawings, and from the claims.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram of an exemplary system that implements the dynamic resolution of dependent components of a plug-in.

FIG. 2 is a flowchart illustrating an exemplary process for dynamically resolving dependent components of a plug-in.

FIG. 3 is a contextual diagram illustrating the dynamic resolution of dependent components of a plug-in, in operation.

FIG. 4 depicts the exterior appearance of an exemplary system.

FIG. 5 is a block diagram illustrating the internal architecture of the device shown in FIG. 4.

Like reference numbers represent corresponding parts throughout.

DETAILED DESCRIPTION

The enhanced approach technique described herein effects the resolution of plug-in dependencies and the selection of an interface between the host application and the plug-in during the runtime of a host application, using meta information

3

stored in a manifest associated with the plug-in. In this manner, the plug-in may be dynamically loaded, unloaded, and/or re-loaded by the host application, without requiring the program code of the host application to reference dependent components of the plug-in.

Such an approach allows plug-ins to become more complex and adaptable, and to incorporate an increasing number of third party components which can be managed at runtime. In doing so, a tool kit is provided for selecting, resolving dependencies of, and loading plug-ins at runtime, to thereby add desired functionality to a host application, providing a significant enhancement over other technologies which merely address dependency resolution during compile-time of the plug-in.

As used herein, a ‘dependency’ relates to any reference to an external entity or dependent component, such as via a Universal Resource Locator (URL). A dependency may also relate to the extemal entity or dependent component itself. As such, resolution of dependencies may occur or may be required to occur prior to achieving full functionality of a particular plug-in. The enhanced approach described herein may provide for explicit and complete resolution of any dependencies.

Further, ‘compile-time’ (as contrasted with ‘runtime’) refers to operations performed by a compiler, or requirements that must be met by source code for an operation to be successful. Compile-time generally occurs prior to link time and runtime. In a similar vein, runtime refers to the time after compile-time when an application is loaded, executed or otherwise invoked. Moreover, ‘dynamic’ operations pertain to operations that occur with or during computer program execution, as contrasted with ‘static’ operations that occur without computer program execution.

FIG. 1 is a block diagram of an exemplary system 100 that implements the dynamic resolution of dependent components of a plug-in. The system 100 includes a host application 101 and a plug-in 102 that communicate via an interface 104. The host application 101 includes a socket 105 into which plug-in 102 “plugs-in,” or provides particular functionality, and a tool kit 106.

The host application 101 may further implement middleware, such as the SUN MICROSYSTEMS® JAVA® or MICROSOFT .NET® virtual environments. The plug-in 102 represents any runtime component that may be plugged into or dynamically integrated with an application framework. Runtime components are generally compiled in a format to be used in a runtime environment, such as machine code to be executed on a certain hardware platform or intermediate code (such as MICROSYSTEMS® JAVA® bytecode or MICROSOFT® Common Intermediate Language (CIL)) to be executed in a virtual environment. Altematively, runtime components may represent scripts that run using interpreters.

The plug-in 102 may be accessed by the host application 101 via predefined interfaces or APIs located in a program library that can be referenced by a unique identifier or resource locator. The tool kit 106 includes a component loader 107 that loads a given set of plug-ins, and that creates a single component instance of each dependent component of the plug-in, as referenced by a unique identifier or resource locator.

The component loader 107, which may be instantiated as a singleton, supports a load component (LoADCorvl1>oNENT(URI)) functionality, an unload component (UNLoADCorvl1>oNENT (URI)) functionality, and a find components (r1NDCorvl1>oNENTs (interface)) functionality. When executed, LOADCOMPONENT (URI) (where URI refers to a manifest of a component to be loaded) creates and stores a single COMPONENTIVIANIIEST

4

instance of the plug-in 1 02 in the component loader 1 07 under the corresponding URI. With the invocation or execution of LoADCorvl1>oNENT(URI), a pre-loading/caching process for dependent components of the plug-in 102 may be triggered.

When executed, UNLoADCorvl1>oNENT(URI)) unloads the plug-in 102, in which case some or all references to the plug-in 102 and its respective instantiated classes are removed. After unloading, the plug-in 102 may again be re-loaded or updated using cache invalidation. When executed, r1NDCorvl1>oNENTs(interface)) selects plug-ins that, for the given interface 104 used by the host application 101, may communicate with the given interface 104, by returning a list of appropriate manifests (or COMPONENTIVIANIIEST instances).

The tool kit 106 further includes a manifest 109 (the “component manifest” or the COMPONENTIVIANIIEST class), and at least one class instance factory 110 that each create a single class instance. The COMPONENTIVIANIIEST class represents a plug-in, as described by a manifest. With each COMPONENTMAN1rEsT instance the manifest document is accessed, a single instance of a CLASSINSTANCEFACTORY is created, and list of CLASSIVIANIIEST instances is created and stored.

In addition to providing access to the manifest, the COMPON1ENTl\/IANIIEST class provides a get classes (GETCLAssEs( )) functionality, a find classes (r1NDCLAssEs(interface)) functionality, and a check signature (cr1EcKS1GNATURE(public key token)) functionality. When executed, GETCLAS sEs( ) returns a complete list of CLASSIVIANIIEST instances; r1NDCLAssEs(interface) performs a selection among the complete list of CLAssMAN1rEsT instances based on an IMPLEMJENTSINTERFACE function and retums a list with the selected instances; and cr1EcKS1GNATURE(public key token) checks the digital signature of an associated component.

By default, instance creation is delegated to a class instance factory (or CLASSINSTANCEFACTORY class) associated with the component, where each instance of a class includes a reference back to the class. Each class includes a fully qualified name associated with its respective class instance factory, such that two class instances created from different instance factories are easily distinguishable.

The CLASSINSTANCEFACTORY class is an inner or nested class of the CoMPoNENTMAN1rEsT class, and provides an abstraction layer above the underlying middleware instance factories. Dependencies that have been extracted by the COMPONENTMAN1rEsT class are pre-loaded into a cache for fast access. The complete resolution of all classes may be based on the complete pre-loading of all dependencies, disregarding resolution strategies provided by the underlying middleware.

Class instances created by a particular instance of the CLASSINSTANCEFACTORY class are isolated at the component instant level from class instances created by other CLAssINSTANCEFACTORY class instances, such as by isolation from other components. The CLASSINSTANCEFACTORY class provides get class (GETCLAss(class name)) functionality which, when executed, retums an indicated, named or referenced class.

The manifest 109 itself includes at least one class descriptor 111 (or “class manifest,” or CLASSIVIANIIEST class) that provides meta information on a particular class, where a look-up of an appropriate class descriptor is provided for the given interface 104 or API. The manifest 109 may be an XML document collocated with the plug-in 102, listing those classes that implement particular interfaces, and that also identifies, references, or otherwise lists dependent components of the plug-in 102. The manifest 109 may be accessible via a universal resource identifier (U RI).

The CLASSIVIANIIEST class may be an inner or nested class of the COMPONENTIVIANIIEST class, and may represent the data

5

given in the manifest. On construction of an instance of this class, a middleware dependent class or type representation associated with the name given in the manifest is created and stored by calling GETCLASS functionality associated with a given CLAssINsTANcEFAcToRY class.

The CLASSIVIANIIEST class provides an implements interface (IMPLEMJENTSINTERFACE(1I1I€I'f2lC€)) functionality, a create instance (cREATEINsTANcE( )) functionality, and a check signature (CH]ECKSIGNATU'RE(p1.1IJl1C key token)) functionality. When executed or otherwise invoked, ]1\/lIPLEM]ENTSINTERFACE(1I1I€I'— face) retums true or false depending on whether the class implements the interface 104; CREATEINSTANCE( ) creates an instance of the associated class; and CH]ECKSIGNATURE(p1.1I3l1C key token): checks the signature of the class. Put another way, the implements interface functionality allows for a matchmaking to occur between classes stored within the class manifest and interfaces supported by the host application 101.

The plug-in 102 includes at least one socket 112 (illustrated as sockets 112a to 112n, where n represents any integer), into which, when dependencies are resolved, dependent components such as library 114, component 115, plug-in 116, files, or any other collections of data are similarly plugged-in. During runtime, the plug-in 102 and its dependent components are accessible without locking.

The host application 101 may support the plug-in 102 for many reasons, including enabling third party developers to create capabilities to extend an application, reducing the size of an application, and separating source code from the application because of incompatible software licenses. If the source code of the dependent component is available, the tool kit 106 may create a compiled version of the dependent component during the resolution of dependencies.

The plug-in 116 may itself include a socket 117 referencing an external component that is resolved during or prior to the runtime of the plug-in 102. Put another way, the plug-in 102 may host plug-in 116, and the plug-in 116 may host a further plug-in. The resolution of the dependency created by the socket 117 may be dynamically resolved in a similar manner to the resolution of the dependencies created by the at least one socket 112.

By virtue of their advantages, plug-ins such as plug-in 102 are adaptable, and may be easily applied in many software architectures. Unlike plug-ins which use a static dependency resolution approach, in which all dependent components are bundled at compile-time and then shipped as a whole to the target runtime environment, the enhanced approach described herein provides for the dynamic resolution of dependencies at runtime. Such an approach is particularly useful for modem Service Oriented Architectures (SOAs), in which the target runtime environment of a ho st application, in particular large scale business applications, may no longer include a single entity or service, but rather may be distributed over several entities or services.

As such, the dynamic resolution of plug-in dependencies follows the paradigm of modularization and reusability that affects the runtime environment by modularizing and reusing program libraries used by the plug-in as well. Enhanced modularization as well as the increased variety of third party tools used in modern projects can be provided despite an increased number of external dependencies in relation to a particular development project. In this regard, the dependent component of a plug-in may be a third-party dependent component, as well as a dependent component developed by distributed teams from within the same organization.

FIG. 2 is a flowchart illustrating an exemplary process 200 for dynamically resolving dependent components of a plugin. Briefly, the process 200 includes, during a runtime of an

6

application, dynamically accessing, for a plug-in invoked by the application, a manifest listing classes capable of providing an interface for the plug-in, and dependent components that provide functionality to the plug-in, and dynamically instantiating a class instance of at least one of the listed classes. Furthermore, the process includes dynamically resolving the listed dependent components, and dynamically loading the plug-in. In each case where a dynamic operation is described, a static operation may be substituted where appropriate.

In more detail, process 200 begins when a runtime of an application occurs (S201). For a plug-in invoked by the application, a manifest listing classes capable of providing an interface for the plug-in, and dependent components that provide functionality to the plug-in is dynamically accessed (S202). The interface may be anAPI that supports requests for services made between the plug-in and the host application, or any other type of interface, where each class describes rules by which an interface behaves.

A class instance is created or “instantiated” from a given class, and providing functionality to the enacting runtime, describing how interaction between the plug-in and host application may occur. The identity of the dependent components of the plug-in may not be identified in the code of the host application.

During the runtime of the application, the at least one of the listed classes may be dynamically selected based on a version of the interface, the application, or the dependent components, where the selected at least one of the listed classes is instantiated as the class instance. In such a case, the plug-in may be devised to support polymorphism, versioning and life cycle management. For instance, the same API can have variations in its implementation depending on certain state parameter, requiring dynamic updates.

The manifest may further include an identifier or name of the plug-in, a version of the plug-in, a provider of the plug-in, information regarding a license of the plug-in, a digital signature of the plug-in, and redirection information pointing to a location of the plug-in. Table 1, for instance, identifies certain data stored within a manifest COMPONENTl\/IAN]IESTTYPE, and provides descriptions of the identified data.

ID The identifier or name of the plug-in.

VERSION The version of the plug-in. The combination of ID and VERSION provides a fully qualified name.

CLASSMANIFEST One or more elements oftype
CLASSMANIFESTTYPE.

DEPENDENCY Zero or more references pointing to an extemal
entity or other dependent component. The reference
may be universal (via a URL or URI) or relative
to the location ofthe manifest.

DESCRIPTION Plain text description of the plug-in.

PROVIDER The provider of the plug-in

LICENSEINFO Information regarding the license of the plug-in, including terms and conditions of use.

SIGNATURE The digital signature of the plug-in, for example the signature of the archive file that can be verified on download.

LOCATION A redirection that points to the location of the