Plug-in configuration manager

[0001] This application claims priority to U.S. Provisional Patent Application No. 60/377,341, filed May 2, 2002, entitled “PLUG-IN CONFIGURATION MANAGER,” which is hereby incorporated herein by reference.

[0002] A portion of the disclosure of this patent document contains material which is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document of the patent disclosure, as it appears in the Patent and Trademark Office patent file or records, but otherwise reserves all copyright rights whatsoever.

[0003] The following applications are cross-referenced and incorporated herein by reference:

[0004] U.S. patent application Ser. No. 10/404,552 filed Apr. 1, 2003 to Michael Blevins and entitled, “COLLABORATIVE BUSINESS PLUG-IN FRAMEWORK”;

[0005] U.S. patent application Ser. No. 10/404,684 filed Apr. 1, 2003 to Michael Blevins and entitled, “SYSTEMS AND METHODS FOR BUSINESS PROCESS PLUG-IN DEVELOPMENT”; and

[0006] U.S. patent application Ser. No. 10/404,296 filed Apr. 1, 2003 to Michael Blevins and entitled, “SYSTEM AND METHOD FOR COLLABORATIVE BUSINESS PLUG-INS”.

[0007] The present invention relates to the synchronized configuration of plug-ins on servers in a cluster.

[0008] In existing business process management (BPM) systems, flaws exist in the mechanisms used to propagate the actual runtime space of a plug-in manager across a cluster. Plug-ins on the cluster do not each experience the same life cycle. A plug-in configuration manager, such as a singleton stateless session bean, is typically pinned to a single server in the cluster. The configuration manager maintains the state of all plug-ins configured within a BPM system, and any configuration changes can be propagated from this manager to any other server in the BPM system. Since the configuration manager is held on a single server in the cluster, however, the configuration manager represents a single point of failure within the application.

[0009] Systems and methods in accordance with embodiments of the present invention can be used to manage the configuration of plug-ins across a cluster. A global management JavaBean (MBean) can be used to store the current plug-in information for the cluster as an attribute of the MBean. The global MBean can thereby provide cluster-wide access to this attribute, and can broadcast changes to the configuration as notifications to each server in the cluster. A plug-in manager can reside on each server in the cluster, and can have a notification listener capable of receiving the notifications from the global MBean. Each plug-in manager can execute the configuration changes on the server containing the plug-in manager in response to a notification.

[0010] A plug-in manager can exist once in a cluster, which can first execute a change to the current plug-in configuration, such as on a master server, and can direct the global MBean to broadcast the change to each plug-in manager. The global MBean and plug-in configuration manager can be migratable throughout the cluster. A persistent data store can be used to hold plug-in configuration information that the global MBean can use if the global MBean needs to obtain state information, such as when a new MBean is created. Changes executed by the plug-in configuration manager can include the loading, unloading and configuration of plug-ins.

[0011] Other features, aspects, and objects of the invention can be obtained from a review of the specification, the figures, and the claims.

[0016] Systems and methods in accordance with embodiments of the present invention can utilize a plug-in framework to design, execute, and monitor business processes, as well as to administer related data with an integration system. Components of such a framework, which can be provided by an integration system, for example, can include components such as a process engine or business process management (BPM) server, an integration studio or design client, and a worklist or run-time management client.

[0017] In addition to design and run-time management clients, a user can create custom clients to manage business processes, and/or enhance an existing set of user interface features using a BPM API. A BPM API can be used to create custom configuration, design, run-time management, and monitoring clients. FIG. 1 illustrates an exemplary BPM processing model that can be used in accordance with one embodiment of the present invention.

[0018] Such a BPM processing model can depend on the integration process engine 100, which serves as the controller for run-time instances, managing the execution and monitoring the progress of those instances. Certain methods can allow a user to start, or instantiate, a business process and interact with an existing business process. Such methods can include methods called: in response to an XML event 102, as a time-based event 104, through a manual call 106, through a call from another business process 108, or through a plug-in interface 110.

