SERVICE MANAGEMENT IN A DBMS

Abstract

Computer-implemented method, comprising: Providing a service manager that interacts with a database management system (DBMS), where the DBMS is a software application designed to enable the definition, creation, querying, updating, and management of databases; Automatic and dynamic registration of multiple DMBS services with the service manager during the DBMS runtime, wherein: Each of the multiple DBMS services processes data that is stored in a database managed by the DBMS; Each of the multiple DBMS services is implemented as a singleton, where a singleton is a software object implemented in such a way that only one instance of a specific type of software object can be instantiated at a time; and A first service among several DBMS services allows the service manager to check whether a cached singleton instance has already been initialized; and Managing dependencies between the multiple registered DBMS services by the service administrator, wherein: The dependencies are managed based on the source code of the DBMS service, which specifies dependency services required by the DBMS service; The class name of each dependency service is automatically converted into a string that is used by the service manager as an argument for managing the service; The dependencies of the services are represented in a single data structure and are identified and updated during the runtime of the DBMS using a deep search in a dependency tree that represents dependencies of the DBMS services registered with the service manager; the global variable represents a specific service that is to be registered with and managed by the service administrator; and Managing dependencies also features: in response to the creation of the global variable, execution of a constructor of a type associated with the global variable; and Identifying cyclic dependencies based on a representation of the dependencies of the DBMS services in the form of a directed acyclic graph.

Description

BACKGROUND

[0001] The present invention relates to database management systems (DBMS) and, in particular, to the management of services associated with a DBMS.

[0002] In conjunction with a DBMS, data often needs to be replicated, analyzed, validated, or otherwise processed for a variety of tasks. Some of these tasks can be implemented as services. Some services can be provided as an integral part of the DBMS, while others can be added later, for example, when installing a DBMS plug-in or add-on. Some services can be instantiated only in response to an explicit user query, while others can be implemented as daemons that run in the background. For example, IBM Db2 Analytics Accelerator (IDAA) from IBM includes infrastructure services such as the "Configurator" and "Tracer," services that provide access to metadata in the catalog, and background services that are scheduled, for example, by the "System Maintenance" daemon.

[0003] Due to the heterogeneity of the types of services integrated into a DBMS, and because some services may be added after the DBMS is installed according to user-specific requirements, managing all the data processing services offered by a DBMS is a complex and error-prone task. The situation is further complicated by the fact that there are often complex dependencies between the various services, for example, during instantiation or shutdown. Adding to the complexity, some services are implemented using delayed instantiation. This means that it is not possible to predict in advance when a particular service will be instantiated.

[0004] Current state-of-the-art database management systems (DBMS) use a single, central piece of software code that lists all the services supported by the DBMS. This central list of services, contained in a single source code file, is difficult to maintain because it can easily become outdated, for example, if a new library containing one or more additional services is loaded into the DBMS at runtime. If the list is specified in the source code, the relevant code must be recompiled whenever the source code is modified. Therefore, using a central list of services to orchestrate the instantiation and shutdown of services supported by a DBMS is error-prone, complex, and highly time-consuming.

[0005] Another disadvantage of a central list or file that specifies and orchestrates the instantiation of multiple files is that these files tend to become very complex if a large number of services, such as several hundred or even thousands, need to be managed. In this case, the source code that centrally specifies the dependencies of the various services may contain cyclic dependencies that are difficult for a programmer to identify. Such cyclic dependencies can lead to infinite loops and program errors.

[0006] Additionally, using a central list to orchestrate service instantiation in combination with delayed service instantiation has the disadvantage of increased resource consumption: To prevent service instantiation errors when a service is delayed instantiated at an unforeseen time, a common strategy is to instantiate all services that might be required by a given delayed service by default when the DBMS starts. While this strategy can help prevent errors associated with delayed instantiation, it increases the consumption of CPU and memory resources because services may be instantiated unnecessarily.For example, if a particular service is instantiated solely to ensure the correct instantiation of a service that is instantiated with a delay in response to a user query, this service may unnecessarily consume resources in a situation where, with regard to the delayed instantiation of the service, no user query is ever received.

[0007] Managing services in a current DBMS is therefore a cumbersome, error-prone task that often leads to programming errors, high CPU and memory requirements, and an inflexible system that is unable to integrate new services and program libraries without modifying and recompiling the source code.

[0008] US 2012 / 0030680A1 describes a computer-implemented method for handling requests via a general-purpose service management framework, wherein the method is executed by one or more processors configured to perform a variety of operations, the operations including: receiving a service management request; querying a global service database to retrieve service configuration information for a service associated with the service management request, wherein the global service database stores service configuration information associated with a variety of services defined and added to the framework; determining a location or platform of the service associated with the service management request based on the retrieved service configuration information;and processing the service administration request based on the specific location or platform.

[0009] The scientific article "A Dependency-aware Hierarchical Service Model for SaaS and Cloud Services" by R. Wang et al., published in "2011 IEEE International Conference on Services Computing," pp. 480-487, addresses service-oriented computing as a computing paradigm that utilizes existing services as fundamental elements for developing distributed applications based on the "use, not own" principle. In this model, services are divided into three levels according to different business requirements. Services are assembled by selecting services from the lower level or other services at the same level. Tenant applications are implemented by selecting services at the composite business level. A hypergraph-based service model is used to represent hierarchical services and multi-tenancy applications.The authors propose algorithms based on a directed hypergraph that can represent dependencies between services and applications to verify the correctness of the dependencies during the application development phase, and implement an SCA-based platform for building large-scale multi-tenancy applications. SUMMARY

[0010] The invention relates to a computer-implemented method, a computer-readable storage medium, and a corresponding computer system for managing multiple services in a DBMS, as set forth in the independent claims. Embodiments of the invention are set forth in the dependent claims. Embodiments of the present invention may be freely combined with one another, provided they are not mutually exclusive.

[0011] According to one aspect, the invention relates to a computer-implemented method for managing multiple services in a DBMS. The services are each configured to store data that is stored in a database managed by the DBMS or received for storage in such a database. The method comprises: providing a service manager operatively connected to the DBMS; automatically and dynamically registering the multiple services with the service manager during the runtime of the DBMS; and automatically managing dependencies between different registered services by the service manager.

[0012] According to another aspect, the invention relates to a computer-readable storage medium containing program instructions, wherein the program instructions are executable by a processor to cause the processor to execute a method for managing multiple services in a DBMS. The services are each configured to store data that is stored in a database managed by the DBMS or received for storage in such a database. The method involves managing multiple services in a DBMS. The services are each configured to store data that is stored in a database managed by the DBMS or received for storage in such a database.The procedure involves: providing a service manager that is functionally connected to the DBMS; automatically and dynamically registering the multiple services with the service manager during the runtime of the DBMS; and automatically managing dependencies between different registered services through the service manager.

[0013] According to another aspect, the invention relates to a computer system comprising a database management system (DBMS) and a service manager that is operatively connected to the DBMS. The service manager is configured to automatically and dynamically register multiple services with it during the DBMS's runtime. Each service is configured to process data stored in, or received for storage in, a database managed by the DBMS. The service manager is further configured to automatically manage dependencies between the various registered services. Brief description of the different views of the drawings

[0014] In the following, embodiments of the invention are described in greater detail by way of example only, with reference to the drawings, wherein: Fig. 1 represents a computer system that includes a DBMS and a service manager; Fig. 2 represents another computer system that includes a DBMS and a service manager; Fig. 3. A flowchart of a procedure for managing services in a DBMS; Fig. 4 represents the dependencies of several services; Fig. 5 illustrates the integration of services and the service manager into a larger system architecture; Fig. Represents 6 sections of source code for a service class; Fig. It represents 7 sections of source code from various object and interface classes used to implement a service. DETAILED DESCRIPTION

[0015] Embodiments of the invention can offer the advantage of providing a system and method for managing multiple services within a DBMS, thereby increasing the system's flexibility and maintainability and reducing resource consumption, particularly when using delayed instantiation for some services. Some or all of the technical disadvantages associated with prior art service management methods can be avoided.

[0016] In embodiments of the invention, libraries, each comprising one or more services, can be dynamically loaded into the DBMS during runtime and the new services can remain instantiated in the DBMS without requiring manual modification of a central file and / or recompilation of code.

