Implementing multiple versions of a plug-in concurrently

A system and method for implementing multiple versions of a plug-in concurrently are provided herein. The method includes identifying a plug-in within a multi-plug-in platform that is configured to provide a desired functionality. The method also includes executing a first version and a second version of the plug-in concurrently to provide the desired functionality, wherein each version of the plug-in is isolated from the other version of the plug-in.

BACKGROUND

A plug-in is a set of software components that may be used to extend or customize the functionalities of a software application. For example, a plug-in may be used to integrate new content into an existing application. However, application environments typically only allow a single instance of a plug-in to be integrated at a time. In many cases, it may be desirable to replace an existing version of a plug-in with a new version of the plug-in. In such cases, if the application environment only supports one instance of a plug-in at a time, the new version of the plug-in may immediately replace the existing version of the plug-in in the application environment. Thus, the entire application environment may be exposed to the new version of the plug-in without proper testing of the new version of the plug-in.

DETAILED DESCRIPTION OF SPECIFIC EXAMPLES

Techniques described herein relate generally to the implementation of multiple instances of a plug-in concurrently. More specifically, techniques described herein relate to a multi-plug-in platform that is configured to execute any of a number of different versions of a plug-in concurrently to provide a desired functionality. This may be accomplished by isolating each version of the plug-in from all other versions of the plug-in.

The techniques described herein may allow for proper testing of a new version of a plug-in prior to implementation of the new version of the plug-in within an entire computing environment. For example, an existing version of a plug-in may be executed in one region of a computing environment, while a new version of the plug-in may be tested in another region of the computing environment. Once it has been verified that the new version of the plug-in provides a desired functionality, the new version of the plug-in may replace the existing version of the plug-in throughout the entire computing environment. Alternatively, the new version of the plug-in may be exposed in a controlled manner by slowly migrating portions of the environment from the existing version of the plug-in to the new version of the plug-in. Thus, the new version of the plug-in may be tested in a controlled manner without posing a significant risk to the computing environment.

FIG. 1is a block diagram of a computing device100in which a multi-plug-in platform102may be implemented. The computing device100may be any type of computing device that is capable of implementing the procedure described herein for executing multiple versions of a plug-in104concurrently. For example, the computing device100may be a laptop computer, desktop computer, tablet computer, mobile device, server, or the like.

The computing device100may include a central processing unit (CPU)104that is adapted to execute stored instructions, as well as a memory device108that stores instructions that are executable by the CPU106. The CPU106can be a single core processor, a multi-core processor, a computing cluster, or any number of other configurations. The memory device108can include random access memory (RAM), read only memory (ROM), flash memory, or any other suitable memory systems. The instructions that are executed by the processor104may be used to implement a method that includes identifying a plug-in104within the multi-plug-in platform102that is configured to provide a desired functionality and executing two or more versions of the plug-in104concurrently to provide the desired functionality.

The computing device100may also include a storage device110. The storage device110can include a hard drive, an optical drive, a thumbdrive, an array of drives, or the like. The storage device110may be configured to store any number of applications112A. The applications112A may include any types of modules or programs that are configured to perform one or more specific functions. In addition, according to the techniques described herein, an application112A may utilize one or more plug-ins104provided by the multi-plug-in platform102to provide a desired functionality that is not supported by the application112A itself, as discussed further below.

The computing device100may be communicatively coupled to a user computing device114through a network (not shown). The user computing device114may include a CPU116, such as the CPU106discussed with respect to the computing device100. The user computing device114may also include a storage device118, such as the storage device110discussed with respect to the computing device100, that is configured to store any number of applications112B. The applications112B may include any types of modules or programs that are configured to perform one or more specific functions. In addition, according to the techniques described herein, an application112B may utilize one or more plug-ins104provided by the multi-plug-in platform102to provide a desired functionality that is not supported by the application112B itself, as discussed further below. In some cases, the desired functionality may be specified by a user of the user computing device114via a user interface120. In other cases, the desired functionality may be automatically determined by the application112B during execution of a specific task. Further, an application112A may communicate with another application112B using a plug-in104that encapsulates the protocol and libraries for communicating with the specific version of the application112B and is managed by the multi-plug-in platform102.

According to techniques described herein, the multi-plug-in platform102may allow for the execution of more than one version of a plug-in104within the same environment, e.g., within the same application112or computing device100or114, concurrently. The multi-plug-in platform102may accomplish this by ensuring that each instance of a plug-in104is isolated from all other instances of the plug-in104, as discussed further below.