[0019] Certain entities can be integrated into a business process, such as a JMS application 112, EJB component 114, Java class 116, or another application 118. The database store 120 stores templates, template definitions, and run-time instances, such as in a template store 122 or instance store 124. A user can create templates and template definitions, and can monitor run-time instances using a studio or custom design client.

[0020] FIG. 2 illustrates an exemplary BPM plug-in framework 204 that can be used within an the overall BPM architecture. A server 216, which can include EJBs 218, 220, 222, can manage the deployment of the BPM and plug-in EJBs 206, 208. To make a plug-in available to BPM users, the user can simply deploy the plug-in as a session EJB on the server. The plug-in can be deployed as part of the integration application, such as by editing the config.xml file. A BPM plug-in manager 210 can store plug-in configuration information in an integration database store 214. An external application 200 can interact with the process engine via an XML event or nonXML event. NonXML events can be supported via the plug-in framework 204. An event processor 212, which can be part of a standard framework 202, can manage both XML and non-XML events.

[0021] The main components of a plug-in framework 204 can include a plug-in manager 210, which supports the management of plug-ins 206, 208 and a plug-in API, which supports the design and development of plug-ins. The plug-in manager 210 can be a dedicated part of an integration process engine 242 that supports the configuration, design, and run-time management of plug-ins. The plug-in manager 210 can oversee the loaded plug-ins and their interactions with the integration process engine and BPM clients 224, 226, and can route all plug-in related requests. Requests can be routed to plug-ins in the studio 228. The studio 228 can contain plug-ins to handle, for example, plug-in functions 230, plug-in events 232, plug-in starts 234, plug-in dones 236, plug-in functions 238, and plug-in variable types 240.

[0022] An integration process engine can run on a platform, such as WebLogic Server from BEA Systems of San Jose, Calif., and can take advantage of services such as J2EE-compliant services. One such service that can be used by BPM is an Enterprise JavaBean (EJB). An EJB can provide lifecycle management and services such as caching, persistence, and transaction management. The process engine can consist of a combination of session and entity EJBs. In addition, message-driven beans can be used for providing asynchronous messaging services. A plug-in framework can support the development and deployment of plug-ins into a system.

[0023] A plug-in can consist of a set of run-time loadable Java classes that can extend system functionality, such as the business process management functionality of an integration system. Developers can use a plug-in framework to integrate other products and technologies into the integration environment. Developers can also use plug-ins to modify the default design-time or run-time behavior of workflow components.

[0024] A plug-in API can be used to provide support for configuration, design, and run-time interactions between a process engine and a deployed plug-in. An exemplary plug-in API can consist of two session EJBs, a set of run-time management classes, and a package. A plug-in manager can be a stateless session EJB that provides run-time management of plug-ins. A plug-in manager can provide meta-data about the deployed plug-ins, enable access to plug-in design and run-time components, and handle event notifications to and from plug-ins.

[0025] A plug-in manager configuration EJB can also be used, which can be a stateless session EJB that provides configuration and design management of plug-ins. Such an EJB can maintain plug-in configuration information, manage the plug-in framework cluster-wide state transitions, and maintain a list of plug-ins that are registered for the system event notifications. Plug-in classes can also be used to provide run-time management of plug-ins during workflow execution. A common plug-in package can provide client and process engine functions, including value object classes. All members of this package can be serializable to allow for exchanges between the client and process engine.

[0026] A session bean can go through various stages during a life cycle, which can be managed by a bean container, for example. The life cycle of a bean can be useful for managing resources such as database connections. A client or application can initiate a life cycle by invoking a ‘create’ method on the container, which can instantiate the bean and invoke the necessary methods in the session bean, making the bean ready to have its business methods invoked. The container can passivate a bean by moving it from memory to a secondary storage. If a client invokes a business method on the bean while the bean in a passive stage, the container can reactivate the bean, returning the bean to a ready state. At the end of a life cycle, the client can invoke certain methods on the container. An ejbCreate method, for example, can be used to perform certain operations after a bean is instantiated, such as connecting to a database. Because presently a stateless session bean is never passivated, its life cycle can have just two stages, including ‘non-existent’ and ‘ready.’