[0017] Embodiments of the invention can be advantageous because they avoid many technical disadvantages of prior art service management approaches that rely on a single, central list of services supported by a DBMS: Each service added to the DBMS automatically registers with the service manager at runtime. Thus, it may not be necessary to modify and recompile source code. Furthermore, since the service manager automatically maintains service dependencies, such as those of dynamically added services, it ensures that all services required by a particular service are instantiated by the service manager before the service itself is instantiated.This avoids the instantiation of too many services by default, thus preventing errors during service instantiation, as dependencies are managed by a service manager designed to automatically register new services during the DBMS runtime.

[0018] According to embodiments, the method further includes: automatically identifying one or more other services required by the one service to be registered by the service administrator during the registration of one of the services with the service administrator; and updating the dependencies between the multiple registered services, the service to be registered, and the services identified during the registration of the one service, so that the dependencies also include the dependencies of the service to be registered and the other required services.

[0019] For example, one or more other services required by a particular service to be registered can be specified within the service itself, such as in its source code, and / or can be dynamically provided to the service manager by a function of that service. For instance, the function could be a `getRequiredServices` function that returns a list of strings generated by the service, configured to convert the class names of the required services—specified, for example, in the service's source code or in class files associated with the service—into corresponding strings. These strings can then be used by the service manager as arguments to register the required service and, optionally, to dynamically instantiate a required service before instantiating the service in question.

[0020] This can be advantageous because the class names of the one or more services required by the service being registered are specified explicitly or implicitly within the service itself, rather than in a centrally managed configuration file. This can ensure that managing the dependencies of hundreds or even thousands of services globally in a single file is avoided. Automated conversion of a service's class name into a string used by the service manager as an argument for managing (registering, initializing, and / or shutting down) a service can be beneficial because it can guarantee a canonical and deterministic use of service names.

[0021] According to preferred embodiments, the getRequiredServices function, when called, is configured to: convert the class names of the one or more required services into a corresponding string; convert the one or more strings into a compiler-checkable object; and return the compiler-checkable object to the service manager that called the getRequiredServices function.

[0022] Using automated conversion of a class name specified in a class's source code to a data object of a type known to the compiler allows the compiler, at compile time and optionally at design time, to verify that a particular service has been referenced correctly. This can help avoid typos, cyclic service dependencies, and / or duplicate service names during programming / software development.

[0023] If the dependencies of a particular service change, there is no need to update a central service repository of the DBMS or to recompile the DBMS source code. However, if a service is modified to require an additional analytical or mathematical service library, the service's source code may still need to be modified and recompiled. According to embodiments of the invention, loading an additional service into the DBMS does not, in itself, require manual modification or recompilation of a central service repository. In contrast, some prior art systems would require updating both the service's source code and the DBMS source code, which contains a central list of services, or at least this central list of services.

[0024] In some implementations, the service manager is designed to register dynamically loaded services and instantiate one or more of the newly loaded services in the correct order according to a dynamically updated data structure that contains the dependencies of all services registered with the service manager. Services can be dynamically instantiated and shut down as needed without requiring any manual updates to source code or a central configuration file. For example, the service manager can be configured to dynamically load a library containing one or more new services into the DBMS at runtime. The library is loaded into the DBMS to ensure that a specific action can be performed, such as an OLAP analysis of certain data, like a specific statistical clustering analysis.Loading the library can be triggered by an explicit user action. The new services in the loaded library may have dependencies on other services, which may be part of the loaded library and / or the set of already registered services. Loading the service library at runtime can automatically trigger the registration of the services contained in the loaded library via their service classes and interfaces. In some examples, the service source code also includes calls to constructor methods or other methods (also called "functions") that trigger the instantiation of other required services. The service manager can be configured to call a `getRequiredServices` method of each service to be registered during the registration process to identify the dependencies of the service being registered.The service manager is configured to update the dependencies of all services managed by the service manager.

[0025] Embodiments of the invention can have the further advantage that the service manager does not need to know all services when the service manager or the DBMS starts. Rather, services can be added later as needed. A service dynamically loaded into the DBMS interacts with the service manager during the loading and registration process, so that registration is performed automatically and a callback mechanism is provided that allows any number of ways to instantiate services and introduce / register further dependencies. A central configuration file or class in which all services must be pre-registered by hardcoding them in the source code can be avoided, resulting in significantly improved flexibility and maintainability of the system.

[0026] According to some implementations, dependency management involves instantiating services according to the dependencies, so that all services required by a particular service are already instantiated when that particular service is instantiated by the service manager.

[0027] According to some embodiments, one or more of the services are instantiated with a delay.

[0028] According to embodiments, at least some of the several services represent steps within a workflow of a product manufacturing process. At least some dependencies represent equipment dependencies, workflow dependencies, material dependencies, and / or supply dependencies of physical objects that are involved in or processed by the product manufacturing process.

[0029] For example, a DBMS can be used to manage one or more databases containing data generated and used by an ERP (Enterprise Resource Planning) system. A core function of many ERP systems is Material Requirements Planning (MRP I) and Manufacturing Resource Planning (MRP II).

[0030] Material requirements planning (MRP) involves computational tasks such as production planning, scheduling, and inventory control, which are used to manage manufacturing processes. An MRP system or subsystem typically performs one or more of the following functions: ensuring that materials are available for production and products are available for delivery to customers; maintaining the lowest possible material and product inventories; and planning manufacturing activities, delivery times, and purchasing activities.

[0031] Production Resource Planning (MRP II) involves computational tasks related to the effective planning of all resources within a manufacturing company. It can encompass operational planning at the unit level, financial planning, and may include simulation capabilities to answer "what-if" questions and extend the closed MRP loop. An MRP II system or subsystem typically performs one or more of the following functions: generating and updating the Master Production Schedule (MPS), managing item master data (engineering data), utilizing production resource data and other engineering manufacturing data, material requirements planning (MRP), capacity requirements planning (CRP), and so on.

[0032] Nowadays, fewer and fewer manufacturing companies produce goods that remain unchanged and unmodified over extended periods ("for stock"). Due to frequent changes in customer requirements, these companies must be able to adapt their production processes quickly and easily, keeping pace with new customer preferences in every respect. In particular, when customers prefer the ability to "design" the product they wish to purchase—for example, when a car manufacturer allows a multitude of features to be changed during the ordering process, making the final delivered car virtually unique—managing the manufacturing process and the necessary resources becomes extremely complex and difficult to maintain. Various functions of an MRP or MRP-II system or subsystem can be implemented as services that are either an integral part of a DBMS or that are subsequently loaded into the DBMS.in the form of program libraries. The point in time at which a library is loaded and the services it contains are registered and / or instantiated may be unpredictable. Thus, an ERP system can have many hundreds or even thousands of services, the management of which is a highly complex task.

[0033] Embodiments of the invention can also enable the orchestration of a vast number of services, the number and relative dependencies of which are not sufficiently predictable in advance to ensure a suitable manufacturing process. Managing and updating dependencies when planning materials and resources for the manufacturing process becomes much simpler if service registration is decentralized, based on an automated and dynamic registration of each service and its respective dependencies with the service administrator. This eliminates the need to manually maintain a central list of registered services.

[0034] According to further embodiments, at least some of the services managed by the service manager include services for shutting down and restarting services and processes within a manufacturing plant's workflow. The service dependencies specified within each service, which are automatically extracted by the service manager or otherwise automatically and dynamically received, reflect the dependencies of the physical requirements and the dependencies of the individual processes for shutting down and restarting the manufacturing plant's services and processes. The service manager automatically coordinates temporary shutdowns and restarts of the manufacturing plant, for example, to perform maintenance or service tasks. In many plants, it is necessary to shut down or start up systems in a specific sequence so that upstream systems can go offline or online.For example, during maintenance of a beverage production facility, it is crucial that water supply systems are started up before systems that convert water into high-pressure steam, followed by systems that generate pure steam. All steps involved in a planned, temporary shutdown are efficiently orchestrated by the service manager to avoid disrupting workflow, damaging machinery involved in the manufacturing process, and compromising the quality of finished products. Any disruptions in this process can trigger a domino effect, posing a risk to schedules and budgets. Given the complexity and scale of such manufacturing facilities, orchestrating all the interdependencies between equipment, consumables, products, parts, and processes is no small feat.With embodiments of the inventions, physical objects such as equipment, goods, intermediate products, or machines can be represented as a service that is loaded into the DBMS. Each new piece of equipment, each dynamically generated product or intermediate product, and the corresponding other physical objects required (machines, parts, other intermediate products, or consumables) can be specified in the relevant service as service requests. If the services loaded into the DBMS are automatically registered with the service manager, a highly dynamic adaptation of the workflow and orchestration of the instantiation of individual services and workflow tasks can be achieved. The flexibility required by modern, highly dynamic manufacturing processes could not be achieved based on a manually curated, central list of services.All or at least many services are preferably implemented as Singletons.