The multi-plug-in platform102may receive a request for a plug-in104providing a desired functionality from an application112. Such a request may include, for example, a request for a plug-in that is configured to perform a specific task or provide the application112with specific data. In some cases, the request may also include parameters124relating to a specific provider126or a specific plug-in104that is desired by the application112, or parameters relating to the functionality that is desired by the application112. As used herein, the term “provider” refers to a service that provides the configuration for a specific instance of a connection to an application112.

A controller128within the multi-plug-in platform102may be configured to determine information relating to a suitable provider126for providing the desired functionality, as well as information relating to a suitable plug-in104provided by the provider126. The controller128may accomplish this by accessing one or more data stores130including information relating to the providers128and the plug-ins104that are supported by the multi-plug-in platform102. The one or more data stores130may be accessed by the controller128via a data access object (DAO) interface132based on data access objects (DAOs) identified from the parameters124received from the application112, for example. The DAO interface132may provide an abstract interface for mapping the request from the application112into DAOs containing references to specific portions of memory within the one or more data stores130.

The information relating to the provider126that may be obtained from the one or more data stores130may include an identification number of the provider126, a name of the provider126, a type of the provider126, plug-in reference numbers for plug-ins104provided by the provider126, parameters relating to the provider126, and the like. In addition, the information relating to the plug-in104that may be obtained from the one or more data stores130may include an identification number of the plug-in104, a name of the plug-in104, different versions of the plug-in104, a type of the plug-in104, and the like. The information relating to the plug-in104may also include a manifest file of the plug-in and a container of plug-in code, which includes a jar file or other archive format obtained from a plug-in archive133. In addition, metadata associated with the plug-in may be extracted from the plug-in archive133.

In some examples, a plug-in manager134within the multi-plug-in platform102stores the information relating to the plug-ins104in a cache (not shown). The plug-in manager134may also store all data returned from execution of the plug-ins104in the cache for future use. In addition, different computer languages for reading and writing the plug-ins104may be supported by the plug-in manager134.

Once the controller128has retrieved the information relating to the provider126and the plug-in104, the multi-plug-in platform102may use the information to implement multiple instances of the plug-in104concurrently. For example, the plug-in manager134may use the information to identify an adapter136for each version of the plug-in104that is to be implemented by the multi-plug-in platform102.

Each adapter136may then construct a class loader138for a corresponding version of the plug-in104using information obtained from the plug-in archive133. The class loader138may define the manner in which each version of the plug-in104will behave. In addition, the class loader138for each version of the plug-in may isolate the version of the plug-in104from all other versions of the plug-in104, thus allowing for the execution of multiple versions of the plugin104at the same time.

Once the class loader138for each version of the plug-in104has been constructed, the multi-plug-in platform102may execute two or more instances of the plug-in104, wherein each instance of the plug-in104includes a distinct version of the plug-in that supports a specific configuration. The specific configuration may include specific server parameters, host parameters, user parameters, connection parameters, or the like, supported by the plug-in104. The multi-plug-in platform102may then provide the desired functionality to the application112via the API122, for example.

In some cases, the computing device100or114hosting the application112may store data140relating to the execution of the multiple versions of the plug-in104, as well as data140relating to a state of execution of the plug-in104, within the storage device110or118. This may allow for easy execution of the plug-in104, or a plug-in104providing a similar functionality, in the future. For example, the data140may include plug-in metadata extracted from the plug-in archive133that identifies the functionalities that are supported by the plug-in104, as well as possible configurations supported by the plug-in104. Such metadata may be passed back to the multi-plug-in platform102at any point in time, and the multi-plug-in platform102may use such data140to identify or configure a new plug-in104that provides the same functionality as the original plug-in104. This may be useful for instances in which the original plug-in104has been modified or deleted. In addition, the data140relating to the state of execution of the plug-in104may be used to maintain the state of execution of the original plug-in104for an extended period of time, thus allowing the original plug-in104or a new plug-in104to resume execution beginning from the last saved state.

The multi-plug-in platform102may be managed by a user of the computing device100. The user may be, for example, a software developer or administrator. The computing device100may include a user interface142through which the user of the computing device100may manage the configuration and operation of the multi-plug-in platform102. For example, the user interface142may be a read-write user interface through which the user may manage the plug-in configurations by creating, reading, updating, or deleting configuration information. However, in some cases, the user of the computing device100may not have access rights to the multi-plug-in platform102, and the user interface142may be a read-only user interface through which the user can only load, reload, or delete plug-ins104, without altering the plug-in configuration information that was derived from the plug-in archive133, for example.

