Deploying and distributing content management code

Deploying and distributing content management code is disclosed. A software object class is received at a repository. The software object class is stored at the repository. The software object class is downloaded from the repository to an application server associated with the repository.

BACKGROUND OF THE INVENTION

Content management systems have been provided that enable a developer to develop custom applications that use and/or access content stored in an associated content repository. An example of such a system is an application server on which a content management framework and/or platform has been installed. The framework/platform includes a set of reusable components each preconfigured to perform a content management function or operation that an application developer may desire his/her application to perform. However, from time to time the need may arise to update the set of components, e.g., to install and deploy new/updated components developed by the content management system/application vendor, to deploy custom components developed by a content management system user and/or a third party developer, and to ensure that two or more application servers deployed at different times are all using the same version of the components. Therefore, there is a need for an effective way to deploy and update content management code.

DETAILED DESCRIPTION

Deploying and distributing content management code from a repository is disclosed. In some embodiments, business logic (e.g., business object classes) and/or other code is registered with a repository. For example, in some embodiments, one or more business object classes comprising a content management framework are registered with a repository. The classes are stored in a content store and associated registration data is stored in a metadata store. Upon request from an application server, one or more business object classes are downloaded to the application server. As updates, if any, are registered at the repository, in some embodiments a change record in the repository is updated. An application server checks the change record periodically to determine if new/updated business object classes have been registered at the repository. In some embodiments, the change record is a global change record set to a value indicating that a new or updated class has been registered, without implicitly or explicitly identifying which classes have changed. In some embodiments, class (or collection of class, e.g., .jar) specific change records and/or flags or other indicator reflect whether individual classes have changed. In some embodiments, upon noting a change by reading a global change record, an application server iterates through the classes it has downloaded previously and/or otherwise needs and/or anticipates needing, checking for each the class and/or collection-specific change data/indicator, and downloading any classes that have changed since they were last downloaded to the application server. In some embodiments, new and/or updated classes are “hot deployed” without requiring that the application server be restarted. In some embodiments, hot deployment includes deploying an updated class and using the updated class to instantiate subsequently-requested instances of a business object while retaining the superseded class as long as it is still necessary, e.g., so long as at least one business object instance instantiated based on the superseded class is still actively being used (e.g., has at least one reference to it).

FIG. 1is a block diagram illustrating an embodiment of a system for accessing and using managed content. One or more clients, represented in the example shown inFIG. 1by client102and client104, communicate via a network106, such as a local area network (LAN), with an application server108, e.g., to access and use an application running on application server108. In some embodiments, application server108hosts one or more applications running on a content management framework or platform associated with managed content to which access is provided via a content system110. In the example shown, application server108communicates via network106with content system110to access and/or store content items associated with content system110. In some embodiments, content system110is configured to store and/or manage one or more logical repositories (e.g., document bases), each comprising an associated body of content items. In some embodiments, more than one application server108may be configured to access and/or use a single content system, such as content system110, and/or a single repository. In some embodiments, content system110comprises a single content server installation capable of being configured to host one or more content server instances, each content server instance being configured to support one repository. In some embodiments, a repository may be spread across multiple content server instances and/or installations, but each content server instance is associated with only one repository.

FIG. 2Ais a block diagram illustrating an embodiment of a content system. In the example shown, content system110includes a content server202configured to provide access to and/or store content items, e.g., files, database tables, etc., stored in content store206. In various embodiments, content server202and content store206reside on the same or different physical devices and/or systems, such as on separate servers or other computers. Content server202manages content items stored in content store206at least in part by associating with each of at least a subset of the content items stored in content store206corresponding metadata stored in metadata store204. In some embodiments, the metadata is stored in the form of one or more software objects configured and used to represent an associated content item within a body of managed content. Examples of metadata include content item owner, author, title, date created, date last accessed, version, content type, file or data format, authoring application, recipient, sender, relationship to other content item(s), keyword(s), etc. In some embodiments, content server202uses the metadata to manage (e.g., track) and provide managed access to associated content items, e.g., by executing and returning results for metadata and/or full-text index based queries and providing content management functions such as check-in/check-out, versioning, save, delete, etc.