[0035] According to embodiments, the dependency management involves shutting down one or more of the services according to the dependencies, such that before shutting down any one of the services, the shutdown of that one service is delayed until all services dependent on that one service have been shut down.

[0036] This can ensure that shutting down one service does not negatively impact other services that depend on it. For example, in complex manufacturing processes, shutting down one process could interrupt another, a dependency that a human operator might not be aware of. Embodiments of the invention can prevent unwanted shutdowns or failures, such as those of a complex manufacturing process, caused by an erroneous shutdown command from a human operator, by delaying the shutdown until it is no longer required by any other service.

[0037] According to embodiments, each of the services is implemented according to a singleton design pattern. For example, each of the services can be implemented as a singleton.

[0038] This can reflect the fact that the machines, consumables, products and intermediate products involved in a manufacturing process are also considered as “physical single-instance objects”.

[0039] According to some embodiments, the dependencies of the services are represented in the form of one or more directed acyclic graphs (DAGs).

[0040] This can have the advantage that a diagram such as a tree can be traversed quickly and cyclical dependencies can be easily identified.

[0041] In some implementations, service dependencies are represented in a single data structure, which is managed and continuously updated by the service manager during the DBMS runtime. A dependency update is performed specifically when a service is newly registered with the service manager.

[0042] In some implementations, one, several, or all of the multiple services have a `getServiceInstance` function. The service manager can access this function, which allows the service manager to check whether a private member, a cached singleton service instance, has already been initialized. If so, the existing service instance is returned directly to the service manager. If not, a new service instance is created, added to the member variable, and returned to the caller (e.g., the service manager) immediately before its first use.

[0043] According to embodiments, the method involves adding another service to the DBMS. This addition includes registering the additional service with the service manager during the DBMS runtime and automatically updating the service dependencies so that the dependencies represent the dependencies of both the existing and the additional service.

[0044] For example, registering the additional service can be part of a program library that may contain further services. The library is loaded into the DBMS at runtime, allowing other services to use the services contained in the library and / or enabling services within the library to use services that are already instantiated by the service manager or at least registered with the service manager.

[0045] In some implementations, the registration of services with the service administrator is realized through a decentralized registration process. The use of a decentralized registration process means that neither the DBMS nor any other system functionally coupled with the DBMS maintains or uses a manually generated and maintained list of registered services.

[0046] In some implementations, service dependencies are specified within the services themselves, for example, within the service source code, and communicated to the service manager when the services are registered with the manager. For instance, the source code of a class file implementing the services might contain a list of class names of one or more other services required by that service. The service manager is configured to parse this list when the service (or one of the services) is registered and to update the dependencies accordingly.

[0047] Additionally or alternatively, each of the multiple services has a function for registering the service with the service manager. For example, the service class that implements the service, or an interface class implemented by the service, can have this function. The function used for service registration could, for example, be a `registerService` function.

[0048] According to embodiments, each of the multiple services has an instantiateService function and a shutdownService function. The service manager can access (i.e., call) the instantiateService and shutdownService functions. These functions can be, for example, public functions. The method further includes: the service manager using the instantiateService and shutdownService functions of the multiple services to dynamically orchestrate the instantiation and shutdown of the multiple services according to their dependencies. The instantiateService and shutdownService functions of the multiple services managed by the DBMS are preferably identical, i.e., they have the same function name and the same list of arguments, while the specific implementation can differ from service to service.This simplifies the maintenance and management of a large number of services, as the service manager can control the instantiation and shutdown of a large number of services with a small number of commands.

[0049] In some embodiments, each of the multiple services has a `getRequiredServices` function. The service manager can access this function, which is configured to return the names of one or more required services. Each required service is a service that must be instantiated before the service containing the `getRequiredServices` function is instantiated. Registering each of the multiple services involves the service manager calling the `getRequiredServices` function of the service to be registered; automatically checking whether the names of the required services returned by the `getRequiredServices` function indicate an already registered service; and automatically registering any service returned by the `getRequiredServices` function that has not yet been registered.

[0050] For example, the service administrator can search for the name of a required but not yet registered service in a local or remotely located service library.

[0051] According to embodiments, the execution of the getRequiredServices function involves: converting the class names of the one or more required services into a corresponding string; converting the one or more strings into a compiler-testable object; and returning the compiler-testable object to the service manager that called the getRequiredServices function.

[0052] In fact, the getRequiredServices function transforms the identified class names into a standardized (“canonical”) way that can even allow an automated check of the object type by a compiler.

[0053] In some implementations, the service manager is configured to call the `getRequiredServices` function of any one of the multiple services even before the service is instantiated. The service manager is configured to check whether the names of the required services returned by the `getRequiredService` function identify an already instantiated service; and to automatically call the `instantiateService` function of the identified service returned by the `getRequiredService` function that has not yet been instantiated. In other implementations, however, the service manager does not call the `getRequiredService` function in anticipation of service instantiation, because all dependencies of the services managed by the service manager have already been identified during the registration process and stored in a separate data structure, such as a directed acyclic graph, a tree, or a set of trees.The service manager is configured to analyze this dependency data structure before a given service is instantiated, and to instantiate all services whose instantiation is required by the relevant service before the relevant service is instantiated. This can have the advantage that each service only needs to specify a limited set of required services and does not have to worry about second- and third-level dependencies; that is, it does not have to specify the services required by the "required services," since these second- and third-level requirements are automatically handled and integrated into the global dependency data structure by the service manager when the required services are registered.

[0054] In some implementations, the service manager is configured to update dependencies at least when a service is registered. Updating dependencies involves updating the dependencies between the multiple registered services, the service being registered, and the "required" services identified during the registration of the service, so that the dependencies also include those of the service being registered and the other required services.

[0055] The dependencies can be stored in one or more data structures managed by the service administrator. The data structure could be, for example, a directed acyclic graph or a set of directed acyclic graphs. In other exemplary embodiments, the data structure representing the dependencies could also be a list, a set of lists, or any other type of data structure suitable for encoding dependencies between multiple services.

[0056] According to embodiments, at least one of the multiple services specifies one or more other services required by that one service. These services are also referred to as "required services." The specification of the one or more other services can be in the form of a list of class names, which are checked by a compiler during compilation time. When compiling a service class, an error is raised if the service class contains the name of a required service and the compiler cannot identify a class whose name matches the name of the required service.

[0057] State-of-the-art service management systems (e.g., the "CodeProject" available online at https: / / www.codeproject.com / Articles / 5794 / Registry-of-Singletons) neither automatically register services nor manage dependencies between them. Furthermore, these systems identify services by a string—that is, an expression in source code or another file—specified in a syntax that cannot be checked by a compiler configured to compile the service. The problem with using strings for unique service registration is that each string representing a service must be globally unique. Moreover, any typo can lead to an error that cannot be identified before the service source code is compiled and tested.Therefore, using unwritten strings to specify the names of required services in a service's source code is error-prone and can lead to situations where errors are found relatively late (if at all).

[0058] In contrast, the embodiments of the invention mentioned above directly use the class names of other services and transform them into a compiler-checkable object that can specify one or more required services. This means that the source code of a particular service contains a list of the class names of the one or more other services required by that particular service. The class names are included in the source code of the particular service in a syntax that forces the compiler to check whether the class name is identical to the class name of one of the registered services. Specifying required services in the source code of a service using exactly the same identifiers that the compiler itself uses can have the advantage that references to invalid services can be checked by the compiler during compilation time and, optionally, during design time.The compiler raises errors during compilation time or generates underlines or other forms of text highlighting during design time if an unknown service class name is included in code of a service class that has just been compiled or modified.