The multi-plug-in platform102may be an extensible environment. New adapters136and/or new class loaders138may be added to the multi-plug-in platform102during the release of a new version of a product. In addition, information relating to new plug-ins104may be uploaded to or updated within the data store130during runtime, and information relating to new providers126may be created or edited within the data store130at any point in time. Thus, the multi-plug-in platform102may be continuously adapted according to the functionalities requested by applications112.

The block diagram ofFIG. 1is not intended to indicate that the computing device100is to include all of the components shown inFIG. 1. Further, the computing device100may include any number of additional components not shown inFIG. 1, depending on the details of the specific implementation.

FIG. 2is a process flow diagram of a process200for determining a version of a plug-in104to be used to provide a desired functionality for an application112. Like numbered items are as described with respect toFIG. 1. The process200may be executed by the multi-plug-in platform102discussed above with respect toFIG. 1. In addition, according to techniques described herein, the two or more versions of the plug-in104may be executed concurrently within the multi-plug-in platform102without interfering with one another.

An application112may send a request for a plug-in that is configured to provide a desired functionality to the controller128within the multi-plug-in platform102, as indicated by arrow202. The request may include any accompanying parameters or data relating to the desired functionality. The controller128may query any of the one or more data stores130to identify the provider126and information relating to corresponding plug-ins104via the DAO interface132, as indicated by arrows204and206.

The controller128may send a request for an interface implementation, e.g., via the API122, of the identified plugin configuration to the plug-in manager134, as indicated by arrow208. The plug-in manager may identify a suitable plug-in104identified by the provider128using the DAO interface132. Once the plug-in104has been identified, a suitable adapter136may be determined based on an adapter type for the specific version of the plug-in104that may be read from the metadata associated with the plug-in104. The plug-in manager134may then delegate the task of configuring the plug-in104to the adapter136, as indicated by arrow210.

The adapter136for the plug-in104may construct a corresponding class loader138and delegate the resolution of the implementation of the plug-in104to the class loader138, as indicated by arrow212. The class loader138may construct and return an implementation of the API122, as indicated by arrow214, and return information relating to the implementation of the API122to the controller128. The controller128may execute the configured version of the plug-in104using the implementation of the API122via calls to the API122. In addition, the controller128may simultaneously execute any number of other versions of the plug-in104using the same procedure. For example, multiple versions of the plug-in104may be executed to provide the desired functionality for the application112. In some examples, the desired functionality provided by the multiple versions of the plug-in104may be delivered to the application112in the form of one or more Java Beans, which include a number of reusable software components or objects. Further, the class loader138for each version of the plug-in104may isolate the version of the plug-in104from all other versions of the plug-in104by preventing the public classes and interfaces of the version's embedded libraries from being visible to any other version of the plug-in104.

It is to be understood that the process flow diagram ofFIG. 2is not intended to indicate that the process200is to include all of the steps discussed above in every case, or that each step is to be executed by a particular component in every case. Rather, any number of steps may be added to or deleted from the process200, depending on the details of the specific implementation. In addition, any number of the components may be replaced with alternative components for performing the steps of the process200, depending on the details of the specific implementation.

FIG. 3is a process flow diagram of a method300for implementing multiple versions of a plug-in concurrently. The method300may be executed by the multi-plug-in environment102discussed above with respect toFIGS. 1 and 2. Multiple versions of the same plug-in may be implemented concurrently according to the method300in order to allow a software developer or administrator to manage the different versions of the plug-in, as well as the configuration of each version of the plug-in, on-the-fly. For example, the method300may allow for the testing of a new version of a plug-in within a particular computing environment without ceasing execution of an existing version of the plug-in within the computing environment. This may allow for the verification of the proper functioning of the new version of the plug-in at a relatively low cost, since the new version of the plug-in may not be implemented within the entire computing environment.

The method begins at block302, at which a plug-in that is configured to provide a desired functionality is identified within a multi-plug-in platform. The desired functionality may be, for example, any type of functionality requested by an application. More specifically, the desired functionality may be any type of functionality requested by a model element within a computing or networking environment, such as a standard application component, a custom application component, an infrastructure service template, or a custom workflow from an application.