In some embodiments, one or more objects to represent a content item in metadata store204are created by and/or in response to a request from an application running on an associated content management framework (e.g., foundation classes, business logic, and/or API). For example, an application may populate and/or provided data values for metadata object attributes and/or provide the associated content and/or indicate to the content server a location (e.g., on the application server and/or an associated client) where the content is located. The content server stores the content in content store206and associates the content as stored in content store206with the corresponding metadata in metadata store204.

FIG. 2Bis a block diagram illustrating an embodiment of elements associated with a content system. In the example shown, an implementation object222stored in metadata store204is associated with a corresponding content item224stored in content store206. The implementation object222represents the content item224in a body of managed content with which both are associated.FIG. 2Billustrates a simple example in which there is a one-to-one relationship between implementation object222and content item224, but in some embodiments a single implementation object (or related set of objects) may be associated with two or more content items and/or a single content item may be associated with two or more implementation objects (e.g., to avoid duplicative storage of content).

In some embodiments, access to content item224and/or other content management functions are provided at least in part by invoking one or more methods and/or using one or more attributes of implementation object222. In some embodiments, an application running on application server108ofFIG. 1invokes business logic on application server108to access or perform other operations with respect to content item224using one or more attributes and/or methods of implementation object222. For example, in some embodiments an application on application server108invokes business logic (e.g., a service) on application server108to perform a metadata-based search of content system110, e.g., to find content items that satisfy search criteria such as by author, date created, date modified, content type, document title, etc. Content system110searches metadata in metadata store204for implementation objects that satisfy the query, e.g., by checking attribute values of at least a subset of the objects, and returns results indicating any responsive content items. If the application receives an indication from a user that a particular result, such as content item224, is desired to be retrieved, the application invokes other business logic which in turn invokes one or more methods of and/or uses one or more attributes of implementation object222to retrieve content item224, e.g., a file or other object comprising content item224.

FIG. 3is a block diagram illustrating an embodiment of an application server. In the example shown, application server108includes one or more applications302running on a content management framework comprising a business object framework304and foundation classes306. The application(s) use(s) the business object framework304and/or foundation classes306to perform content management operations, such as storing, accessing, retrieving, organizing, searching for, checking in/out, and/or otherwise managing a body of content items using as applicable one or more software objects associated with business object framework304and/or comprising foundation classes306. In some embodiments, foundation classes306comprises a set of system objects configured to represent items of content in a repository such as content system110and to provide access to and control and management of such content. In some embodiments, application(s)302make calls to business logic software objects comprising and/or associated with business object framework304and/or foundation classes306, which instantiate and access runtime implementation objects on application server108and/or access persistently stored implementation objects stored on content system110, as applicable, to perform desired content management operations. In some embodiments, business object framework304comprises a set of reusable, preconfigured components available to an application developer to perform content management functions and/or operations.