[0059] According to embodiments, the design-time environment used for programming a service is configured to use the compiler to identify, during the service's design time, a section of source code that mentions a service class name that does not match an existing service class known to the compiler. In this case, the design-time environment is configured to automatically highlight the service class name in the service class's source code during design time.

[0060] This can be advantageous because typos and other errors that lead to a discrepancy between the name of a required service specified in the service's source code and the actual name of the class that represents and / or implements the required service are automatically detected during the design phase. This can significantly accelerate the service development process, as errors are identified automatically and at the earliest possible stage.

[0061] According to various embodiments, the service manager is a component of an application that is implemented as an extension application (add-on or plug-in) of the DBMS, or it is an integral component of the DBMS.

[0062] For example, an integral component of the DBMS can be a program component or function that is part of the core functionality of the DBMS and is provided as part of the DBMS, as originally provided by the DBMS developer or vendor. Providing the service manager as an integral part of the DBMS can be advantageous because the DBMS already provides support for automatic and dynamic registration and dependency checking of new services to be loaded into the DBMS.

[0063] Providing the service manager as a plug-in or add-on to the DBMS can be advantageous, as it allows an existing DBMS to be enhanced by the ability to automatically and dynamically load new services into the DBMS, so that their dependencies on other services are automatically taken into account and integrated into the dependencies of existing services.

[0064] According to embodiments, the method further features: a) Receiving a service request for a specific service by the DBMS; b) Identifying the requested service among the multiple services by the service administrator; c) The service administrator must identify one or more of the other registered services required by the requested service; - for each of the identified one or more other services: i. to check whether this other service is already instantiated; ii. if that other service is already instantiated, to switch to the next service identified in step c; iii. if this other service is not yet instantiated, instantiate the other service and move on to the next service identified in step c.

[0065] This can be advantageous because the service manager is designed to ensure that any service that might be instantiated with a delay in response to a user request passed to the DBMS can be instantiated without a programming error caused by other, but required, services that are not instantiated.

[0066] In some implementations, the service manager is configured to store dependencies in a data structure with a logical sort order defined by the dependencies. The logical sort order of the services in the data structure representing the service dependencies can be used to orchestrate the instantiation and shutdown of the multiple services managed by the service manager. For example, the topological sort order can be determined explicitly using well-known algorithms or implicitly by performing a depth-first search, as described in the pseudocode in the two preceding paragraphs.

[0067] As used herein, the term "delayed initialization" describes the tactic of postponing the creation of an object—in this case, a service—until it is first needed. This is a type of delayed evaluation specifically related to the instantiation of objects or other resources. Deploying services with delayed instantiation can improve the startup speed of the DBMS because the effect of object instantiation is spread over a period of time, rather than being concentrated in the system's startup phase, thus significantly improving mean time to response.

[0068] As used herein, the term "service" refers to a software functionality or set of software functionalities with a purpose that can be reused by different clients or different program routines acting as clients for different purposes. A "service" is preferably a software functionality for processing data that is currently stored in a database managed by a DBMS and / or that is intended to be stored in the database managed by the DBMS. For example, a service could be a clustering algorithm designed to cluster digital disease patterns. Another service could be a principal component analysis service configured to identify a subset of parameters in a dataset that predicts a particular relevant feature with a high probability.Another example of a service could be a specific type of report, such as a report detailing the number of consumables used during the production of a particular good, the amount of energy and water consumed at a specific manufacturing step, or similar information. The report may be specific to a particular user or user group and / or depend on other factors. The report can be generated dynamically by analyzing data such as manufacturing-related data stored in a database. Depending on the specific implementation, a service may have an interface that allows a user or another software function to access the service.

[0069] For the purposes of this document, a "registered service" is a service whose name (or other identifier) ​​and dependencies on other services (if any) have been communicated to the service administrator. As a result, the service administrator has integrated the registered service and its required services, if any, into a data structure used to represent the dependencies of all registered services.

[0070] As used herein, a "service manager" is a software element configured to manage a plurality of services. The software element may be a standalone application, a program module, a program routine, a program function, a software class, or a combination of two or more of the above.

[0071] As used herein, a "compiler-checkable object" is a data object to which a type, such as a specific object class, and optionally other attributes are assigned, enabling a compiler to perform one or more consistency checks during compilation time and optionally also during design time. A consistency check might, for example, include verifying whether the type assigned to the data object is contained in a list of object types known to the compiler.

[0072] As used herein, a "database" is a collection of electronic information ("data") organized in memory or on non-volatile storage media in the form of a specific, defined data structure that supports or is optimized for data retrieval by a specific type of database query. The data is usually logically organized in database tables. A database can be, in particular, a relational database, such as a column-oriented database or a row-oriented database.

[0073] For the purposes of this document, a "database management system (DBMS)" is a software application designed to enable the definition, creation, querying, updating, and management of databases. Examples of DBMS include IBM Db2 for z / OS, MySQL, PostgreSQL, IBM Db2 Analytics Accelerator (IDAA), and others.

[0074] As used herein, a "database query" or "query" is a command to retrieve, update, store, and / or analyze data stored in a database managed by a DBMS, the command being specified in the syntax of the DBMS interface. The syntax may, for example, be SQL.

[0075] As used herein, a "table" is a database table that is managed by a DBMS.

[0076] As used herein, a "module" is a hardware, firmware, or software element, or a combination thereof, configured to perform a specific function within an information technology (IT) scheme. For example, a module may be a standalone software application, or a submodule or subroutine of a software application that contains one or more other modules.

[0077] As used herein, a "Singleton pattern" is a software design pattern that restricts the instantiation of a class to a single instance and provides global access to that instance. Accordingly, a "Singleton" is a software object implemented in such a way that only one instance of a given type of software object (e.g., a specific type of service represented and implemented by the software object) can be instantiated at any one time.

[0078] Fig. Figure 1 represents a computer system 100, which has one or more processors 104 and a DBMS 102. For example, the computer system can be a standard computer system, such as a desktop computer system or a server computer system, or a distributed computer system, such as a cloud computer system. The DBMS can be of any type. For example, the DBMS 102 can be a relational DBMS. The DBMS can be a columnar DBMS, a rowal DBMS, a hierarchical DBMS, or the like. For example, the DBMS can be one of the following: IBM Db2, MySQL, Oracle, PostgreSQL, IBM's Db2 Analytical Accelerator for Db2 (IDAA), or the like. The computer system has a service manager 106 that is operationally connected to the DBMS 102.

[0079] The computer system 100 also has a service administrator 106, which is functionally connected to the DBMS.

[0080] As used herein, the expression “service manager integrated with a DBMS” can, for example, mean that the service manager is an integral part of the DBMS because it is configured to manage services that use the DBMS as their respective runtime environment.

[0081] The service administrator is configured to perform a procedure that is in Fig. 3 is illustrated and described below by referring to elements from both Fig. 1 as well Fig. 3 is taken.

[0082] The service manager 106 can be deployed in step 302, for example, as an integral component of the DBMS by installing and instantiating the DBMS. Alternatively, the service manager can be deployed in step 302 after the DBMS has been instantiated. For example, the service manager can be included in a plug-in or add-on of the DBMS, and the functionality of the service manager is deployed when the plug-in or add-on is installed and instantiated on computer system 100.

[0083] Service Manager 106 is configured to automatically and dynamically register several services 108 to 114, 208 to 214 with the DBMS during runtime in step 304. For example, when a new program library containing one or more services is loaded into the DBMS, the services contained in the library are automatically registered with the Service Manager. Additionally, or alternatively, services that are an integral part of the DBMS are automatically registered with Service Manager 106 when the DBMS is instantiated. Each service is an element of program logic ("software") configured to process data that is stored in, or received from, one of the databases 116 to 122 managed by DBMS 102.