The plug-in may be determined from a number of plug-ins within the multi-plug-in platform based on data and parameters relating to the desired functionality. In addition, in some cases, the plug-in may be determined based on an identified provider within the multi-plug-in platform. The provider may be identified based on the type of model element requesting the functionality. For example, if the model element is an infrastructure service template, an infrastructure template provider may be identified within the multi-plug-in platform. Then, a suitable plug-in provided by the infrastructure template provider may be identified.

At block304, a first version of the plug-in and a second version of the plug-in are executed concurrently to provide the desired functionality. Each version of the plug-in is isolated from the other version of the plug-in, and each version of the plug-in may support a different configuration. This may enable a software developer or administrator to manage multiple versions of the plug-in simultaneously.

The first version of the plug-in and the second version of the plug-in may be executed using input from the provider of the plug-in. In some examples, in order to enable execution of the plug-in, specific runtime parameters are provided to the provider. Such runtime parameters may be specific to the desired functionality that is to be provided by the plug-in. In other examples, standard parameters may be provided to the provider in order to enable execution of the plug-in. Such standard parameters may include a service access point, a user name, a password, or the like. In addition, a provider template definition may be loaded from a registration file or a programming interface. The provider template definition may define the connection parameters that will enable execution of the plug-in supported by the provider.

In some cases, an existing version of the plug-in and a new version of the plug-in may be executed concurrently. For example, the existing version may be implemented within a first segment of a computing environment, and the new version may be implemented within a second segment of a computing environment. It may be determined whether the new version provides the desired functionality. If it is determined that the new version provides the desired functionality, the new version may be implemented within the first segment, and execution of the existing version may be ceased. On the other hand, if it is determined that the new version does not provide the desired functionality, execution of the new version may be ceased, and the existing version may be implemented within the second segment. In this manner, new versions of the plug-in may be tested before being implemented within the entire computing environment.

According to the method300, an old version of the plug-in may be deleted if it has been verified that a new version of the plug-in is configured to replace the old version of the plug-in, or if a functionality provided by the old version of the plug-in is no longer desired. In addition, a new version of the plug-in may be reverted to an old version of the plug-in if it is determined that the new version of the plug-in does not provide the desired functionality. Further, in some cases, a state of execution of an old version of the plug-in may be maintained, and execution of a new version of the plug-in may be directed based on the state of execution of the old version of the plug-in.

It is to be understood that the process flow diagram ofFIG. 3is not intended to indicate that the steps of the method300are to be executed in any particular order, or that all of the steps of the method300are to be included in every case. Further, any number of additional steps not shown inFIG. 3may be included within the method300, depending on the details of the specific implementation. For example, any number of additional versions of the plug-in may also be executed concurrently to provide the desired functionality.

The method300may be used to provide various functionalities for any number of different applications. In some cases, the method300may be used for a catalog browsing application within a network environment. For example, the multi-plug-in platform102may identify any number of catalog providers that support plug-ins for selecting items from a catalog within a browsing window. The plug-ins may then be executed within the network environment via the multi-plug-in platform. The plug-ins may enable, for example, a user to select a number of items from the catalog within the browsing window via a user interface.

FIG. 4is a block diagram of a tangible, non-transitory, computer-readable medium400that stores a protocol adapted to implement multiple versions of a plug-in concurrently. The tangible, non-transitory, computer-readable medium400may be accessed by a processor402over a computer bus404. Furthermore, the tangible, non-transitory, computer-readable medium400may include code to direct the processor402to perform the steps of the current method.

The various software components discussed herein may be stored on the tangible, non-transitory, computer-readable medium400, as indicated inFIG. 4. For example, a plug-in identification and configuration module408may configured to identify data relating to a plug-in that provides a desired functionality, and configure two or more versions of the plug-in to be used to provide the desired functionality. In addition, a multi-plug-in execution module408may be configured to execute the two or more versions of the plug-in concurrently to provide the desired functionality.

It is to be understood thatFIG. 4is not intended to indicate that all of the software components discussed above are to be included within the tangible, non-transitory, computer-readable medium400in every case. Further, any number of additional software components not shown inFIG. 4may be included within the tangible, non-transitory, computer-readable medium400, depending on the details of the specific implementation.

The present examples may be susceptible to various modifications and alternative forms and have been shown only for illustrative purposes. For example, the present techniques support both reading and writing operations to a data structure cache. Furthermore, it is to be understood that the present techniques are not intended to be limited to the particular examples disclosed herein. Indeed, the scope of the appended claims is deemed to include all alternatives, modifications, and equivalents that are apparent to persons skilled in the art to which the disclosed subject matter pertains.