FIG. 4is a block diagram illustrating an embodiment of an extensible business object framework. In the example shown, business object framework304comprises an extensible business object framework that includes four categories of business objects and/or logic, including services402, type based behaviors/objects404, aspects406, and modules408. In some embodiments, services402comprises a set of service based objects available across one or more repositories and to one or more application servers associated with one or more repositories. Examples of services include retention policy services configured to enforce one or more retention policies to content items, as applicable. In some embodiments, type based behaviors404define and provide behaviors that are determined by content type. An implementation object instantiated to represent in metadata a content item of a type having one or more content type based behaviors associated with it is configured to provide the type-based behavior(s). Type based behaviors may include type-based methods, e.g., one or more type-based methods that override default document behaviors (e.g., save, checkout, etc.) or add new type-specific behavior (e.g., adding a “spell check” action to a contract). In some embodiments, a base implementation object is instantiated and modified dynamically (in place) to configure the implementation object to provide the type-based behaviors. In some embodiments, aspects406comprises one or more behaviors that can be attached optionally to one or more implementation object instances, across and/or within content types. In some embodiments, an aspect may be attached at instantiation of the implementation object or at a later point in time. Examples of an aspect include retention policy enforcement. For example, linking a content item to a retention folder or “vault” in some embodiments causes a retention aspect to be attached. The implementation object representing the content item is modified to provide additional behavior to ensure proper retention, e.g., by preventing, modifying, or redirecting calls to a “delete” method of the implementation object. Finally, modules408in some embodiments include one or more business objects comprising business logic applicable to and available to be invoked with respect to a single document (or other content) repository or “docbase”, as opposed to being available across repositories, like a service. In some embodiments, type based behaviors404, aspects406, and modules408are extensible and an API is provided to enable third party developers to develop and deploy custom components.

From time to time the need may arise to update the object classes comprising a business object framework such as business object framework304. Examples of circumstances requiring such an update include deployment of new components developed by a content management system vendor or new custom components developed by a third party developer contracted by an enterprise or other user of a content management system; updates to correct software bugs, security flaws, or other problems with one or more business object classes; and the need to ensure consistency across multiple application servers deployed at different times.

In some embodiments, business logic and other software objects comprising a content management system and/or framework are deployed in and distributed from a repository, such as content system110. An application server, such as application server108, downloads needed business object classes from the repository, and instantiates a required business object using the locally stored class definition downloaded from the repository. In some embodiments, a base set of business objects is downloaded in connection with initial deployment and/or redeployment of an application server. In some embodiments, new and/or updated business object classes are downloaded as such new and/or updated business object classes become available and/or the need for such classes arises and/or is anticipated.

FIG. 5is a flow chart illustrating an embodiment of a process for deploying in a repository new/updated business object classes. At502, one or more new and/or updated business object classes and associated registration data are received. The registration includes metadata that enables the repository to associate a request to download a new/updated class with the corresponding class definition stored in the repository. At504, the new and/or updated class(es) are stored in the repository. In some embodiments,504includes storing business object classes that are desired to be available across multiple repositories, e.g., business objects associated with one more services comprising services402ofFIG. 4, are stored in a separate repository configured to store and make available for download to one or more application servers business logic objects applicable across repositories. Repository-specific business object classes are stored in the repository to which they relate. At506, a change record in the repository is updated. In some embodiments,506includes updating a data value or other indicator associated with the particular class(es) being added and/or updated. Logic at the repository and/or application server reads the data value to determine whether the associated class has been changed since last downloaded by the application server. In some embodiments,506includes updating a global change record. In some embodiments, the global change record comprises a timestamp, version stamp, flag, and/or other data indicating that at least one business object class has been added to and/or updated in the repository. In some embodiments, application server logic reads the global change record and if the value has changed since the application server last checked for updates to the business object classes downloaded by the application server previously the application server checks to see if any of the previously downloaded (and/or currently required classes) have been changed or added since the application server last checked for updates and/or originally downloaded the classes.

FIG. 6Ais a block diagram illustrating an embodiment of a change record. In the example shown, a change record602stored in metadata store204is configured to indicate whether and/or when one or more business object classes stored at the repository, e.g., in content store206, such business objects “BO1”, “BO2”, and “BO3” inFIG. 6A, and/or one or more collections of classes (e.g., .jar file), represented inFIG. 6Aby collection604, have changed. In some embodiments, each time one or more new and/or updated business object classes are registered at the repository, the change record602is updated, e.g., by writing a timestamp, version stamp, and/or other data to the change record.