[0084] The service manager 106 is configured to automatically manage dependencies 107 between the various registered services in step 306. For example, during the registration of a new service, the service manager identifies one or more other services required by the service being registered and updates the dependencies so that the updated dependencies also reflect the service dependencies of the service currently being registered. Similarly, the dependencies are updated even if a service is not registered. The dependencies 107 might, for example, be a data structure managed by the service manager and accessible only to the service manager.For example, dependencies can be a tree or a set of trees, where the nodes represent services and where an edge connecting a parent node to a child node represents a dependency between a service represented by the parent node and a required service represented by the child node. The service manager can be configured to ensure that the services represented by all direct and indirect child nodes of a given node are instantiated before the service represented by that given node is instantiated.

[0085] Services 108 through 114 can have one or more daemons and one or more services that can be explicitly called by a user or a function of the DBMS. Each service can be implemented as a singleton; however, any other software pattern can be used that ensures only a single instance of a service can be instantiated at any one time, meaning that the singleton design pattern is not the only possible implementation option.

[0086] For example, the services might include a Catalog Manager service configured to track and determine the settings of various configuration parameters in IBM's IDAA. The services might also include a Tracer service and a Configurator service, which the Catalog Manager service uses to provide the aforementioned tracing and configuration functionalities. The Tracer service depends on the Configurator service. Therefore, to start and use the Catalog Manager service, the Tracer service must already be instantiated. However, since the Tracer service depends on the Configuration service, the Configuration service must be instantiated first, followed by the Tracer service, and finally the Catalog Manager service. Due to the often complex dependencies between different services, it is important that the services are instantiated in the correct order.

[0087] According to a state-of-the-art approach, the correct order of service instantiation is ensured as follows: a central initialization class is provided, with a hard-coded line in the source code for each of the DBMS services: "registerService <configurator>(); registerService <tracer>(); registerService <catalogmanager>();

[0088] However, using a central class to globally instantiate services according to the state-of-the-art approach mentioned above does not guarantee a correct instantiation order. For example, depending on user requests, some services may be instantiated with a delay, resulting in an unforeseen temporal sequence. If a service is added to the system at runtime, for example, by loading a library into the DBMS, it is necessary to update the source code of the central class and recompile the class, and potentially the entire DBMS. Some services that perform background operations (so-called "daemons") require an explicit, external trigger for instantiation. Furthermore, maintaining a central class or other element of source code that handles these tasks becomes too complex.This explicitly specifies the order of service instantiation events when the number of services exceeds a certain threshold. For example, cyclic dependencies can occur between multiple services, causing runtime errors that are difficult to identify. Maintaining such a central register is tedious, and developers often take steps to avoid it. For example, instantiation chains have been created by instantiating one or more services as another service is instantiated. This results in a (partially) manually coded dependency diagram between all services, and thus code that is more complex and harder to maintain.

[0089] In contrast, according to embodiments of the invention, the services register dynamically with the service manager during the runtime of the DBMS. The service manager processes and orchestrates the instantiation and shutdown of all services of the DBMS 102, for example, in a thread-safe manner, whereby the service manager and each of the services can each be executed in a separate single thread. During the instantiation and shutdown of each of the services 108 to 114, the service manager 106 ensures that dependencies between the services are respected. The automated registration of the services with the service manager and the automated updating of the dependencies ensure that the DBMS can support a large number of services.Another technical advantage of automated registration and dependency updates is that any code accessing a registered service can always rely on the service being available. There is no performance degradation caused by checking and delaying service instantiation.

[0090] Preferably, each of the services is implemented as a singleton, meaning that a single software object is created and made available for subsequent use by other services or functions of the DBMS.

[0091] Fig. Figure 2 shows an alternative embodiment of a computer system 200, which includes a service manager 106 and a DBMS 202. The system 200 includes one or more processors 204, an OLTP DBMS 203 such as IBM's Db2, and an OLAP DBMS such as IBM's IDAA 202. The two DBMSs 203 and 202 can be hosted on the same computer system 200 or on different computer systems. The OLTP DBMS 203 has a query optimizer optimized for performing write queries, while the OLAP DBMS 202 has a query optimizer optimized for performing analytical read queries. The OLTP DBMS 203 could be, for example, Db2 for z-OS, an Oracle database, a PostgreSQL or MySQL DBMS, or the like. The OLAP DBMS 202 could be, for example, IDAA.Computer system 200 can have a replication engine 232 configured to replicate data stored in databases 228 and 230 of the OLTP DBMS to databases 216 to 222 of the OLAP DBMS. The computer system can also have a query allocation module configured to parse any database query accessing the OLTP DBMS 203 and to forward some queries, especially complex analytical queries, to the OLAP DBMS. The query allocation module attempts to predict whether the query can be executed faster or with fewer computing resources in the OLAP DBMS than in the OLTP DBMS. If so, the query allocation module forwards the database query to the OLAP DBMS for execution. The client that submitted the query is not usually informed whether the query was executed in the OLTP DBMS or the OLAP DBMS.The OLAP-DBMS can have a plurality of services 208 to 214, each configured to perform analytical queries such as statistical evaluation, clustering and classification tasks, image segmentation, complex reports for various users, purposes and subsets of data, and the like.

[0092] The OLAP DBMS 202 can have several hundred or even thousands of services 208 to 214. Some of these services may be an integral part of the DBMS 202 from the outset. Other services can be loaded into the DBMS later, for example, if the owner of the DBMS 202 decides to perform certain types of data analysis tasks that are not covered by the already integrated services. The service manager 106 is designed to fully automatically manage and maintain a very large number of services and their related dependencies 107, thereby ensuring that the DBMS 202 and its services operate stably and also ensuring that errors associated with manually specifying dependencies and / or the chronological order of service instantiation are avoided.

[0093] Fig. Figure 3 presents a flowchart of a procedure for managing multiple services in a DBMS, which was already described in the figure description. Fig. As explained in section 1. For example, step 302 can be performed by installing a DBMS that already has the service manager 106, or by installing a plug-in that has the service manager, using the already installed DBMS 202 as the runtime environment.

[0094] In one embodiment, the DBMS 102, 202 is started. Starting the DBMS involves loading one or more service libraries into the DBMS and starting the service manager 106. In the next step, the service manager registers the services contained in the libraries that were loaded when the DBMS 102, 202 started. The registration process involves identifying the dependencies of each service to be registered and storing all identified dependencies in a central dependency data structure 107, which is maintained by the service manager. In this way, the service manager checks that no cyclic dependencies exist in this data structure 107. Additional initialization steps can also be performed during the DBMS startup.

[0095] Once the DBMS 102, 202 has started, the service manager 106 is designed to instantiate individual services as needed. For example, the service manager may have a user interface that allows a user to submit a query directly to the service manager to perform a specific service. In other implementations, the service manager interfaces to the DBMS 102, 202 and receives a user request for a specific service indirectly through the DBMS 102, 202. In this case, the DBMS 102, 202 has a corresponding user interface 124, 224. Typically, the user interface 124, 224 is a non-SQL interface that allows a user to request a specific service, such as a particular clustering algorithm, a specific report, or the like. The user cannot access or request all services maintained by the service manager.For example, some services may be background daemons required by higher-level services that are actually relevant to a user.

[0096] When the DBMS is instantiated, some of its services can also be instantiated automatically. This automated instantiation is managed by the service manager. For example, a `main()` method of the service manager, or another class calling the service manager, might contain a list of services to be instantiated automatically when the DBMS is instantiated. The service manager evaluates the dependency data structure 107 to determine if any of these "early instantiated" services require any additional services, and if so, to automatically instantiate those required additional services before the "early instantiated" services are instantiated.If one of the additional required services is not yet registered with the service manager, the service manager is configured to search for the name of the additional required service in a predefined, local or remote repository, for example, a local or remote repository that contains a set of service libraries. The services found during the search are then automatically loaded into the DBMS and automatically registered with the service manager. The dependencies of these newly and dynamically registered services are also automatically analyzed as described above and can trigger the automated search and loading of further libraries from the predefined repository until all services required by the "previously instantiated" services are automatically loaded into the DBMS and instantiated by the service manager.