[0027] A Common Management Model (COMMO) framework can be used to implement this functionality. COMMO provides the ability for one node on the cluster to effect a change in a configuration, and to broadcast a notification of that change to every other node on the cluster. The other nodes on the cluster can then replicate the change, performing the same operation locally. In other words, there can be a master server that allows for the loading and unloading of plug-ins, as well as the reconfiguration of these plug-ins. This work can be first accomplished on the master server, then replicated out on the other servers in the cluster. The master server can be either a designated server in the cluster, or can simply be the server that first received the request to change state. In the latter case, the master and managed servers can change for each request.

[0028] A COMMO framework can provide the ability to store the current configuration as an attribute of a global MBean. Systems and methods in accordance with embodiments of the present invention can utilize a Management JavaBean, or MBean, to ensure that nodes in a cluster are synchronized. An MBean can be the instrumentation of a resource in compliance with the Java Management eXtensions (JMX) specification, as set forth by Sun Microsystems of Santa Clara, Calif. A resource such as a Java application can be its own MBean, while an MBean can be thought of as a Java “wrapper” or Java representation of other resources or devices. When the nodes are synchronized, anything that happens to one of the plug-ins can happen to the other plug-ins at the same time, or at approximately the same time. While this benefit might not be apparent to an end user, there is certainly a benefit to somebody developing a plug-in as the developer can depend upon a life cycle. A global MBean can be accessible directly to any new servers that join the cluster, as well as to any existing servers that may need to obtain state information. COMMO can also be used to provide the ability to broadcast a notification of a state change.

[0029] In present systems the life cycle is different, as a singleton stateless session bean can be used to function as the plug-in configuration manager. The stateless session bean can be pinned to a single server in the cluster. In accordance with certain embodiments of the present invention, the responsibility for propagating the state changes can be designated to the plug-ins and plug-in managers themselves. This approach would not have worked in present systems, as present systems lack the underlying facilities to support such an approach. This has not been a major issue for present systems, as most components have not been clusterable. Now that all components can be clusterable, it can be desirable, and in some instances necessary, to change the way in which the system works.

[0030] A JMX notification listener can be part of each plug-in manager. Each server that enters a cluster can locate the global MBean that will provide the server with the current plug-in configuration. The global MBean can also provide the server with notification state changes. A notification listener can be implemented using a COMMO framework, with the system acting as a client to that service.

[0031] The service can enable the plug-in configuration manager to make a remote call to each of the other managed servers. This call can be described, for example, in regard to the system of FIG. 3. A client 300 can make a request for state change into the cluster 302, which can be received by a master server 304. The master server can be a designated cluster master, or can simply be the server that receives the request. A plug-in configuration manager 306 can direct the change to occur on the master server 304, which change can consist of the loading, unloading, or configuration of a plug-in. The configuration manager 306 can then direct the global MBean 308 to update the state in the MBean attribute holding the plug-in configuration state.

[0032] The plug-in configuration manager 306 and global MBean 308 can be migratable MBeans that can exist on any node in the cluster. The plug-in configuration manager 306 can direct the global MBean 308 to broadcast a notification of the change to each managed server 310, 314 in the cluster 302. This call can inform the other servers that a plug-in has been loaded, unloaded, or reconfigured, for example. When the managed servers 310, 314 receive such a notification, the servers can each execute the same command locally. This local execution can be directed by a plug-in manager 312, 316 on each server. This approach can help to keep the plug-ins synchronized on each of the servers.