FIG. 6Ba block diagram illustrating an embodiment of a global change record. In this example, change record602is updated whenever any one or more of a plurality of collections of object classes, represented inFIG. 6Bby collections604and606, and/or one or more components included in one or more such collections, change. In some embodiments, a separate collection and/or business object specific change record or indicator is store for each collection and/or class. In some embodiments, an application server polls the global change record relatively frequently, e.g., every thirty seconds or every minute, etc., and only polls the collection and/or object class specific change records and/or indicators in the event the global change record indicates a new/updated collection/class has been registered at the repository. In some embodiments, frequently checking the global change indicator and only checking for changes to individual collections/classes if the global indicator indicates a change of some sort has occurred enables the application server to check for updates in a computationally efficient manner, and to maintain up-to-date class definitions without constantly checking for updates each time a new business object is required to be instantiated.

FIG. 7is a flow chart illustrating an embodiment of a process for distributing business logic classes from a repository. In some embodiments, the process ofFIG. 7is implemented on a repository, such as content system110. At702, a request is received from a newly deployed or redeployed application server to download a base set of business logic classes. At704, a default, configured, configurable, and/or requested set of business logic classes is downloaded to the application server. At706, new/updated classes are downloaded to the application server as requested. For example, an application may request that a business logic class not included in the set of classes downloaded at704, e.g., the first time a need arises to instantiate an instance of the class, such as in response to an associated call from an application running on the application server, or an application server may request that a new or updated class be downloaded, e.g., to replace an older version downloaded previously.

FIG. 8is a flow chart illustrating an embodiment of a process for downloading business logic classes from a repository. In some embodiments, the process ofFIG. 8is implemented on an application server, such as application server108. At802, the download from a repository of business logic classes is requested. In some embodiments,802includes requesting an initial, base set of classes at the time of initial deployment or redeployment of an application server. In some embodiments,802includes requesting new and/or update classes, e.g., in response to receiving an indication that new and/or updated classes have been registered at the repository. In some embodiments,802includes requesting from a repository one or more business object classes associated with that repository and requesting separately from a shared repository one or more business object classes to be shared, at the application server, across repositories, such as service object classes comprising services402ofFIG. 4. At804, downloaded classes are stored locally, e.g., a local cache (e.g., local file or other container or path), on the application server. Application servers configured to access more than one repository in some embodiments download for each repository, from that repository, a set of business object classes to be used in connection with the repository. For each repository, a repository-specific set of business object classes (e.g., type based objects, aspects, modules, etc.) is stored on the application server in a subdirectory associated with that repository. Objects to be shared across repositories are stored in a shared subdirectory or path. At806, as requests (implicit and/or explicit) requiring that one or more business objects be instantiated are received, the requests are served by using a corresponding class definition stored locally to create the required instance(s). In embodiments, if at806it is determined a required class was not downloaded previously, e.g., at804, the required class is first downloaded from the repository and then the local copy is used to create the instance.

FIG. 9is a flow chart illustrating an embodiment of a process for using locally stored classes to serve requests to instantiate business objects. In some embodiments, the process ofFIG. 9is implemented on an application server such as application server108. In some embodiments,806ofFIG. 8includes the process ofFIG. 9. At902, a request to instantiate a business object is received. At904, it is determined whether the requested class is available in the local class. If not, at906the class is downloaded from the repository and used at916to create the requested instance. If the class is available locally (e.g., was downloaded previously), at908it is determined whether it is time to check with the repository for business object class updates. In some embodiments,908includes checking if a timer has expired. If it is not time to check for updates, the locally stored copy of the class is used at916to create the requested instance. If the time for checking updates has arrived, at910a global change record at the repository is checked. At912it is determined whether the global change record indicates that one or more new and/or updated classes have been registered at the repository since the application server last checked and/or downloaded classes. In some embodiments,912includes comparing a value, such as a timestamp, version stamp, flag, etc. with a previously stored corresponding value read and stored the last time classes were downloaded and/or checked for updates. If the global change record does not indicate that new/updated classes have been registered at the repository, the locally stored copy of the class is used at916to create the requested instance. If the global change record indicates that one or more classes have been added to and/or updated at the repository since the last time the application server downloaded classes and/or updates and/or checked for changes, at914the application server iterates over all previously downloaded classes and checks a corresponding data in the repository, e.g., a class or collection of class specific change record and/or date value or other indicator, and downloads a new/updated definition for any previously downloaded and/or currently required class(es) for which a new and/or updated definition has been registered at the repository. Once the checking for and/or downloading of updates at914is completed with respect to at least the class requested at902, the locally stored (and if applicable updated) copy of the class is used at916to create the requested instance.