[0097] After the DBMS is instantiated, it can be used to process database queries and data analysis tasks according to the state of the art. The service manager can then receive a request for a specific service from a user, the DBMS itself, or any other client software. The requested service may not be among the "early instantiated" services and therefore may not be instantiated at the time the request is received. The service manager evaluates the dependencies between the requested service and other services (108-114, 208-214) to identify one or more required services that must be instantiated before the requested service can start and operate correctly.If the requested service requires a service that has not yet been registered with the service manager, the service manager initiates a search for the required service in the local or remote repository and automatically downloads and registers the required services found during the search. When a new service is registered, the dependencies are updated to include the dependencies of the newly registered service(s). The service manager then automatically instantiates each of the required services and subsequently instantiates the requested service. The instantiated service is used to process data stored in a database managed by the DBMS and to return a data processing result in response to the service request.

[0098] The service manager can also automatically trigger the shutdown of a specific service. For example, a service S1 might represent a production step MS1, which involves using a specific machine M to produce a first product G1. A service S2 might represent a production step MS2, which involves using the same specific machine M to produce a second product G2. Since machine M cannot be used to produce both the first product G1 and the second product G2 simultaneously, services S1 and S2 are mutually exclusive. When service S2 is requested, service S1 must be shut down before S2 is instantiated. The service manager can, for example, delay the instantiation of S2 until S1 has completed and then actively shut down S1 once product G1 has been produced.

[0099] The identification of dependencies in the dependency data structure 107 and / or the updating of the dependency data structure 107 can be performed using a deep search in the dependency tree, which represents all dependencies of all services registered with the service manager.

[0100] Fig. 4 represents the dependencies of several services according to one embodiment of the invention. According to the Fig. In the embodiment shown in Figure 4, each service is implemented as a Singleton class 404, which has a getInstance() method that returns a reference to the single instance object of the service in question (Singleton object). Specifically, the getInstance() method returns a reference to the interface 406, while the actual implementation 408 of the service is hidden. The Fig. The set of classes and interfaces shown in section 4 does not force the use of interfaces in the calling code, but the architecture provides a separation between the 406 interface of a particular service and the fact that it is treated as a singleton. The following... Fig. The separation shown in section 4 between the Singleton class 404, the interface 406, and the actual service implementation 408 is optional. The [details omitted] Fig. The software architecture shown in Figure 4 has the advantage of a clearer design, although it also allows for a combination of the 404 singleton, the 406 interface, and / or the 408 implementation within a single class. For example, the 404 singleton and the 406 interface, or the 406 interface and the 408 implementation, or all three could be combined. Separating the singleton, the interface, and the implementation allows for the use of different implementations for the 406 interface, which is treated as a singleton. This simplifies software testing. For example, if test objects ("model objects") are used instead of the actual implementation, the singleton can be used to test the different implementations. Fig. In the class design shown in Figure 4, different individual instances for the Singleton 404 are provided in the test phase and in the “real” use case.

[0101] Fig. Section 5 shows how the services and the service manager (whose classes and interfaces, such as in...) Fig. 4. This can be implemented in the overall system architecture. The "Singleton instance" 504, 406 knows the interface 508, 406 and the actual service implementation 514, 408. The Singleton instance 504, 406 is responsible for registering itself with the service manager 502 (which can also be called the "Singleton manager").

[0102] The service manager 502 must "know" each service in order to control its instantiation and shutdown according to the requirements of other services. Since the service manager 502 handles the instantiation of each service singleton 506, it must know which implementation class to instantiate to create the singleton object for each service interface 508. Furthermore, each service singleton 506 registers itself with the service manager 502 when, for example, it is loaded into the DBMS or when the DBMS is started.

[0103] The service manager 502 actually instantiates the service singletons 506, and the resulting instantiated single-service object is then stored in the singleton class 506 to complete the instantiation and allow subsequent access to and use of the service. Services (corresponding to singleton instances) can have various refinements, for example, for services that use or are implemented as a background job 512, and for those that do not (510).

[0104] In some implementations, this is achieved by creating a global single variable in the source code of the service class or another class that is functionally related to the service. For example, the global single variable can be created directly next to the code that defines the service's implementation (in the implementation's .cpp file). The global single variable can also be created within the code that defines the service to be registered (in the service's .cpp file). The global single variable represents a specific service that is to be registered with and managed by the service manager. When this variable is created during the startup of the DBMS or the DBMS plug-in or add-on (or during the loading of a library), the constructor of the variable's type or class is executed. The constructor handles the registration of the service represented by the variable with the service manager.Thus, the service manager knows the service object, and since the service-specific variable is a global variable, its existence is guaranteed at all times. The service manager can therefore access a specific service and its implementation to perform actions such as instantiation, shutdown, and querying the current status of the service using the specific implementation type.

[0105] In preferred embodiments, each service knows which other services it requires. For example, the implementation class 514 of a service knows which other services it accesses in its code because the class names of these other services are specified in the source code of implementation class 514. These other services are also referred to as the "required services" of that service.

[0106] When a service is automatically registered with the service manager, the service manager calls the `getRequiredServices()` function of the service being registered to infer the dependencies of any unregistered service during registration. In C++ code, the `getRequiredServices` function might take the following form, for example: `Class MyImplementation: public MyInterface { public: using ServicePrerequisites = services::ServicePrerequisites}`<Tracer, MyOtherServices> ; virtual auto doSomething()->void override {}};

[0107] "ServicePrerequisites" is a list of required services whose names can be checked by a compiler at compile time and optionally at design time. In addition to the `getRequiredServices` function, the service class can have methods that allow the service manager to initialize and shut down the service for which the service class represents and / or which it implements. The service class serves as a central entry point for a particular service, although some of the service's functions can actually be implemented in other classes.

[0108] In some implementations, the service dependencies automatically obtained by the service manager in response to the getRequiredServices() function call are used to automatically update a data structure containing all dependencies of all registered services.

[0109] In some implementations, different service implementations are registered with the service manager, and the service manager is automatically notified of any changes to the currently used service implementation during DBMS runtime. If the new implementation has no dependencies (as can be the case, for example, with model objects), it is alternatively possible to create the new single instance for a service and store it in the Singleton class 506 using a method such as `void setInstance(...)`. This method can be implemented through a Singleton service instance interface 504. This can be advantageous because no additional steps are necessary to ensure that all dependencies are up to date.

[0110] In some implementations, the service manager can determine during the instantiation phase that a particular service is already instantiated and is needed (e.g., due to an explicit user request or because another explicitly requested service depends on it). In this case, the service manager returns a reference or pointer to the existing service instance and does not create another instance of that service. Furthermore, when an already instantiated service object is passed to a calling process, the service manager does not check the dependencies of the requested service, since the fact that the service is already instantiated implies that all its dependencies must have already been handled.

[0111] According to embodiments, the registration of a new service with the service manager is performed automatically when the global variables for the new service's singleton service instance are created during process startup or when the relevant libraries loaded for each service are instantiated. During the registration of the new service, the service manager adds a representation of the new service to a data structure 107, which depicts dependencies between the new service and the services already registered. For example, the service dependencies can be represented in the form of a data structure containing one or more directed acyclic graphs, such as a tree or a set of trees. The new service is represented as an additional node in this graph, with the position of the new node in the graph representing the dependencies between the new service and the existing services.

[0112] In preferred embodiments, the service manager automatically analyzes the dependencies during the registration of a new service to determine whether the new service's dependencies contain any cyclic dependencies. For example, various tree traversal algorithms can be used to check whether the diagram is free of cycles. If a cyclic dependency is identified, the registration of the new service is terminated, and an error event and / or a warning message is generated. The new service is registered and optionally instantiated only if the analysis concludes that the new service and its dependencies do not create any cyclic dependencies.

[0113] Since the service manager does not know the order in which different services are registered, a registration might identify a required service that has not yet been registered with the service manager. In this case, the dependency check is delayed until the required service is also registered, and the service manager then automatically triggers the registration of the required service. Delaying the dependency check for potential recurring dependencies is not a problem, as the dependencies are automatically checked later once the required service is registered.

[0114] Additionally or alternatively, service dependency analysis is performed during the instantiation phase of a service. If dependency checking is performed during service instantiation rather than service registration, loading many different service libraries into the DBMS can be simplified. This is because the libraries can be loaded in any order without triggering an error event or warning message if they are loaded in a chronological order that does not match their logical dependencies. Since dependencies are only checked during service instantiation, the process of loading many different service libraries into the DBMS in any order is simplified, as the DBMS operator does not need to consider logical dependencies during the loading process.