[0033] From the point of view of services that are available to the clients of the cluster, the cluster is homogeneous and each node is equivalent. This synchronization can be guaranteed. If there is a communications error or system failure, for example, the framework can continue to attempt to notify the servers. As long as the servers are running and available, the nodes can remain synchronized. If a managed server goes down and comes back up, such an MBean framework can provide the functionality for the server to re-synchronize, such that the server will be completely in step with the other servers.

[0034] The broadcast that goes out for a failed node does not have to include a history of state changes. Rather than retrieving all the lost notifications in sequence, it is possible to simply retrieve the current state in a single call. This single notification can also be used for a node that is just joining the cluster. An approach that can be used in such a situation is shown in FIG. 4. A request can be received, such as from a client, to change the plug-in configuration state of the cluster 400. The plug-in configuration can be changed on a master server in the cluster using a plug-in configuration manager 402. The configuration state change can be stored as an attribute of a global management bean, such as may be resident on the cluster master 404. A notification, which can contain any of the change-related information discussed above, can be broadcast from the global management bean to each managed server in the cluster 406. The global management bean can be aware of any new servers being added to the cluster that should receive notifications. The configuration change can then be made on each managed server, such as by the plug-in manager on each server 408. If a new server is brought into the cluster, the notification that is broadcast can contain the entire configuration state instead of just the change. Alternatively, a separate notification can be sent to the new server that contains the entire configuration.

[0035] In systems and methods in accordance with one embodiment, JMX can be used to write the plug-in configuration manager as an MBean that can implement a specific interface and conform to certain design patterns. Since an MBean is being used, the server can become responsible for the propagation of changes. The configuration manager can also be designated as a run-once service. This designation can allow for automatic fail-over in the case of a crash, and can ensure that only a single version of the configuration manager exists in the cluster. The existence of a single configuration manager can prevent inconsistent states between servers.

[0036] Using such a COMMO MBean framework, a new non-persistent MBean can be defined that can maintain the cluster-wide plug-in and plug-in manager state, and can broadcast delta notifications to all managed servers whenever the state changes. The state itself can be held in a single object, such as a ‘PluginManagerState’ object, and can be available from the MBean via a ‘PluginManagerState’ attribute. The state can describe which plugins are currently loaded, as well as the configuration data for these plug-ins.

[0037] When a managed server boots, the server can create an MBean if one does not already exist, retrieving the static plugin configuration from a persistent store, such as through JDBC, and setting a state attribute such as “PluginManagerState” for the MBean. If the MBean already exists, the managed server can connect to the existing MBean and retrieve the dynamic plug-in configuration. In either case, the MBean can register as a JMX notification listener with a local MBean server. The server can then load the same plug-ins as are loaded on the other nodes in the cluster, using the same plug-in configuration data.

[0038] A plugin configuration manager bean, such as “PluginManagerCfg”, can still be pinned to a single node of the cluster, but can be implemented as a migratable service. This bean can support dynamically changing the plugin configuration, including changes such as loading a plug-in, unloading a plug-in, setting the configuration for a plug-in, and deleting the configuration for a plug-in.

[0039] After servicing any of the above requests, the plugin configuration manager can call the MBean to broadcast, to the other nodes in the cluster, a JMX notification containing the delta. The notification can contain the entire state or simply the change of state. Upon receiving a notification, the plug-in manager on each server can follow suit and execute the same configuration command locally. Thus, plug-ins can maintain an identical state and configuration on all servers. JMX notifications can be propagated synchronously.

[0040] The foregoing description of preferred embodiments of the present invention has been provided for the purposes of illustration and description. It is not intended to be exhaustive or to limit the invention to the precise forms disclosed. Many modifications and variations will be apparent to one of ordinary skill in the art. The embodiments were chosen and described in order to best explain the principles of the invention and its practical application, thereby enabling others skilled in the art to understand the invention for various embodiments and with various modifications that are suited to the particular use contemplated. It is intended that the scope of the invention be defined by the following claims and their equivalence.