In some embodiments, class loading precedence rules are modified and/or configured to ensure applications running on a content management system framework, platform, and/or system properly download business object classes from an associated repository and that no conflicts between inconsistent versions of the same class and/or between otherwise incompatible classes result. In the JAVA 2 Platform Enterprise Edition (J2EE), for example, a class loader hierarchy is established in which a set of classes basic to the platform are loaded by a “bootstrap” class loader having no parent, and other class loaders of increasing specificity descend as children or grandchildren, etc. of that class loader. In the default configuration, a class loader has visibility in only one direction, toward its parents, grandparents, etc., and is configured to look to such parent class loaders first to find a definition to use to create a requested instance of a class. In some embodiments, the precedence rule by which a class loader looks first to its parent (which in turn looks first to its own parent, etc., as applicable) to obtain needed classes is modified to ensure that the class loader looks first to its own local cache of class definitions to service requests to create an object instance, and only delegates to a parent class loader if the class is not available locally. The J2EE standard, for example, contemplates such a precedence rule being configured at the web application level, to enable each web application to maintain its own set of classes separate from each other web application running on the application server and from the classes managed and used by the application server itself. In some embodiments, the precedence rules at a level lower than the application level are modified to configure a class loader at such a lower level to look first to its local cache prior to looking to a parent class loader. While not contemplated by the J2EE standard for other than web application class loaders, in some embodiments using this approach, e.g., at the application framework/system level, facilitates “sandboxing” at that level, making it easier to avoid so-called “jar conflicts”, such as could arise if an incompatible version of a class were loaded in a visible class loader.

FIG. 10is a block diagram illustrating an embodiment of a class loader hierarchy with modified precedence. In the example shown, a set of hardware and/or operating system vendor class loaders1002and a set of application server associated class loaders1004comprise a hierarchy of class loaders that includes a bootstrap class loader1006that has no parent, an “extension” class loader1008that is a child of bootstrap class loader1006, an application framework/system level class loader1010that is a child of extension class loader1008, application server shared class loader1012that is a child of application framework/system level class loader1010, and one or more web application class loaders1014that are children of application server shared class loaders1012. In a default configuration, at each level other than the web application class loader level a class loader looks first to its parent to obtain a class definition (which parent would in turn look first to its parent, and so on), and only to its own cache if the parent does not have and/or cannot obtain the class. A child can only “see” classes available via a parent, and has no visibility of the classes available to/from a child. In some embodiments, one or more class loaders (not shown inFIG. 10; seeFIG. 11) of which the application framework/system level class loader1010is a parent/grandparent are configured to look first to their local cache for a class definition, and only to delegate to a parent level class loader if the required class is not available and/or cannot be obtained (e.g., from a repository) by the application framework/system level class loader. In some embodiments, this modification of the class loader precedence rules facilitates sandboxing, thereby making it easier to avoid conflicts between classes.