[0115] Fig. Section 6 represents a portion of the source code of a service class that specifies a service implemented as a singleton. The code includes a service definition with the static methods `initialize()`, `shutdown()`, and `getPrerequisites()`, the latter representing a `getRequiredServices` function. A disadvantage of this implementation is that the required services are returned as strings and must be specified in the source code as (unwritten) strings that are not checked by a compiler. A better implementation option is described in Fig. 7 shown.

[0116] Fig. 7 represents a portion of the source code of a preferred representation of a service. Fig. 7A shows an abstract interface implemented by a service implementation class, whose source code is partially contained in Fig. Figure 7B illustrates this. The service is implemented as a Singleton, whose implementation must define a `getRequiredServices` method configured to return a compiler-checkable object of required services. This compiler-checkable object is referred to as "SingletonPrerequisites" in this example. The service manager initializes the service using methods of the `SingletonPrerequisites` method. Fig. 7A partially mapped abstract interface, a service, and shuts it down. These methods can be static methods like initialize(), shutdown(), inherited from the service class. A method that returns a compiler-checkable object instead of a string provides the technical advantage of greater robustness against typos, name duplications, and class name inconsistencies that can occur when a programmer specifies the required service classes in the source code of a service.

[0117] Fig. Figure 7C shows that the abstract interface can also have a `registerMySingleton{}` function configured to return a `RegisterSingleton` registration object. The registration object must be a defined global variable, for example, in a `.cpp` file. This ensures that a service can be registered before it is instantiated. The registration object can inform the service manager that it exists. The registration object links the service implementation to the interface but ensures complete encapsulation and obfuscation of the implementation.

[0118] The present invention may be a system, a method, and / or a computer program product. The computer program product may include a computer-readable storage medium (or media) containing computer-readable program instructions stored thereon to induce a processor to execute aspects of the present invention. The computer-readable storage medium may be a physical unit capable of containing and storing instructions for use by an instruction execution unit. The computer-readable storage medium may, for example, be an electronic storage unit, a magnetic storage unit, an optical storage unit, an electromagnetic storage unit, a semiconductor storage unit, or any suitable combination thereof, without limitation.A non-exhaustive list of more specific examples of computer-readable storage media includes the following: a portable computer floppy disk, a hard disk, RAM, ROM, erasable programmable read-only memory (EPROM or flash memory), static random-access memory (SRAM), a portable CD-ROM, a DVD (Digital Versatile Disc), a flash drive, a floppy disk, a mechanically coded unit such as punched cards or raised structures in a groove on which instructions are stored, and any suitable combination thereof. For the purposes of this text, computer-readable storage media shall not be understood as volatile signals per se, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through a waveguide or other transmission medium (e.g., a wireless communication device).Light pulses transmitted via an optical fiber cable or electrical signals transmitted via a wire. The computer-readable program instructions described herein can be downloaded from a computer-readable storage medium to respective data processing units or, via a network such as the internet, a local area network, a wide area network, and / or a wireless network, to an external computer or external storage device. The network may include copper transmission cables, optical fiber transmission lines, wireless transmission, routing computers, firewalls, switching units, gateway computers, and / or edge servers.A network adapter card or network interface in each data processing unit receives computer-readable program instructions from the network and forwards these instructions for storage in a computer-readable storage medium within the respective data processing unit. The computer-readable program instructions for performing operations of the present invention may be assembly instructions, ISA (Instruction Set Architecture) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state data, or either source code or object code written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Smalltalk, C++, and similar languages, as well as conventional procedural programming languages ​​such as the programming language "C" or similar programming languages.The computer-readable program instructions can be executed entirely on the user's computer, partially on the user's computer as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on the remote computer or server. In the latter case, the remote computer can be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection can be made to an external computer (for example, via the internet using an internet service provider).In some embodiments, electronic circuits, including, for example, programmable logic circuits, field-programmable gate arrays (FPGAs), or programmable logic arrays (PLAs), can execute the computer-readable program instructions by using state information from the computer-readable program instructions to personalize the electronic circuits to perform aspects of the present invention. Aspects of the present invention are described herein with reference to flowcharts and / or block diagrams of methods, devices (systems), and computer program products according to embodiments of the invention. It is noted that each block of the flowcharts and / or block diagrams, as well as combinations of blocks in the flowcharts and / or block diagrams, can be executed by means of computer-readable program instructions.These computer-readable program instructions can be provided to a processor of a general-purpose computer, a specialized computer, or other programmable data processing device to create a machine such that the instructions executed by the processor of the computer or other programmable data processing device produce a means of implementing the functions / steps specified in the block(s) of the flowchart and / or block diagram. These computer-readable program instructions can also be stored on a computer-readable storage medium capable of controlling a computer, programmable data processing device, and / or other units to operate in a particular way, such that the computer-readable storage medium on which instructions are stored has a manufactured product, including instructions specifying which aspects of the block(s) in the flowchart and / or block diagram are to be implemented.The computer-readable program instructions can also be loaded onto a computer, other programmable data processing device, or other unit to cause a series of process steps to be executed on the computer, other programmable device, or other unit in order to create a computer-implemented process, such that the instructions executed on the computer, other programmable device, or other unit implement the functions / steps specified in the block(s) of the flowcharts and / or block diagrams. The flowcharts and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention.In this context, each block in the flowcharts or block diagrams can represent a module, segment, or part of instructions containing one or more executable instructions for performing the specific logical function(s). In some alternative executions, the functions specified in the block may occur in a different order than shown in the figures. For example, two blocks shown consecutively may, in reality, be executed essentially simultaneously, or the blocks may sometimes be executed in reverse order depending on the corresponding functionality.It should also be noted that each block of the block diagrams and / or flowcharts, as well as combinations of blocks in the block diagrams and / or flowcharts, can be implemented by special hardware-based systems that perform the specified functions or steps, or execute combinations of special hardware and computer instructions.

[0119] A possible combination of the characteristics described above could be as follows: Feature combination FC1: a feature combination which has the features of claim 1. Feature combination FC2: a feature combination which has the features of claims 1 and 2. Feature combination FC3: a feature combination which has the features of claim 3 and any of the feature combinations FC1 and FC2. Feature combination FC4: a feature combination which has the features of claim 4 and any of the feature combinations FC1 to FC3. Feature combination FC5: a feature combination which has the features of claim 5 and any of the feature combinations FC1 to FC4. Feature combination FC3: a feature combination which has the features of claim 6 and any of the feature combinations FC1 to FC5. Feature combination FC7: a feature combination which has the features of claim 7 and any of the feature combinations FC1 to FC6. Feature combination FC8: a feature combination which has the features of claim 8 and any of the feature combinations FC1 to FC7. Feature combination FC9: a feature combination which has the features of claim 9 and any of the feature combinations FC1 to FC8. Feature combination FC10: a feature combination which has the features of claim 10 and any of the feature combinations FC1 to FC9. Feature combination FC11: a feature combination which has the features of claim 11 and any of the feature combinations FC1 to FC10. Feature combination FC12: a feature combination which has the features of claim 12 and feature combination FC11. Feature combination FC13: a feature combination which has the features of claim 13 and any of the feature combinations FC1 to FC12. Feature combination FC14: a feature combination which has the features of claim 14 and feature combination FC13. Feature combination FC15: a feature combination which has the features of claim 15 and any of the feature combinations FC1 to FC14. Feature combination FC16: a feature combination which has the features of claim 16 and any of the feature combinations FC1 to FC15. Feature combination FC17: a feature combination which has the features of claim 17 and any of the feature combinations FC1 to FC16. Feature combination FC18: a feature combination which has the features of claim 18 and any of the feature combinations FC1 to FC17. Feature combination FC19: a feature combination which has the features of claim 19 and any of the feature combinations FC1 to FC18.< / catalogmanager> < / tracer> < / configurator>

Claims

