Patent Application
20080307211
1. Field of the Invention
The present invention generally relates to on-demand operating environments and, in particular, to adapting the configuration of these environments to changing business conditions.
2. Background Description
The modern business environment requires computers and computing services, but competitive pressures place a premium on adapting these services to changing conditions. Investments in these services are placing an increasing drain on enterprises whose primary business is not computers or computing services. Consequently, a market has developed for providing computing services to such enterprises “on demand”, that is, on a pay-as-you-go basis, without an investment burden and without the risks of maintaining that investment.
In order to serve this developing market, an On Demand Operating Environment (ODOE) must be constructed and configured. Furthermore, ODOE will become more complex as it is being adopted to serve as a viable platform for developing and deploying business solutions for enterprises. Customers will expect not only to be provisioned with on-demand services; they will also expect to be able to change the behavior of their solution in an on-demand fashion.
That is, the same enterprise that will be attracted to having their computing services be provided by someone outside the enterprise will, nonetheless, want those services to be adaptable and responsive to the changing business needs of the enterprise. However, this adaptability and responsiveness was often the primary reason for the enterprise to provide its own computing services. It is not at all clear in the prior art how the enterprise can have it both ways: outsource the provisioning of computing services, and at the same time retain a sufficiently tight coupling to the adaptive levers of these services so that the services efficiently respond to the changing business needs of the enterprise as viewed by the business managers who have outsourced computing services. Therefore, an important aspect of a resolution of these problems with the prior art will be an ability to dynamically configure business solutions that are built on ODOE.
Current approaches do not provide a satisfactory solution for this requirement. The configuration of business solutions within an enterprise refers to the setting of parameters for each component in a business solution, from high level application programs to low level communication and hardware services. A business solution may be understood as a multilayered system of interrelated components. Because the components are interrelated the configuration of one component must take account of the configuration of other components which are related. Changes to a parameter setting for one component may affect or depend upon parameter settings for other components. The prior art still takes a traditional, labor-intensive and static approach to configuration of these interrelated components of a business solution. Variable parameters are iteratively adjusted and tested until satisfactory performance is obtained. By “static” is meant that the configuration stays the same until there comes a time when it must be redone in the same labor intensive fashion.
This type of configuration approach is error prone and can easily introduce inconsistencies among different solutions using different configuration properties. Current implementations of this approach tend to be low-level and dependent upon administrators to bridge the semantic gaps between new business requirements and a system-level configuration. Business users (e.g. managers of the business where computing services have been outsourced) are not able to inject their changes into ODOE and sense the effects of these changes in a reasonably prompt manner.
Business users need responsiveness with a short turn around time, if not real time, and current approaches to the need for prompt changes in the configuration of business solutions are insufficiently responsive. Current configuration mechanisms, e.g., such as Web Application Services (WAS) Websphere Common Configuration Model (WCCM), do not support consistency checking and a two-phase commitment protocol to guarantee the soundness and completeness of configuration activities towards ODOE. What is needed is a comprehensive approach to customizing business solutions that are built upon an ODOE. What is needed is an improved and simplified user experience for deploying, configuring and customizing business centric solutions on ODOE.
It is therefore an object of the present invention to provide a comprehensive approach to customizing business solutions that are built upon an ODOE.
Another object of the invention is an improved and simplified user experience for deploying, configuring and customizing business centric solutions on ODOE.
It is also an object of the invention ensure that the results of changes in the configuration can be sensed by business users promptly, if not in real time.
Yet another object of the invention is to provide a systematic method of configuring ODOE and business solutions built upon it in a dynamic fashion.
A further object of the invention is to provision a business-level configuration specification named On Demand Configuration Language (ODCL).
Yet another object of the invention is to capture business consistency constraints in ODCL and transform these into low-level configuration constraints or parameters, which can be realized via either configuration rules or code generation.
Another object of the invention is to provide a two phase configuration commitment protocol to ensure the consistency of configuration properties or parameters within ODOE and hosted business solutions.
The invention provides a systematic method of dynamically configuring ODOE and the business solutions built upon it. The invention improves on the prior art by providing a method of transforming from high level service configurations (i.e. at the level familiar to the business user) down through the lowest implementation service levels without cracks or holes in the complete configuration. The dynamic aspect of this configuration method means that the system can be configured “on-the-fly”, without shutting down the system. The invention uses an On Demand Configuration Language (ODCL) to develop a business level configuration specification. This language allows the business user to specify requirements for the ODOE in terms of the business solutions needed for the business to be effective in the marketplace. Business consistency constraints are captured in ODCL, and these are then transformed to low-level configuration constraints or parameters, which can be realized through configuration rules or code generation. A two phase configuration commitment protocol is provided to ensure the consistency of configuration properties within ODOE and hosted business solutions.
One aspect of the invention is a method for dynamic configuration of an On Demand Operating Environment (ODOE) for a business by a number of steps. The first step is provisioning a configuration specification for the purpose of capturing business consistency constraints, and also for the purpose of using these consistency constraints to set configuration parameters downstream of the business consistency constraints as viewed by business users. In this manner configuration parameters are established for services provided to the business via the ODOE, which may also include any business solutions (e.g. implemented as software applications) that may be hosted by the ODOE.
The second step is capturing from managers of the business consistency constraints of the business in a language defined by the configuration specification. In a third step, the configuration specification is used to transform the consistency constraints into configuration parameters for the downstream services and hosted business solutions, where the configuration parameters for at least one of the services or business solutions is dependent upon configuration parameters for another of the services or business solutions. A fourth step is controlling implementation of these configuration parameters to ensure consistency among those that are dependent.
Another aspect of the invention is using the configuration language to synthesize configuration agents for configuring the downstream services and business solutions in accordance with the business consistency constraints, and controlling operation of these configuration agents to execute a coordinated configuration of the downstream services and business solutions in accordance with the consistency constraints.
A further aspect of the invention is monitoring performance indicators that measure operation of the services and the business solutions in relation to the consistency constraints, detecting changes in these performance indicators, and using the detected changes to trigger a repetition of the coordinated configuration. This is how the configuration is maintained dynamically as business conditions change within a given set of consistency constraints, or when the business users change the consistency constraints. Because the configuration parameters for the downstream services and business solutions are interdependent, it is another aspect of the invention to execute the coordinated configuration using a two-phase commitment protocol controlled by a configuration manager. A two-phase commitment protocol, as known in the prior art, is a distributed algorithm that lets all nodes in a distributed system agree to commit a transaction. A coordinator sends a “query to commit” message to all nodes, each of which executes the transaction, but without releasing blocked resources. This permits each node to undo the transaction. The coordinator waits for a response from each node, indicating that the transaction succeeded or failed. In the second phase, the coordinator sends a “commit” message if the response from all nodes is that the transaction succeeded, otherwise sending an “abort” message. Each node then releases any blocked resources upon receiving a “commit” message, and backs out of the transaction before releasing blocked resources if the received message from the coordinator is “abort”. In the present invention, the plurality of configuration agents and configuration points, where the configuration parameters applied by one configuration agent depend upon another, provide an analogy to distributed nodes.
Yet another aspect of the invention is that the downstream services and business solutions are organized into a plurality of layers. This is done to facilitate provisioning of the configuration specification and also to facilitate controls that enable consistent implementation the interdependent configuration parameters. In a further aspect of the invention, the performance indicators whose changes are monitored and used to trigger re-configurations dynamically are generated by algorithms, which in turn operate upon correlations generated when rules expressing the business consistency constraints are applied to an event stream. The events in this stream can be events observed by business users and placed in the stream of events by data entry, events output by learning algorithms monitoring oral or written communications of business users, and events reported by monitors within a runtime ODOE.
The foregoing and other objects, aspects and advantages will be better understood from the following detailed description of a preferred embodiment of the invention with reference to the drawings, in which:
Referring now to the drawings, and more particularly to
Enterprise Service Bus 160 is the communication channel among services in the ODOE 140, and is a configuration target. Mediation, Messaging, Events 162 represent the mechanism enabling communication among services in the ODOE 140. They are configuration targets as well. Business Connections 163 represent business level connection interfaces (as opposed to system-level connection interfaces) and are configuration targets. Layer 170 provides customized services for customers, which are also target services to be configured by the invention. Business Services 172 (e.g. YouTube, Bicycle Service, etc.), Application Services 173 (e.g. Email Services, Version Control, etc.), and Infrastructure Services 174 (e.g. Network Services, Storage Services, etc.) are also target services to be configured.
These layers are illustrative only, and in practice there may be many more layers, the layers being defined so as to provide a robust organization of the interrelated components of the business solution. The structure of these layers is, first of all, adapted to provide a transformation from high level services and corresponding configuration parameters down to the lowest IT implementation levels in a manner that is consistent and complete. By breaking this transformation down into a sequence of stages at successive layers, a complex and difficult process is made manageable and cracks and holes are minimized in the transformation of high level parameters into low level configuration parameters. Further, the collection of layers is not only adapted to show interrelationships between and among component services but is also structured to remain adapted to these interrelationships over a wide range of changes in component parameters as the configuration is dynamically adjusted.
On Demand Configuration Language (ODCL) 110 is a model repository that contains configuration models required for configuring target systems and services. It is customized by a customization editor 111 to serve the needs of a particular business. It is here that the perspective of the business user 105 is addressed. The business user 105 typically is conversant with the business operations that make up the business processes that produce the products and services of the business, but is not knowledgeable about operation of the systems and components (arrayed in exemplar layers 140, 160, and 170) upon which those business operations and processes rely.
It is therefore necessary to provide a mechanism for translating user requirements and configuration decisions with respect to the business operations and processes about which the user is knowledgeable into corresponding requirements of the systems and components about which the business user 105 is not knowledgeable. This is the function of the customization editor 111, a configuration editor which uses an observation model (OM) 112, a service meta-model 113 and a platform meta-model 114 to define business level configuration models for ODCL 110. Observation model 112 describes the monitored attributes of target systems and services; service meta model 113 describes the interfaces and semantics of target services; and platform meta model 114 describes the interfaces and semantics of target systems. The observation model 112 is itself subject to revision by OM editor 115, which is used by the system administrator to define observation models. OM editor 115 also configures 116 and compiles 117 observation model data for use by a monitor 141, such as IBM's WBI monitor, that monitors attributes of ODOE processes.
The ODCL 110 is used to develop model synthesizers 120, which take configuration models at the business level (generated by business user 105 using customization editor 111) and convert them into system level configuration models. Each configuration agent 130 takes a system configuration model and applies it to target systems and services via configuration points 135, which serve as a “façade” for the target systems and services to be configured. Configuration agents 130 also coordinate all configuration tasks including the timing of configuration of the physical services and systems.
From the perspective provided by the invention, the business operations and processes familiar to the business user 105 are described in terms of business services which can be knowledgeably configured by the business user 105. These business services are described within ODCL 110, which also describes the relationships between and among these business services and the ODOE services which support these business services. These ODOE support services are particular to the business solution provided by the business, and would be included in a top layer (e.g. ODOE layer 140).
For example, if a business manufactures bicycles the business services familiar to the business user 105 would include, for example, a bicycle parts ordering service, a bicycle parts assembly service, and a bicycle product delivery service, each of which might be operated or controlled by employees of the business. These services would be configured in terms of parameters familiar to, and determined by, the business user 105, such as the number of bicycles of a particular model to be produced per month, the quality and cost ranges of parts on a bicycle parts list, and the assembly time and order of assembly for the various parts. These services may in turn be supported by ODOE services, such as a database service for tracking bicycle orders and fulfillment, an Internet ordering service for procurement of parts, and an assembly monitoring service for tracking the time required to assemble the various parts. If automated equipment is used to assemble the bicycles, ODOE services might include a robotic maintenance service for monitoring and managing performance of the equipment. In turn, these ODOE services will require services from other levels of the arrayed component services, such as a messaging service 162 to carry messages from sensors at a bicycle assembly line over an enterprise service bus 160 to support the assembly monitoring service. Each of these support services will have their own configurable parameters, and the ODCL 110 will use these parameters to describe the relationships between these services.
Now turning to
It should also be noted that
Observation model situation rule meta model 212 defines what is to be monitored and the corresponding metrics for monitoring, drawing upon observation models 112. It is fed by situation rules 222, which provide sequencing rules for the order in which components are configured, so that there are no surprises. Situation rules 222 in turn draws upon a repository of observation model instances 252, that is, monitoring data, so that rule meta model 212 is in compliance with the observed monitoring data. Also, the metrics used in situation rules 222 determine when control of the configuration process is to be moved from one configuration point 135 to another.
Situation rule meta model 212 feeds meta model mapping module 214 that describes the configuration mechanism and maps the sequence control rules into the platform meta model 216 of the configuration target (here, the ACT Rule Meta Model). The meta model mapping module 214 also feeds a particular model synthesizer 220 which generates a configuration model 225 for a particular component. Model synthesizer 220 is in turn fed by information from configuration policy 226 and the platform meta model 224 pertaining to the particular component (e.g. IBM's ACT rules engine, as shown) being targeted for configuration. The platform meta model 224 draws upon platform meta models 114, which describe the configuration mechanism and contains detailed information about the platform that the ODOE is operating on, such as what kind of networks and databases are being used. Rules and configuration data for the particular component are generated by the configuration model 225, which produces a configuration agent 230 which actually configures (at configuration point 235) the particular target configuration component at a level of the configuration structure (e.g. ACT 245 within ODOE 240). Note that the configuration model 225 is checked for compliance against the sequence control rules of platform meta model 216. Note also that the configuration level (e.g. ODOE 240) must be instrumented to be configurable via configuration point 235.
The configuration agents (130 in
The executable code generated by configuration injection code generator 340 is encapsulated in a configuration agent whose operation is directed by configuration manager 375, which is a part of ODOE runtime 370. Collectively, consistency constraints 350, configuration objects 355, injection objects 360 and configuration list 365 comprise the knowledge base of the encapsulated executable code which does the work of configuration. Configuration manager 375 is able to direct the sequencing of configuration agents via policy runtime 380 by being aware of consistency constraints 350. In the implementation shown, policy runtime 380 is included in the ACT component.
While the invention has been described in terms of a single preferred embodiment, those skilled in the art will recognize that the invention can be practiced with modification within the spirit and scope of the appended claims.