FIG. 11is a block diagram illustrating an embodiment of a set of class loaders that are children/grandchildren of the application framework/system level class loader. In some embodiments, the class loaders shown inFIG. 11are created by a content management framework running on an application server, such as foundation classes1102, to manage the process of initially downloading and subsequently updating business object classes deployed from a repository. In the example shown, foundation classes1102has created an instance of a shared class loader1104. In some embodiments, shared class loader1104is configured to downloaded one or more business object interfaces and/or shared dependent jars (files referenced and/or otherwise used by one or more business object classes), analogous to a library of shared components, and includes an interface visible to one or more applications and configured to receive and service requests from the one or more applications to instantiate business objects. The shared class loader1104in turn has created (e.g., downloaded and instantiated) one or more type based object class loaders1106, one or more service object class loaders1108, one or more aspect object class loaders1110, and one or more module object class loaders1112. In this example, a separate class loader has been provided for each component (business object class) downloaded from the repository. A separate class loader is created for each component (business object) downloaded from the repository to segregate (sandbox) each component from each other component, e.g., so that problems do not result from the use by different components of incompatible versions of the same object, etc. In some embodiments, each of the component class loaders1106-1112is configured to look first to its own cache of stored classes and, if a required class is not available, then to shared class loader1104. In some embodiments, if a class is not available to shared class loader1104in a local cache, shared class loader1104requests the class, if available, from an associated repository. If the class is not available locally or for download from the repository, only then does the share class loader look to its parent class loader (e.g., application framework/system level class loader1010in the example shown inFIG. 10) to obtain the class.

Typically loading new/updated business object classes would require that at least the web application be restarted. On restart, the application typically would identify and subsequently use as required any updated software classes. However, in many cases continuous or near continuous access to applications and/or associated managed content is essential to an enterprise or other organization served by a content management system, including the enterprise's own employees, customers, vendors, suppliers, partners, contractors, etc. As a result, in some embodiments new/updated business logic and/or other software objects comprising a content management framework are downloaded from an associated repository and “hot deployed”, without requiring that the application be restarted or otherwise unavailable for any significant period of time.

FIG. 12is a flow chart illustrating an embodiment of a process for hot deploying new and/or updated business object classes. In some embodiments, the process ofFIG. 12is implemented on an application server to deploy new and/or updated business object classes downloaded from an associated repository. At1202, deployment begins with a first new/updated class. At1204, it is determined whether the class is new or an update (modification) to a previously downloaded class. If the class is new, at1206it is deployed by storing a copy in a local cache and using the local copy to create instances as requested and/or required. If the class is an update to a previously downloaded class, at1210the updated business object class is deployed and used to instantiate subsequently requested instances of the business object class. At1212, the original (superseded) business object class is retained until no longer needed. In some embodiments, the superseded business object class is retained until there is no longer an actively referenced and/or otherwise used business object that was instantiated based on the superseded business object class. In some embodiments, hot deployment of an updated business object class while retaining at least for a time a superseded version of the business object class is provided at least in part by configuring code associated with a framework on which one or more applications are running, such as business object framework304and/or foundation classes306ofFIG. 3, to receive from one or more applications, such as application(s)302ofFIG. 3, and process requests to instantiate business objects, including as shown inFIG. 12with respect to new or updated business object classes. In some embodiments, an application running on the framework does not request new business object instances directly from an underlying runtime environment (e.g., JAVA) ultimately used to instantiate business objects, but instead requests that the framework cause such business object instances to be created. The applications request a business object by name, and code associate with the framework maps each request to an associated business object class and causes the runtime environment to create an instance. In this way, the application(s) can continue to use the same name to request an instance of a business object both before and after an updated business object class has been deployed—each such request would be served by the framework using the original class prior to an update being deployed and using the updated class subsequent to an update being deployed—thereby avoiding the need to restart an application in order to configure it request instances based on the updated class. Instead, the update is transparent to the application, which continues to request (from the framework) the business object using the same name as before the update. Once a new or updated business object class has been hot deployed, it is determine at1214whether any more business object classes remain to be deployed. If so, a next class is selected for deployment at1216and1204-1214are repeated, as applicable, as described above. Once the last business object class has been deployed (1214), the process ofFIG. 12ends.

Hot deployment of new/updated business object classes as described above enables updated classes downloaded from a repository to be deployed with minimal impact on application server and/or individual business object availability.