[1] Computer-implemented method, comprising: Providing a service manager that interacts with a database management system (DBMS), where the DBMS is a software application designed to enable the definition, creation, querying, updating, and management of databases; Automatic and dynamic registration of multiple DMBS services with the service manager during the DBMS runtime, wherein: Each of the multiple DBMS services processes data that is stored in a database managed by the DBMS; Each of the multiple DBMS services is implemented as a singleton, where a singleton is a software object implemented in such a way that only one instance of a specific type of software object can be instantiated at a time; and A first service among several DBMS services allows the service manager to check whether a cached singleton instance has already been initialized; and Managing dependencies between the multiple registered DBMS services by the service administrator, wherein: The dependencies are managed based on the source code of the DBMS service, which specifies dependency services required by the DBMS service; The class name of each dependency service is automatically converted into a string that is used by the service manager as an argument for managing the service; The dependencies of the services are represented in a single data structure and are identified and updated during the runtime of the DBMS using a deep search in a dependency tree that represents dependencies of the DBMS services registered with the service manager; the global variable represents a specific service that is to be registered with and managed by the service administrator; and Managing dependencies also features: in response to the creation of the global variable, execution of a constructor of a type associated with the global variable; and Identifying cyclic dependencies based on a representation of the dependencies of the DBMS services in the form of a directed acyclic graph. [2] Computer-implemented method according to claim 1, wherein the dependency management comprises instantiating the DBMS services according to the dependencies, such that all DBMS services required by a particular DBMS service are already instantiated when the particular DBMS service is instantiated by the service manager. [3] Computer-implemented method according to claim 1, wherein at least some of the DBMS services represent steps within a workflow of a product manufacturing process and wherein at least some dependencies represent equipment dependencies, workflow dependencies, material dependencies and / or supply dependencies of physical objects involved in the product manufacturing process. [4] Computer-implemented method according to claim 1, wherein the dependency management comprises shutting down one or more of the DBMS services according to the dependencies, wherein, prior to shutting down any one of the DBMS services, the shutdown of a first DBMS service is delayed until all DBMS services dependent on the first DBMS service have been shut down. [5] Computer-implemented method according to claim 1, wherein each of the DBMS services is implemented according to a singleton design pattern. [6] Computer-implemented method according to claim 1, further comprising adding an additional DBMS service to the DBMS, which comprises: Register the additional DBMS service with the service administrator during the DBMS runtime; Update the dependencies of the DBMS services so that the dependencies represent the dependencies of the existing and the additional DBMS service. [7] Computer-implemented method according to claim 1, wherein the registration of the DBMS services with the service administrator is implemented in the form of a decentralized registration process. [8] Computer-implemented method according to claim 1, wherein each of the multiple DBMS services implements an interface comprising a method for registering the DBMS service with the service administrator. [9] Computer-implemented method according to claim 1, wherein each of the multiple DBMS services has an instantiateService function and a shutdownService function, wherein the service manager can access the instantiateService function and the shutdownService function, wherein the method further comprises: The service manager uses the instantiateService and shutdownService functions of multiple DBMS services to dynamically orchestrate the instantiation and shutdown of multiple DBMS services according to their dependencies. [10] Computer-implemented method according to claim 1, wherein each of the multiple DBMS services has a getRequiredServices function, wherein the service manager can access the getRequiredServices function, wherein the getRequiredServices function is configured to return the names of one or more required DBMS services, wherein each required DBMS service is a DBMS service that must be instantiated before the DBMS service that has the getRequiredServices function is instantiated, and wherein the registration of each of the multiple DBMS services includes: Calling the getRequiredServices function of the DBMS service to be registered by the service administrator; Automatically checking whether the names of the required DBMS services returned by the getRequiredService function identify an already registered DBMS service; and Automatic registration by the service manager of each DBMS service returned by the getRequiredService function that has not yet been registered. [11] Computer-implemented method according to claim 10, wherein the getRequiredServices function is configured upon its invocation to: - to convert the class names of each of the one or more required DBMS services into a corresponding string, - to convert one or more strings into a compiler-testable object; and - to return the compiler-verifiable object to the service manager that called the getRequiredServices function. [12] Computer-implemented method according to claim 1, wherein at least one of the multiple DBMS services specifies the one or more other DBMS services required by the at least one DBMS service, wherein the specification of the one or more DBMS services is in the form of a list of class names which are checked by a compiler during compilation time, wherein an error is triggered if the DBMS service class has a name of a required DBMS service and the compiler cannot identify a class whose name matches the name of the required DBMS service. [13] Computer-implemented method according to claim 12, wherein the name of the required DBMS service is highlighted in the program code of the DBMS service class during the design time in response to the fact that the DBMS service class has a name of a required DBMS service and the compiler cannot identify a class whose name matches the name of the required DBMS service. [14] Computer-implemented method according to claim 1, further comprising: Automatic identification by the service administrator of one or more other DBMS services required by the DBMS service being registered during the registration of the DBMS services with the service administrator; Updating the dependencies between the multiple registered DBMS services, the DBMS service to be registered, and the DBMS services identified during the registration of the one DBMS service, so that the dependencies also include the dependencies of the DBMS service to be registered and the other required DBMS services. [15] Computer-implemented method according to claim 1, wherein the service manager is a component of an application implemented as a selection from the group consisting of: an extension application of the DBMS and an integral component of the DBMS. [16] Computer-implemented method according to claim 1, further comprising: Receiving a service request for a specific DBMS service by the DBMS; The service administrator identifies the requested DBMS service among the multiple DBMS services; The service administrator must identify one or more of the other registered DBMS services required by the requested DBMS service; and for each of the identified one or more other DBMS services: in response to the fact that this other DBMS service is not yet instantiated, to instantiate this other DBMS service. [17] Computer-readable storage medium containing program instructions, wherein the program instructions are executable by a processor to cause the processor to perform a procedure comprising: Providing a service manager that interacts with a database management system (DBMS), where the DBMS is a software application designed to enable the definition, creation, querying, updating, and management of databases; Automatic and dynamic registration of multiple DMBS services with the service manager during the DBMS runtime, wherein: Each of the multiple DBMS services processes data that is stored in a database managed by the DBMS; Each of the multiple DBMS services is implemented as a singleton, where a singleton is a software object implemented in such a way that only one instance of a specific type of software object can be instantiated at a time; and A first service among several DBMS services allows the service manager to check whether a cached singleton instance has already been initialized; and Managing dependencies between the multiple registered DBMS services by the service administrator, wherein: The dependencies are managed based on the source code of the DBMS service, which specifies dependency services required by the DBMS service; The class name of each dependency service is automatically converted into a string that is used by the service manager as an argument for managing the service; The dependencies of the services are represented in a single data structure and are identified and updated during the runtime of the DBMS using a deep search in a dependency tree that represents dependencies of the DBMS services registered with the service manager; the global variable represents a specific service that is to be registered with and managed by the service administrator; and Managing dependencies also features: in response to the creation of the global variable, execution of a constructor of a type associated with the global variable; and Identifying cyclic dependencies based on a representation of the dependencies of the DBMS services in the form of a directed acyclic graph. [18] Computer system comprising: a database management system, DBMS, where the DBMS is a software application designed to enable the definition, creation, querying, updating, and management of databases; a service administrator who is functionally connected to the DBMS; and where the service administrator is configured to: automatic and dynamic registration of multiple DMBS services with the service manager during the DBMS runtime, wherein: Each of the multiple DBMS services processes data that is stored in a database managed by the DBMS; Each of the multiple DBMS services is implemented as a singleton, where a singleton is a software object implemented in such a way that only one instance of a specific type of software object can be instantiated at a time; and A first service among several DBMS services allows the service manager to check whether a cached singleton instance has already been initialized; and Managing dependencies between the multiple registered DBMS services by the service administrator, wherein: The dependencies are managed based on the source code of the DBMS service, which specifies dependency services required by the DBMS service; The class name of each dependency service is automatically converted into a string that is used by the service manager as an argument for managing the service; The dependencies of the services are represented in a single data structure and are identified and updated during the runtime of the DBMS using a deep search in a dependency tree that represents dependencies of the DBMS services registered with the service manager; the global variable represents a specific service that is to be registered with and managed by the service administrator; and Managing dependencies also features: in response to the creation of the global variable, execution of a constructor of a type associated with the global variable; and Identifying cyclic dependencies based on a representation of the dependencies of the DBMS services in the form of a directed acyclic graph.

Images