WO2009082385A1 - Interface visuelle pour un système pour déployer un processus informatisé sur une infrastructure partagée - Google Patents

Interface visuelle pour un système pour déployer un processus informatisé sur une infrastructure partagée Download PDF

Info

Publication number
WO2009082385A1
WO2009082385A1 PCT/US2007/088334 US2007088334W WO2009082385A1 WO 2009082385 A1 WO2009082385 A1 WO 2009082385A1 US 2007088334 W US2007088334 W US 2007088334W WO 2009082385 A1 WO2009082385 A1 WO 2009082385A1
Authority
WO
WIPO (PCT)
Prior art keywords
model
infrastructure
design
changes
business process
Prior art date
Application number
PCT/US2007/088334
Other languages
English (en)
Inventor
Nigel Edwards
Sven Graupner
John Manley
Jerome Rolia
Bryan Stephenson
Lawrence Wilcock
Original Assignee
Hewlett-Packard Development Company, L.P.
Belrose, Guillaume Alexandre
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Hewlett-Packard Development Company, L.P., Belrose, Guillaume Alexandre filed Critical Hewlett-Packard Development Company, L.P.
Priority to PCT/US2007/088334 priority Critical patent/WO2009082385A1/fr
Publication of WO2009082385A1 publication Critical patent/WO2009082385A1/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/06—Resources, workflows, human or project management; Enterprise or organisation planning; Enterprise or organisation modelling

Definitions

  • the invention relates to methods of modelling a process such as a business process having a number of computer implemented steps using software application components, to enable automatic deployment on computing infrastructure, and to corresponding apparatus and software.
  • Models of higher level entities need to be recursive in the sense of containing or referring to lower level entities used or required to implement them (for example a virtual machine VM, may operate faster or slower depending on what underlying infrastructure is currently used to implement it (for example hardware partition nPAR or virtual partition vPAR, as will be described in more detail below).
  • This means a model needs to expose the underlying configurability of the next generation computer fabrics - an nPAR consists of a particular hardware partition.
  • an IT system with all of its hardware components, hosts, switches, routers, desktops, operating systems, applications, business processes, etc. may include millions of objects. It may be difficult to employ any manual or automated method to create a monolithic model of such a large number of components and their relationships. This problem is compounded by the typical dynamic nature of IT systems having frequent adds/moves/changes. Secondly, there is no abstraction or hiding of details, to allow a processing function to focus on the details of a particular set of relevant components while hiding less relevant component details. Thirdly, it may be impractical to perform any processing on the overall system because of the number of components involved.”
  • An object is to provide improved apparatus or methods.
  • the invention provides:
  • Such customisation is traditionally too expensive or too slow for service providers to provide manually. It can become more cost effective and faster to provide by means of the automation of the design of the computing infrastructure for the process. This helps to reduce the need for scarce knowledgeable human operators. Shared infrastructure helps reduce costs and enables more rapid changes in scale as resources can be reallocated.
  • Embodiments of the invention can have any additional features, without departing from the scope of the claims, and some such additional features are set out in dependent claims and in embodiments described below.
  • Another aspect provides software on a machine readable medium which when executed carries out the above method.
  • Another aspect provides a method of using a visual interface to a system for deploying a computer based process on shared physical infrastructure of a service provider, the process having a number of functional steps, the system having: a model generating part for generating a software model of the process, suitable for automated deployment on the shared physical infrastructure, to meet given non functional requirements, by generating for the model a representation of an arrangement of software application components, for carrying out the functional steps, and a design of computing infrastructure, for running the software application components, the method having the steps of: using an operator terminal to view a three dimensional view of at least the computing infrastructure design of the model, causing changes to the model by inputting actions associated with entities in the three dimensional view, for translation into changes to corresponding parts of the model, and causing the system to carry out the automated deployment of the process based on the model, on the shared physical infrastructure.
  • Another aspect provides a system for deploying a computer based process on shared physical infrastructure of a service provider, the process having a number of functional steps, the system having: a model generator part for generating a software model of the process, suitable for automated deployment on the shared physical infrastructure, to meet given non functional requirements, by generating for the model a representation of an arrangement of software application components, for carrying out the functional steps, and a design of computing infrastructure, for running the software application components, the system also having; a three dimensional visual rendering part coupled to the model and arranged to generate a three dimensional view of at least the computing infrastructure design of the model for operators, an input interpreter coupled to the model generator to enable operator input to the model generation by translating operator inputs associated with the three dimensional view into changes to corresponding parts of the model, and a deployment part for carrying out the automated deployment of the process based on the model, on the shared physical infrastructure.
  • a model generator part for generating a software model of the process, suitable for automated deployment on the shared physical infrastructure, to meet given non functional requirements, by
  • Figure 1 shows a schematic view of an embodiment showing models, adaptive infrastructure and a management system
  • FIG. 2 shows a schematic view of some operation steps by an operator and by the management system, according to an embodiment
  • Figure 3 shows a schematic view of some of the principal actions and models according to an embodiment
  • Figure 4 shows a schematic view of a sequence of steps from business process to deployed model in the form of a model information flow, MIF, according to another embodiment
  • FIG. 5 shows a sequence of steps and models according to another embodiment
  • Figure 6 shows steps in deriving a grounded model according to an embodiment
  • Figure 7 shows an arrangement of master and slave application servers for a distributed design, according to an embodiment, Figure 8 shows parts of a master application server for the embodiment of figure 7,
  • Figure 9 shows an arrangement of virtual entities on a server, for use in an embodiment
  • Figure 10 shows an example of a sales and distribution business process (SD)
  • Benchmark Dialog Steps and Transactions Figure 11 shows an example Custom Model Instance for SD Benchmark
  • Figure 12 shows a class diagram for an Unbound Model Class
  • Figure 13 shows an example of a template suitable for a decentralised SD example
  • Figure 14 shows a Grounded Model instance for a decentralized SD
  • Figure 15 shows another example of a template, suitable for a centralised secure SD example
  • Figure 16 shows an overview of an embodiment having a 3-D visual interface for the operator according to an embodiment
  • Figure 17 shows some of the principal steps according to an embodiment
  • Figure 18 shows an overview of an architecture of a system according to an embodiment
  • Figure 19 shows example of a 3D view of part of a model
  • Figures 20, 21 and 22 show steps of methods according to embodiments .
  • non-functional requirements can encompass how well the functional steps are achieved, in terms such as performance, security properties, cost, availability and others. It is explained in Wikipedia (http://en.wikipedia.org/wiki/Non- functional requirements) for non-functional requirements as follows- "In systems engineering and requirements engineering, non-functional requirements are requirements which specify criteria that can be used to judge the operation of a system, rather than specific behaviors. This should be contrasted with functional requirements that specify specific behavior or functions. Typical non-functional requirements are reliability, scalability, and cost. Non-functional requirements are often called the ilities of a system.
  • Deployed is intended to encompass a modelled business process for which the computing infrastructure has been allocated and configured, and the software application components have been installed and configured ready to become operational. According to the context it can also encompass a business process which has started running.
  • suitable for automated deployment can encompass models which provide machine readable information to enable the infrastructure design to be deployed, and to enable the software application components to be installed and configured by a deployment service, either autonomously or with some human input guided by the deployment service.
  • business process is intended to encompass any process involving computer implemented steps and optionally other steps such as human input or input from a sensor or monitor for example, for any type of business purpose such as service oriented applications, for sales and distribution, inventory control, control or scheduling of manufacturing processes for example. It can also encompassr any other process involving computer implemented steps for non business applications such as educational tools, entertainment applications, scientific applications, any type of information processing including batch processing, grid computing, and so on.
  • One or more business process steps can be combined in sequences, loops, recursions and branches to form a complete Business Process.
  • Business process can also encompass business administration processes such as CRM, sales support, inventory management, budgeting, production scheduling and so on, and any other process for commercial or scientific purposes such as modelling climate, modelling structures, or modelling nuclear reactions.
  • application components is intended to encompass any type of software element such as modules, subroutines, code of any amount usable individually or in combinations to implement the computer implemented steps of the business process. It can be data or code that can be manipulated to deliver a business process step (BPStep) such as a transaction or a database table.
  • the Sales and Distribution (SD) product produced by SAP is made up of a number of transactions each having a number of application components for example.
  • unbound model is intended to encompass software specifying in any way, directly or indirectly, at least the application components to be used for each of the computer implemented steps of the business process, without a complete design of the computing infrastructure, and may optionally be used to calculate infrastructure resource demands of the business process, and may optionally be spread across or contain two or more sub-models.
  • the unbound model can also specify the types or versions of corresponding execution components such as application servers and database servers, needed by each application component, without specifying how many of these are needed for example.
  • “grounded model” is intended to encompass software specifying in any way, directly or indirectly, at least a complete design of the computing infrastructure suitable for automatic deployment of the business process. It can be a complete specification of a computing infrastructure and the application components to be deployed on the infrastructure.
  • bound model encompasses any model having a binding of the Grounded Model to physical resources.
  • the binding can be in the form of associations between ComputerSystems, Disks, StorageSystems, Networks, NICS that are in the Grounded Model to real physical parts that are available in the actual computing infrastructure
  • infrastructure design template is intended to encompass software of any type which determines design choices by indicating in any way at least some parts of the computing infrastructure, and indicating predetermined relationships between the parts. This will leave a limited number of options to be completed, to create a grounded model.
  • These templates can indicate an allowable range of choices or an allowable range of changes for example. They can determine design choices by having instructions for how to create the grounded model, or how to change an existing grounded model.
  • computing infrastructure is intended to encompass any type of resource such as hardware and software for processing, for storage such as disks or chip memory, and for communications such as networking, and including for example servers, operating systems, virtual entities, and management infrastructure such as monitors, for monitoring hardware, software and applications.
  • AU of these can be "designed" in the sense of configuring and/or allocating resources such as processing time or processor hardware configuration or operating system configuration or disk space, and instantiating software or links between the various resources for example.
  • the resources may or may not be shared between multiple business processes.
  • the configuring or allocating of resources can also encompass changing existing configurations or allocations of resources.
  • Computing infrastructure can encompass all physical entities or all virtualized entities, or a mixture of virtualized entities, physical entities for hosting the virtualized entities and physical entities for running the software application components without a virtualized layer, "parts of the computing infrastructure" is intended to encompass parts such as servers, disks, networking hardware and software for example.
  • AlService is an information service that users consume. It implements a business process.
  • Application Constraints Model can mean arbitrary constraints on components in the Customized Process, Application Packaging and Component Performance
  • MEF progresses from left to right.
  • ApplicationExecutionComponent is for example a (worker) process, thread or servlet that executes an Application component.
  • An example would be a Dialog Work
  • ApplicationExecutionService means a service which can manage the execution of
  • Application Packaging Model is any model which describes the internal structure of the software: what products are needed and what modules are required from the product, and is typically contained by an unbound model.
  • Application Performance Model means any model which has the purpose of defining the resource demands, direct and indirect, for each Business process (BP) step. It can be contained in the unbound model.
  • Component Performance Model can mean any model containing the generic performance characteristics for an Application Component. This can be used to derive the Application Performance Model (which can be contained in the unbound model), by using the specific Business process steps and data characteristics specified in the
  • Model means a customized general model of a business process to reflect specific business requirements.
  • Deployed Model means a bound model with the binding information for the management services running in the system.
  • Candidate Grounded Model can be an intermediate model that may be generated by a tool as it transforms the Unbound Model into the Grounded Model.
  • Grounded Component can contain the installation and configuration information for both Grounded Execution Components and Grounded Execution Services, as well as information about policies and start/stop dependencies.
  • Grounded Execution Component can be a representation in the Grounded Model of a (worker) process, thread or servlet that executes an Application Component.
  • Grounded Execution Service is a representation in the Grounded Model of the entity that manages the execution of execution components such as Work Processes, servlets or database processes.
  • “Infrastructure Capability Model” can be a catalogue of resources that can be configured by the utility such as different computer types and devices such as firewalls and load balancers.
  • MIF Model Information Flow
  • MIF Model Information Flow
  • the present invention can be applied to many areas, the embodiments described in detail can only cover some of those areas. It can encompass modeling dynamic or static systems, such as enterprise management systems, networked information technology systems, utility computing systems, systems for managing complex systems such as telecommunications networks, cellular networks, electric power grids, biological systems, medical systems, weather forecasting systems, financial analysis systems, search engines, and so on.
  • An object-oriented paradigm can be used, in which the system components are modeled using objects, and relationships between components of the system are modeled either as attributes of an object, or objects themselves.
  • Other paradigms can be used, in which the model focuses on what the system does rather than how it operates, or describes how the system operates.
  • a database paradigm may specify entities and relationships.
  • Formal languages for system modelling include text based DMTF Common Information Model (CIM), Varilog, NS, C++, C, SQL, or graphically expressed based schemes.
  • models of the IT system and the applications running on it are created (or updated if they already exist) and in turn deployed on shared infrastructure in a data centre.
  • Physical machines get provisioned, virtual machines (vm) created and software deployed and configured in accordance to the building plans drawn in the tool.
  • the tool can be used to represent the real time state of the system, showing for instance network data packets being transmitted, operating system processes memory growing or shrinking or virtual machines being migrated between physical hosts.
  • the tool can also allow for a 3D representation and control of higher level concepts, such as business logic and business processes running inside the application servers.
  • the tool supports the execution of management operations. Actions triggered on the in-game building blocks to affect their properties (appearance, shape, location) are translated into management commands that modify the state of the running system.
  • a vm can be represented in the tool as a cube. Stretching the cube to make it grow is translated as growing the amount of memory made available to the vm in the data centre.
  • the tool can map the components of IT systems into familiar architectural terms: buildings (for physical machine), roads (for network links between racks of machines). Fluid entities, such as network data packets or migratable vms can be represented in the tool as 3D objects free to move along certain paths between designated sources and destinations.
  • the tool can be made available online, so that IT administrators based in different physical locations can collaborate to build systems or participate to solve issues that affect running systems.
  • 3D visualization for objects and the terrain
  • SimCity game allows users to build cities of great complexity.
  • 3D is a step beyond the in-web-browser table or tree view representation for management of data center resources.
  • the current approach without 3D visualisation is unlikely to scale as the number of resources to manage reaches a higher order of magnitude. This is likely to happen soon with the uptake of Service Oriented Architecture (many more services to manage) or multi-core computing architectures (many more virtual machines per hardware resources).
  • the input interpreter of the system can be arranged to determine if the changes are allowable changes.
  • the model generation part can be arranged to use one of a number of predetermined templates of computing infrastructure design, the input interpreter being arranged to use the template to determine if the changes are allowable changes.
  • the operator interface can be suitable for multiple operators, and generate three dimensional views for the multiple operators simultaneously, and broadcast changes to the model to all operators. This can help enable collaborative input on complex models. For example one operator may make a change to a functional step, and another operator, being an expert in infrastructure, can view the effects of that change on the infrastructure, and respond appropriately.
  • This use of an infrastructure design template can reduce the number of options to be evaluated and can help reduce the complexity of the task of generating a model which can be deployed and which makes efficient use of resources. This in turn can help enable a more highly automated method, or can enable more complex business processes to be deployed more efficiently, and managed more efficiently.
  • the infrastructure includes virtualized entities, the increased flexibility tends to increase the complexity of the task of infrastructure design, and the use of templates becomes even more appropriate and valuable in this case. Furthermore, it enables human operators to be more productive with less knowledge, experience or skills, or enables operators of a given level of skill, knowledge or experience to handle more complex business processes for example.
  • the computing infrastructure can comprise virtualized entities. This is one way of increasing flexibility of allocation of resources, and thus enabling improved efficiency of use of the resources. It helps to provide more flexibility since resources such as storage or processing can be divided more finely for sharing, and can be reallocated more quickly.
  • the input interpreter can be arranged to restrict allowable changes according to a class of the operator. This can enable some operators to change only higher level entities or only change entities for which they have appropriate skills, so for example only a database expert may be allowed to change a given database to add a table or change what others are authorised to do.
  • the model can represent a structure and behaviour of the deployment sufficiently to enable simulation of the deployment to verify how well the non functional requirements are met.
  • the operator input can comprise a change to any one or more of functional steps, software application components, computing infrastructure, development or monitoring tools for the deployment.
  • the model generator can be arranged to determine consequential changes to the rest of model from the operator input. This is useful to enable the model to be maintained consistently and efficiently, and reduce the level of skill and knowledge needed by the operator.
  • the operator input associated with the view can comprise changing any one or more of shape, appearance, and location of entities in the view.
  • the system can have monitors to monitor behaviour of the deployment, the visual rendering part being coupled to the monitor to present a visual representation of the monitored behaviour in the view. This helps enable an operator to see the effects of changes to the model or changes in usage of the process for example, to enable more efficient management of the deployment.
  • the visual rendering part can have a stored mapping of modelled entities to rendered items, and the input interpreter have a stored mapping of operator actions on rendered items to changes to the model.
  • the non functional requirements can comprise any one or more of: a number of concurrent users, an indication of desired response time, an availability level, a security level. These are typically significant to facilitate automated deployment.
  • An enterprise interface can be provided to enable the enterprise to customise the non functional requirements independently of each other. Reference is made to above referenced copending application number 200702363 for more details of examples of this. Combining this with providing the 3D interface can assist the enterprise and the service provider to navigate complex models more quickly and see the effects of each others actions for example.
  • Annotations can be inserted in the source code to assist in modelling or in documentation. Reference is made to above referenced copending application number 200702600 for more details of examples of this. Combining this with the 3D visual interface can enable the advantages of both to be enhanced.
  • a general aim of the model based approach described is to enable matched changes to all three parts: the functional steps of the process, the applications used to implement the functional steps of the process, and configuration of the computing infrastructure used by the applications.
  • Such changes are to be carried out automatically by use of appropriate software tools interacting with software models modelling the above mentioned parts.
  • Model-Based technologies to automatically design and manage Enterprise Systems can provide the capability to automatically design, deploy, modify, monitor, and manage a running system to implement a business process, while minimizing the requirement for human involvement.
  • the design of the hardware infrastructure and software landscape for large business processes such as enterprise applications is an extremely complex task, requiring human experts to design the software and hardware landscape. Once the enterprise application has been deployed, there is an ongoing requirement to modify the hardware and software landscape in response to changing workloads and requirements. This manual design task is costly, time-consuming, error-prone, and unresponsive to fast-changing workloads, functional requirements, and non-functional requirements.
  • the embodiments describe mechanisms to automatically create an optimised design for an enterprise application, monitor the running deployed system, and dynamically modify the design to best meet the non-functional requirements. There are two basic inputs to the design process:
  • the infrastructure would consist of computers, memory, disks, networks, storage, and other appliances such as firewalls.
  • the virtual infrastructure must be configured in such a way to best take advantage of the physical infrastructure and support the requirements of the software running on it. For example, the amount of virtual memory or priority assigned to a virtual machine.
  • the software must be configured to meet the system specific functional requirements, such as customisations of standard business processes. Additionally, the software must be configured to best make use of the infrastructure it is deployed on, while meeting both the functional and non-functional requirements.
  • Configuration parameters could include the level of threading in a database, the set of internal processes started in an application server, or the amount of memory reserved for use by various internal operations of an application server.
  • a design for the enterprise application consists of:
  • a model manager in the form of a Model-Based Design Service is responsible for the creation of a set of models of the system, each with slightly different parameters for selection, configuration, and evaluation possibilities.
  • the design process can be simply regarded as a search for and selection of the best model, usually in terms of finding the least expensive model which meets the functional and non-functional requirements of the system.
  • Figure 16 shows an overview of an embodiment of the invention.
  • This shows a model store 820, shared physical infrastructure 815 of the service provider, and various other parts involved in managing the models and the deployment of the models on the physical infrastructure. These parts for managing would typically be implemented as software services.
  • a deployment part 837 takes the model and deploys it on the physical infrastructure.
  • a model generation part 844 generates the model 827 of the computer based process.
  • a visual interface for operators is provided by a 3-D visual rendering part 830, coupled to the model store, and an input interpreter 832. This is arranged to translate management actions input by the operator associated with rendered entities in the view, into changes to corresponding entities in the model.
  • the model generation part receives non functional requirements 824 for the process, and functional steps 826 of the process.
  • the model of the process comprises a model of software applications 829, for implementing the functional steps, and a model of computing infrastructure 834 for running the software applications.
  • the model is shown in deployed form as deployed software applications 818 and deployed computing infrastructure 813 in the shared physical infrastructure.
  • Figure 17 shows some of the principal steps carried out by the system of figure 1 according to an embodiment.
  • Functional steps and non functional requirements (NFRs) for the deployment of the process are received at step 850.
  • the model generation part models the arrangement of software application components to carry out functional steps at step 857. Then the same part models a design of computing infrastructure for running the software application components to meet the NFRs at step 859.
  • a 3-dimensional view of the model is rendered for the operator at step 861.
  • the updated model of the process is deployed on shared infrastructure at step 863. More details of an example of using a series of models for such purposes will now be described. If starting from scratch, a business process is designed using a business process modeling tool. The business process is selected from a catalog of available business processes and is customized by the business process modeling tool. An available business process is one that can be built and run. There will be corresponding templates for these as described below. Then non-functional characteristics such as reliability and performance requirements are specified. Next the software entities such as products and components required to implement the business process are selected. This is done typically by searching through a catalog of product models in which the model for each product specifies what business process is implemented. This model is provided by an application expert or the product vendor.
  • a template is a model that has parameters and options: by filing in the parameters and selecting options a design tool transforms the template into a complete model of a deployable system.
  • This application shows a method of modelling a business process having a number of computer implemented steps using software application components, to enable automatic deployment on a computing infrastructure, the method having the steps of: automatically deriving a grounded model of the business process from an unbound model of the business process, the unbound model specifying the application components to be used for each of the computer implemented steps of the business process, without a complete design of the computing infrastructure, and the grounded model specifying a complete design of the computing infrastructure suitable for automatic deployment of the business process, the deriving of the grounded model having the steps of providing an infrastructure design template having predetermined parts of the computing infrastructure, predetermined relationships between the parts, and having a limited number of options to be completed, generating a candidate grounded model by generating a completed candidate infrastructure design based on the infrastructure design template, and generating a candidate configuration of the software application components used by the unbound model, and evaluating the candidate grounded model, to determine if it can be used as the grounded model.
  • the model generation part can be implemented in various ways.
  • One way is based on a six stage model flow called the Model Information Flow (MIF).
  • MIF Model Information Flow
  • the six phases are shown in figure 4 described below in more detail and each has a corresponding type of model which can be summarised as follows:
  • Custom Process Model defined above, and for example a specialization of the previous model (General Model) with choices made by the enterprise. This model captures non-functional requirements such as response time, throughput and levels of security. Additionally, it can specify modifications to the generic business processes for the enterprise.
  • Unbound Model defined above, and for example an abstract logical description of a system capable of running the business process with the requirements as specified by the enterprise.
  • Grounded Model defined above and for example can be a transformation of the previous model (Unbound Model) to specify infrastructure choices, such as the quantities and types of hardware and virtualization techniques to use, and also the structure and configuration of the software to run the business process.
  • Bound Model a grounded model for which resources in the data centre have been reserved.
  • Deployed Model a grounded model where the infrastructure and the software components have been deployed and configured. At this point, the service is up and running.
  • Each stage of the flow has corresponding types of model which are stored in a Model Repository.
  • Figure 18 shows a view of an architecture for a system according to an embodiment of the invention.
  • Physical infrastructure is shown in the form of data centre resources 902, which can be physical and virtual machines for processing, virtual and physical network elements such as routers, switches, links, and virtual and physical storage elements for example.
  • a model store in the form of a model repository 911 is shown, for storing models of any of the types mentioned above. Examples of models 913 are shown, together with a stored design template for the computing infrastructure 917, which serves to limit changes or other management operations on the models, as will be described below.
  • An example of an implementation of the models, and services is described in more detail below, with reference to figures 1 to 15.
  • Core services consume the models provided by the Model Repository and execute management actions to realize the transitions between phases, to generate the next model in the MIF.
  • Those services can be for example :
  • Template-based Design Service (not shown and an example of a model based design service): translates non-functional requirements into design choices for a Grounded Model based on the template 917.
  • Resource Acquisition Service (RAS) 904 its purpose is to allocate physical resources prior to the deployment of virtual resources, such as vms.
  • Resource Configuration Service (RCS) 906 its role is to create/update the virtual and physical infrastructure.
  • SDS 908 installs and configures the applications needed to run the business processes and potentially other software.
  • Monitoring Services (MS) 909 deploys Probes to monitor behaviour of a Deployed Model. This can include monitoring at any one or more of these three levels: o Infrastructure: e.g. to monitor CPU, RAM, network FO usage regardless of which application or functional step is executing. o Application: e.g. to monitor time taken or CPU consumption of a given application such as a DB process on the operating system, regardless of which particular infrastructure component is used. o Business process: e.g. count the number of sales order per hour, regardless of which infrastructure components or applications are used.
  • FIG. 18 also shows a Game Server 921 connected to the Model Repository and Game Clients A, 933, and B, 937 connected to the Game Server.
  • Game clients can be local terminals, or remote clients with a connection via the Internet for example, using well established techniques.
  • Each remotely connected client runs a networking layer to communicate with the server to retrieve and send game updates.
  • Each client uses a 3D engine to render 3D objects and terrain on the screen.
  • 3D engines such as :
  • Java3D as shown in more detail at: https://java3d.dev.iava.net/.
  • the input translator and the 3-D visual rendering part can be implemented in the form of software run by the Game Server and the game clients in some cases.
  • the game server can be arranged to do part of the task of generating a 3D view. It can convert the modelled entities into a description of locations and types of blocks for the view, for use by the 3D rendering engine.
  • the Game server can be arranged to use four types of models.
  • the Building Blocks Model 931 is a pre-defined set of 3D objects that can be rendered on screen by the Game Clients. Used together, the building blocks can form complex structures.
  • a Connector is a special type of 3D object whose purpose is to connect objects together. This can be rendered as a line, a dotted line, a tube, a roadway, a river channel or similar.
  • Building blocks can be similar to Lego blocks: cubes, spheres, cones, etc...
  • An example of a screenview of an environment for altering an entity using a palette of shapes is shown in a screenshot from the SimCity building architect tool which can be seen at: http://en.wikipedia.Org/wiki/Image:Sc3kBuildingArchitectPlus.png
  • the Actions Model 929 captures the set of actions that can be executed on the building blocks.
  • An action can be the modification of the object's attributes such as its shape (stretching, shrinking), its location within a 3D space, or its connection to other objects. Actions have a visual appearance in the form of icons.
  • the actions model can limit the actions to allowed actions.
  • the design template can have an entity such as a virtual machine and an attached set of allowable operations to the virtual memory to change its size within a range from IGB to 4GB, in increments of 250MB.
  • the actions model can be arranged to limit modifications to such an entity to be consistent with the limits in the design template.
  • the Model to Building Block Mapping 923 defines how modelled elements (and their relationship) in the Model Repository (such as vm, physical machines, etc ..) are rendered as 3D objects on the screen.
  • An example of this mapping could indicate that a physical machine is rendered as a cuboid (as shown for example at http://en.wikipedia.org/wiki/Cuboid ' ) whose volume is proportional to the disk space of the physical machine.
  • Another example of a mapping could indicate that the link between a virtual machine and its physical host is represented by a 3D connector of a certain width. This mapping can be arranged to render only allowable attributes, or allowable changes to such attributes.
  • the Management Operations to Actions Mapping 927 specifies how allowable management operations -at least some of which are defined in the templates- translate into actions affecting the 3D objects (and vice versa).
  • Figure 19 examples of 3D blocks for 3D view
  • FIG. 19 shows a number of blocks and a connector. It shows a 3D representation of a VM labelled xy as a container shaped like a cuboid .
  • the cuboid contains within it others objects, including a cube RAM whose dimension is proportional to the vm memory and a cube labelled CPU% whose dimension is proportional to the VM CPU share on the physical host.
  • An action in the Actions Model allows stretching or shrinking 3D cubes. The meaning of the mapping will be the following: shrinking or stretching the cube is (A) a legal operation and (B) translates to dynamically changing the VM memory.
  • the Game Server connects to the Model Repository to read the set of models and elements.
  • the Game Server derives the set of 3D building blocks that can be used using the Model to Building Blocks Mapping.
  • the building blocks are displayed on a palette toolbar for example by all the clients connected to the Game Server.
  • the set of possible actions is derived from the set of management operations -stored in the template- combined with the Management Operations to Action Mappings.
  • the set of allowed actions can be displayed on a palette toolbar by each connected client.
  • the user drag-and-drops from the palette 3D building blocks and connectors to link objects together (if allowed) as shown by step 702.
  • These operator actions on rendered entities, in the form of in-game actions are translated by the Game Server into changes to the model, also called requests for changes (RFCs) at step 703 for operations such as:
  • the game server can be arranged to interrogate the model and use the core services to determine consequential changes on other parts or other layers of the model, at step 704 to supplement the change. Another option is to generate a new view showing the consequential changes, and generate and evaluate a simulation of the operation of the changed model before implementing the change in the data centre. Once the operator is satisfied, the completed change or changes are handed over to the Core Services to modify the data center resources accordingly at step 707. Once data center resources have been modified, their status is reflected back in the models in the repository.
  • the Game Server in turns translates the new states of the model elements into new states of the 3D objects (different shape, new position, etc.).
  • Monitoring tools also called probes
  • This behaviour can be rendered in the 3D view, for example by showing graphical indications of CPU usage, disk usage, database access delay times, average time taken by an application, number of users served, and so on.
  • the modified statuses of the 3D objects are then broadcasted to all connected clients so all users get a consistent view on the system at the same time
  • the Game Server connects to the Model Repository, fetches the model and translates its structural elements and their relationships into 3D building blocks and appropriate connectors as defined in the Model to Building Block mappings.
  • the set of building blocks is passed onto the Game Client for rendering.
  • FIG. 21 An example of actions by the game server generates the 3D view is shown in figure 21.
  • a list of the modelled entities in the part of the model in the required view is obtained from the model, and the building block mapping is used to identify which types of blocks and connectors correspond to the listed entities.
  • a description of how to render each type of block or connector is obtained using the building blocks model.
  • any monitored behaviours to be rendered are received from the tools linked to the deployed process, and interpreted by the game server, which determines which blocks they apply to and where and how to show them.
  • the game server determines locations of items in the view, depending on e.g. zoom, perspective, viewing location, orientation, level of detail, which layers, and so on.
  • Figure 22 shows an example of actions by the game server to handle operator actions.
  • operator inputs such as screen coordinates of a cursor and mouse click inputs are used to detect which rendered building block an operator is manipulating.
  • the building block to model mapping is used to identify which modelled entity is being operated on.
  • the actions model is used to display allowed values for example, either graphically or using text in a menu or palette, and to restrict the alteration to allowed values. These allowed values can be determined from the design infrastructure template, and the actions model used to obtain instructions on how to display the allowed values.
  • the actions to management operations mapping is used to determine the actual change selected by the operator.
  • a change management service is used to determine consequential changes to other layers, or other entities and to check all are within change management policies and within the changes allowed by the template, before the changes are deployed in the physical infrastructure.
  • OpenCroquet http://www.opencroquet.org/index.php/Main Page.
  • Open Croquet can be used for parts of the implementation of the game Server and Clients.
  • Techniques used in SecondLife TM http://secondlife.com/) , a 3D online environment where most content is user generated, could also be used. SecondLife has an interface that allows users to create complex structures from building blocks.
  • Blocks are scriptable: their attributes (appearance shapes) can be modified by the execution of easy-to-write, user-friendly code.
  • SecondLife "resident" can use a feature that allows virtual blocks to interact with the Web (and this also means Web Services) via HTTP invocations. This way, linking what happens in SecondLife with the Internet world (and this can include data center management services) is feasible, as shown at http://mashable.com/2006/201730/second-life-web-20-virtual-world-mashups/.
  • LinCity NG is an Open Source implementation of the Sim City TM game. http ://lincity-ng.berlios .de/wiki/index .php/Main Page. Parts of this could be used for most of the implementation of the Game Clients. Support for a networked modecan be added by modifying the source code.
  • Templates are used to capture designs that are known to instantiate successfully (using the core services mentioned above).
  • An example of template describes a SAP module running on a Linux vm with a certain amount of memory.
  • the templates also capture management operations that it is known can be executed, for instance migration of vm of a certain kind, increasing the memory of a vm, deploying additional application server to respond to high load, etc... If a change management service refers to the templates, then the templates can be used to restrict the types of change (deltas) that can be applied to the models.
  • the deriving of the grounded model can involve specifying all servers needed for the application components. This is part of the design of the adaptive infrastructure and one of the principal determinants of performance of the deployed business process.
  • the template may limit the number or type of servers, to reduce the number of options, to reduce complexity of finding an optimised solution for example.
  • the deriving of the grounded model from the unbound model can involve specifying a mapping of each of the application components to a server. This is part of configuring the application components to suit the design of adaptive infrastructure.
  • the template may limit the range of possible mappings, to reduce the number of options, to reduce complexity for example.
  • the deriving of the grounded model can involve specifying a configuration of management infrastructure for monitoring of the deployed business process in use.
  • This monitoring can be at one or more different levels, such as monitoring the software application components, or the underlying adaptive infrastructure, such as software operating systems, or processing hardware, storage or communications.
  • More than one grounded model can be derived, each for deployment of the same business process at different times. This can enable more efficient use of resources for business processes which have time varying demand for those resources for example.
  • Which of the grounded models is deployed at a given time can be switched over any time duration, such as hourly, daily, nightly, weekly, monthly, seasonally and so on.
  • the switching can be at predetermined times, or switching can be arranged according to monitored demand, detected changes in resources such as hardware failures or any other factor.
  • the deriving of the grounded model can be arranged to specify one or more virtualized entities without indicating how the virtualised entities are hosted. It has now been appreciated that the models and the deriving of them can be simplified by hiding such hosting, since the hosting can involve arbitrary recursion, in the sense of a virtual entity being hosted by another virtual entity, itself hosted by another virtual entity and so on.
  • the template can specify virtual entities, and map application components to such virtual entities, to limit the number of options to be selected, again to reduce complexity. Such templates will be simpler if they do not need to specify the hosting of the virtual entities.
  • the hosting can be defined at some time before deployment, by a separate resource allocation service for example.
  • the grounded model can be converted to a bound model, by reserving resources in the adaptive infrastructure for deploying the bound model. At this point, the amount of resources needed is known, so it can be more efficient to reserve resources at this time than reserving earlier, though other possibilities can be conceived.
  • the method can have the step of determining differences to the existing deployed model, and reserving only the additional resources needed.
  • the bound model can be deployed by installing and starting the application components of the bound model. This enables the business process to be used. If the grounded model is for a change in an existing deployment, the differences to the existing deployed model can be determined, and only the additional application components need be installed and started.
  • Some embodiments can use an infrastructure capability model to present the possible types of resources that can be provided by a computing fabric.
  • An instance of an infrastructure capability model contains one instance for each type of Computer System or Device that can be deployed and configured by the underlying utility computing fabric. Each time the utility deploys and configures one of these types, the configuration will always be the same. For a Computer System this can mean the following for example. Same memory, CPU, Operating System
  • the templates can map the application components to computers, while the range of both application components and computers is allowed to vary.
  • the templates can also include some or all of the network design, including for example whether firewalls and subnets separate the computers in the solution, hi embodiments described below in more detail, the Application Packaging Model together with the custom (business process) model show how the various application components can implement the business process, and are packaged within the Grounded Model.
  • the template selected can also be used to limit changes to the system, such as changes to the business process, changes to the application components, or changes to the infrastructure, or consequential changes from any of these. This can make the ongoing management of the adaptive infrastructure a more tractable computing problem, and therefore allow more automation and thus reduced costs.
  • templates certain properties have a range: for example 0 to n, or 2 to n.
  • a change management tool (or wizard, or set of tools or wizards) only allows changes to be made to the system that are consistent with template.
  • the template is used by this change management tool to compute the set of allowable changes, it only permits allowable changes. This can help avoid the above mentioned difficulties in computing differences between models of current and next state, if there are no templates to limit the otherwise almost infinite numbers of possible configurations.
  • the template models formally relate the business process, application components and infrastructure design. This means that designs, or changes, to any one of these can be made dependent on the others for example, so that designs or changes which are inconsistent with the others are avoided.
  • Fig 1 shows an overview of infrastructure, applications, and management tools and models according to an embodiment.
  • Adaptive infrastructure 280 is coupled typically over the internet to customers 290, optionally via a business process BP call centre 300.
  • a management system 210 has tools and services for managing design and deployment and ongoing changes to deployed business processes, using a number of models.
  • the management system has initial design tools 211, design change tools 213, deployment tools 215, and monitoring and management tools 217. These may be in the form of software tools running on conventional processing hardware, which may be distributed. Examples of initial design tools and design change tools are shown by the services illustrated in fig 5 described below.
  • a high level schematic view of some of the models are shown, for two business processes, there can be many more.
  • a model 230 of business process 1 is used to develop a design 250 of software application components. This is used to create and infrastructure design 270 for running the application components to implement the business process. This design can then be deployed by the management system to run on the actual adaptive infrastructure, where it can be used for example by customers, a call centre and suppliers (not shown for clarity).
  • item 220 shows a model of a second business process, used to develop a design 240 of software application components. This is used to create and infrastructure design 260 for running the application components to implement the second business process. This design can then also be deployed by the management system to run on the actual adaptive infrastructure.
  • the management system has a 3D visual interface to an infrastructure management operator 200.
  • This operator can be service provider staff, or in some cases can be trained staff of the enterprise owning the process.
  • the service provider staff may be able to view and manage the processes of different enterprises deployed on the shared infrastructure.
  • the operators of a given enterprise would be able to view and manage only their own processes.
  • the interface can be regarded as having an input interpreter part 832 and a 3D visual rendering part, both coupled to the management system 210 to be able to interact with the various types of models, and with the infrastructure design template.
  • the adaptive infrastructure can include management infrastructure 283, for coupling to the monitoring and management tools 217 of the management system.
  • the models need not be held all together in a single repository, in principle they can be stored anywhere.
  • Figure 2 shows a schematic view of some operation steps by an operator and by the management system, according to an embodiment.
  • Human operator actions are shown in a left hand column, and actions of the management system are shown in the right hand column.
  • the human operator designs and inputs a business process (BP).
  • the management system creates an unbound model of the BP.
  • the operator uses the 3D visual interface to select a template for the design of the computing infrastructure.
  • the system uses the selected template to create a grounded model of the BP from the unbound model and the selected template. In principle the selection of the template might be automated or guided by the system.
  • the human operator of the service provider then causes the grounded model to be deployed, either as a live business process with real customers, or as a test deployment under controlled or simulated conditions.
  • the suitability of the grounded model can be evaluated before being deployed as a live business process: an example of how to do this is described below with reference to figure 3.
  • the system deploys the grounded model of the BP in the adaptive infrastructure.
  • the deployed BP is monitored by a monitoring means of any type, and monitoring results are passed to the 3D visual interface to be viewed by the human operator.
  • the operator of the enterprise can design changes to the BP or the service provider can design changes to the infrastructure at step 575. These are input to the system, and at step 580 the system decides if changes are allowed by the same template. If no, at step 585, the operator decides either for a new template, involving a return to step 520, or for a redesign within the limitations of the same template, involving at step 587 the system creating a grounded model of the changes, based on the same template.
  • the operator causes deployment of the grounded model for test or live deployment.
  • the system deploys the grounded model of the changes.
  • the changes could be derived later, by generating a complete grounded model, and later determining the differences, but this is likely to be more difficult.
  • FIG 3 shows an overview of an embodiment showing some of the steps and models involved in taking a business process to automated deployment. These steps can be carried out by the management system of figure 1, or can be used in other embodiments.
  • a business process model 15 has a specification of steps 1-N. There can be many loops and conditional branches for example as is well known. It can be a mixture of human and computer implemented steps, the human input being by customers or suppliers or third parties for example.
  • application components are specified for each of the computer implemented steps of the business process.
  • a complete design of computing infrastructure is specified automatically, based on an unbound model 25. This can involve at step 85 taking an infrastructure design template 35, and selecting options allowed by the template to create a candidate infrastructure design. This can include design of software and hardware parts.
  • a candidate configuration of software application components allowed by the template is created, to fit the candidate infrastructure design. Together these form a candidate grounded model.
  • the candidate grounded model is evaluated. If necessary, further candidate grounded models are created and evaluated. Which of the candidates is a best fit to the requirements of the business process and the available resources is identified.
  • the criteria can be incorporated in the unbound model for example.
  • the different grounded models would usually but not necessarily come from the same template with different parameters being applied to generate the different grounded models.
  • the template, grounded and subsequent models can contain configuration information for management infrastructure and instructions for the management infrastructure, for monitoring the business process when deployed.
  • An example is placing monitors in each newly deployed virtual machine which raise alarms when the CPU utilization rises above a certain level - e.g. 60%.
  • Figure 4 shows some of the principal elements of the MIF involved in the transition from a custom model to a deployed instance. For simplicity, it does not show the many cycles and iterations that would be involved in a typical application lifecycle - these can be assumed.
  • the general model 15 of the business process is the starting point and it is assumed that an enterprise or consultant has designed a customized business process. That can be represented in various ways, so a preliminary step in many embodiments is customising it.
  • a custom model 18 is a customization of a general model. So it is likely that a General Model could be modelled using techniques similar to the ones demonstrated for modelling the Custom Model: there would be different business process steps.
  • a custom model differs from the general model in the following respects.
  • the custom model is converted to an unbound model 25 with inputs such as application performance 31, application packaging 21, and application constraints 27.
  • the unbound model can specify at least the application components to be used for each of the computer implemented steps of the business process, without a complete design of the computing infrastructure.
  • the unbound model is converted to a grounded model 55 with input from models of infrastructure capability 33, and an infrastructure design template 35.
  • Deployment of the grounded model can involve conversion to a bound model 57, then conversion of the bound model to a deployed model 63.
  • the bound model can have resources reserved, and the deployed model involves the applications being installed and started.
  • Figure 5 shows a sequence of steps and models according to another embodiment.
  • model repository 310 which can have models such as templates (TMP), an unbound model (UM), a bound model (BM), a partially deployed model (PDM), a fully deployed model (FDM).
  • TMP templates
  • UM unbound model
  • BM bound model
  • PDM partially deployed model
  • FDM fully deployed model
  • Another service is a resource acquisition service 330 for reserving resources using a resources directory 340, to create a bound model.
  • An adaptive infrastructure management service 350 can configure and ignite virtual machines in the adaptive infrastructure 280, according to the bound model, to create a partially deployed model.
  • a software deployment service 360 can be used to take a partially deployed model and install and start application components to start the business process, and create a fully deployed model.
  • Figure 6 shows steps in deriving a grounded model according to an embodiment.
  • a template is selected from examples such as centralised or decentralised arrangements.
  • a centralised arrangement implies all is hosted on a single server or virtual server.
  • Other template choices may be for example high or low security, depending for example on what firewalls or other security features are provided.
  • Other template choices may be for example high or low availability, which can imply redundancy being provided for some or all parts.
  • step 410 remaining options in the selected template are filled in. This can involve selecting for example disk sizes, numbers of dialog processes, number of servers, server memory, network bandwidth, server memory, network bandwidth, database time allowed and so on.
  • a candidate grounded model is created by the selections.
  • Step 430 involves evaluating the candidate grounded model e.g. by building a queuing network, with resources represented, and with sync points representing processing delays, db delays and so on. Alternatively the evaluation can involve deploying the model in an isolated network with simulated inputs and conditions.
  • the evaluation or simulation results are compared with goals for the unbound model. These can be performance goals such as maximum number of simultaneous users with a given response time, or maximum response time, for a given number of users.
  • another candidate grounded model can be created and tested with different options allowed by the template.
  • the process is repeated for one or more different templates.
  • results are compared to identify which candidate or candidates provides the best fit. More than one grounded model may be selected, if for example the goals or requirements are different at different times for example. In this case, the second or subsequent grounded model can be created in the form of changes to the first grounded model.
  • FIG. 7 shows an arrangement of master and slave application servers for a decentralised or distributed design of computing infrastructure, according to an embodiment.
  • a master application server 50 is provided coupled by a network to a database 60, and to a number of slave application servers 70. Some of the slaves can be implemented as virtual slave application servers 72. Each slave can have a number of dialog worker processes 80.
  • the master application server is also coupled to remote users using client software 10. These can each have a graphical user interface GUI on a desktop PC 20 coupled over the internet for example. The slaves can be used directly by the clients once the clients have logged on using the master.
  • Fig 8 Master Application Server Figure 8 shows parts of a master application server for the embodiment of figure 7.
  • An enqueue process 110 is provided to manage locks on the database.
  • a message server 120 is provided to manage login of users and assignment of users to slave application servers for example.
  • An update server 130 is provided for managing committing work to persistent storage in a database.
  • a print server 140 can be provided if needed.
  • a spool server 150 can be provided to run batch tasks such as reports.
  • dialog worker processes are shown for running instances of the application components.
  • FIG. 9 shows an arrangement of virtual entities on a server, for use in an embodiment.
  • a hierarchy of virtual entities is shown.
  • VM virtual machines
  • Some are hosted on other VMs.
  • VPARs 610 representing a reconfigurable partition of a hardware processing entity, for example by time sharing or by parallel processing circuitry.
  • a number of these may be hosted by a hard partitioned entity nPAR 620 representing for example a circuit board mounting a number of the hardware processing entities.
  • Multiple nPARs make up a physical computer 630 which is typically coupled to a network by network interface 650, and coupled to storage such as via a storage area network SAN interface 640.
  • Virtual machine technology is a known mechanism to run operating system instances on one physical machine independently of other operating system instances. It is known, within a single physical machine, to have two virtual machines connected by a virtual network on this machine.
  • VMware is a known example of virtual machine technology, and can provide isolated environments for different operating system instances running on the same physical machine.
  • levels at which virtualization can occur For example HP's cellular architecture allows a single physical computer to be divided into a number of hard partitions or nPARs. Each nPAR appears to the operating system and applications as a separate physical machine. Similarly each nPAR can be divided into a number of virtual partitions or vPARs and each vPAR can be divided into a number of virtual machines (e.g. HPVM, Xen, VMware).
  • figs 10 to 15 examples of models that can be used within the Model Information Flow (MIF) shown in figs 1 to 9, particularly fig 4.
  • MIF Model Information Flow
  • figs 1 to 9 examples of models that can be used within the Model Information Flow (MIF) shown in figs 1 to 9, particularly fig 4.
  • MIF Model Information Flow
  • figs 1 to 9 examples of models that can be used within the Model Information Flow (MIF) shown in figs 1 to 9, particularly fig 4.
  • MIF Model Information Flow
  • figs 1 to 9 examples of models that can be used within the Model Information Flow (MIF) shown in figs 1 to 9, particularly fig 4.
  • UML Unified Modelling Language
  • CEvI common information model
  • the implementation can be in Java or other software languages.
  • a custom model can have a 1-1 correspondence between an instance of an AlService and a BusinessProcess.
  • the AlService is the information service that implements the business process.
  • a business process can be decomposed into a number of business process steps (BPsteps), so instances of a BusinessProcess class can contain 1 or more BPSteps.
  • An instance of a BPStep may be broken into multiple smaller BPSteps involving sequences, branches and loops for example.
  • An ApplicationComponent is the program or function that implements the BPStep.
  • SAP an example would be the SAP transaction named VAOl in the SD (Sales and Distribution package) of SAP R/3 Enterprise.
  • Another example could be a specific Web Service (running in an Application Server).
  • BPStep can have stepType and stepParams fields to describe not only execution and branching concepts like higher-level sequences of steps, but also the steps themselves.
  • the stepType field is used to define sequential or parallel execution, loops, and if-then-else statements.
  • the stepParams field is used to define associated data. For example, in the case of a loop, the stepParams field can be the loop count or a termination criterion.
  • the set of BPSteps essentially describes a graph of steps with various controls such as loops, if-then-else statements, branching probabilities, etc.
  • the relation BPStepsToApplicationComponentMapping is a complex mapping that details how the BPStep is mapped to the ApplicationComponent. It represents, in a condensed form, a potentially complex mix of invocations on an Application Component by the BPStep, such as the specific dialog steps or functions invoked within the ApplicationComponent or set of method calls on a Web Service, and provided details of parameters, such as the average number of line items in a sales order.
  • a BPStep may have a set of non-functional requirements
  • NonFunctionalRequirements associated with it: performance; availability, security, and others.
  • availability and security requirements are modelled by a string: "high”, “medium”, “low”.
  • Performance requirements are specified in terms of for example a number of registered users (NoUsersReq), numbers of concurrent users of the system, the response time in seconds and throughput requirement for the number of transactions per second.
  • NoUsersReq registered users
  • Many BPSteps may share the same set of non-functional requirements.
  • a time function can be denoted by a string. This specifies when the non-functional requirements apply, so different requirements can apply during office-hours to outside of normal office hours. Richer time varying functions are also possible to capture end of months peaks and the like.
  • SAP R/3 is a collection of software that performs standard business functions for corporations, such as manufacturing, accounting, financial management, and human resources.
  • the SAP R/3 system is a client server system able to run on virtually any hardware/software platform and able to use many different database management systems. For example it can use an IBM AS/400 server running operating system OS/400 using database system DB2; or a Sun Solaris (a dialect of Unix) using an Oracle database system; or an IBM PC running Windows NT using SQL Server.
  • SAP R/3 is designed to allow enterprises to choose their own set of business functions, and to customize to add new database entities or new functionality.
  • the SD Benchmark simulates many concurrent users using the SD (Sales and Distribution) application to assess the performance capabilities of hardware. For each user the interaction consists of 16 separate steps (Dialog Steps) that are repeated over and over. The steps and their mapping to SAP transactions are shown in Figure 10.
  • a transaction here is an example of an Application Component. Each transaction is shown as a number of boxes in a row. A first box in each row represents a user invoking the transaction e.g. by typing /nvaOl to start transaction VAOl. As shown in figure 10, transaction VAOl in the top row involves the business process steps of invoking the create sales order transaction, then filling order details, then saving the sold-to party, and completing with the "back" function F3 which saves the data.
  • a next transaction VLOlN is shown in the second row, and involves steps as follows to create an outbound delivery.
  • the transaction is invoked, shipping information is filled in, and saved.
  • a next transaction VA03 is shown in the third row for displaying a customer sales order. This involves invoking the transaction, and filling subsequent documents.
  • a fourth transaction is VL02N in the fourth row, for changing an outbound delivery. After invoking this transaction, the next box shows saving the outbound delivery.
  • a next transaction shown in the fifth row is VA05, for listing sales orders. After invoking this transaction, the next box shows prompting the user to fill in dates and then a third box shows listing sales orders for the given dates.
  • the transaction VFOl is for creating a billing document, and shows filling a form and saving the filled form.
  • Figure 11 shows an example of a custom model instance for the SD Benchmark.
  • Two lines are shown leading from this box, one to the non-functional requirements associated with this top-level BPStep, and shown by the boxes at the left hand side.
  • performance requirements such as number of users, number of concurrent users, response time required, and throughput required, can be specified as shown. These are only examples: other requirements can be specified to suit the type of business process.
  • a box representing the respective time function is coupled to each performance requirement box as shown.
  • One indicates 9am to 5pm, and the other indicates 5pm to 9am in this example.
  • stepType Step - one for each SAP transaction shown in Figure 10 (VAOl, VLOlN, etc).
  • the name of the first dialog step for each transaction shown in Figure 10 is used as the name of the corresponding BPStep shown in Figure 11 ("Create sales order”, "Create outbound delivery”, "Display customer sales order”, “Change outbound delivery”, “List sales order”, and "Create delivery document").
  • each BP step is coupled to an instance of its corresponding ApplicationComponent via the respective mapping. So BPstep "Create Sales order” is coupled to ApplicationComponent VAOl, via mapping having ID:001.
  • BPstep "Create outbound delivery” is coupled to ApplicationComponent VLOlN via mapping having ID:002.
  • BPstep "Display customer sales order” is coupled via mapping having E):003 to ApplicationComponent VA03.
  • BPstep "Change outbound delivery” is coupled via mapping having ID:004 to ApplicationComponent VL02N.
  • BPstep "List sales order” is coupled via mapping having ID:005 to ApplicationComponent VA05.
  • BPstep “Create delivery document” is coupled via mapping having ID:006 to ApplicationComponent VFOl.
  • the Unbound Model is used to calculate resource demands. As shown in Figure 12 this model can be made up of four models: the Custom Model (labelled
  • Application packaging model describes the internal structure of the software: what products are needed and what modules are required from the product.
  • An ApplicationComponent can be contained in an ApplicationModule.
  • An ApplicationModule might correspond to a JAR (Java archive) file for an application server, or a table in a database.
  • SAP Java archive
  • SAP it might be the module to be loaded from a specific product into an application server such as SD or FI (Financials).
  • the application packaging model can have a DiskFootPrint to indicate the amount of disk storage required by the ApplicationModule.
  • the ApplicationComponent VAOl in Figure 10 it is from SD with a DiskFootPrint of 2MB for example.
  • One or more ApplicationModules are contained within a product.
  • SAP R/3 Enterprise contains SD.
  • ApplicationModules can be dependent on other ApplicationModules.
  • the SD Code for the Application Server depends on both the SD Data and the SD Executable code being loaded into the database.
  • the custom model can have an ApplicationExecutionComponent for executing an ApplicationComponent. This could be a servlet running in an application server or a web server. It could also be a thread of a specific component or a process. In the case of SD's VAOl transaction it is a Dialog Work Process.
  • the ApplicationComponent may indirectly use or invoke other Application-Components to run: a servlet may need to access a database process; SD transactions need to access other ApplicationComponents such as the Enqueue Work Process and the Update Work Process, as well as the Database ApplicationExecutionComponent.
  • ApplicationExecutionComponent can be contained by and executed in the context of an ApplicationExecutionService (SAP application server) which loads or contains ApplicationModules (SD) and manages the execution of ApplicationExecutionComponents (Dialog WP) which, in turn, execute the ApplicationComponent (VAOl) to deliver a BPStep.
  • SAP application server which loads or contains ApplicationModules (SD) and manages the execution of ApplicationExecutionComponents (Dialog WP) which, in turn, execute the ApplicationComponent (VAOl) to deliver a BPStep.
  • SD ApplicationModules
  • VAOl ApplicationComponent
  • the Application Constraints Model expresses arbitrary constraints on components in the Customized Process, Application Packaging and Component Performance Models. These constraints are used by tools to generate additional models as the MIF progresses from left to right. Examples of constraints include:
  • the purpose of the Application Performance Model is to define the resource demands for each BPStep. There are two types of resource demand to consider.
  • a complete Application Performance Model would contain similar information for all the BPSteps shown in Figure 11.
  • the set of dialog steps in the BPStep "Create Sales Order” might consume 0.2 SAPS. Further it consists of 4 separate invocations (or in SAP terminology Dialog Steps). The calls are synchronous.
  • IndirectComponentResourceDemands and ComponentResourceDemands are IndirectComponentResourceDemands and ComponentResourceDemands. • delayProperties: Any delay (e.g. wait or sleep) associated with the component's activity which does not consume any CPU, NetIOProperties and
  • BPStepToAppCompID This is the ID attribute of the
  • ApplicationExecutionComponent is likely to be involved in several different BPSteps.
  • ApplicationEntryPoint This is the program or function being executed. In the case of "Create Sales Order" this is VAOl for the DialogWP. It could also be a method of a Web Service.
  • CPUProperties can be expressed in SAPs or in other units. There are various ways to express MemProperties, NetIOProperties and DisklOProperties.
  • IndirectComponentResourceDemands associations specify the unique resource demands for each BPStep. These demands need to be calculated from known characteristics of each ApplicationComponent derived from benchmarks and also traces of installed systems.
  • the Component Performance Model contains known performance characteristics of each ApplicationComponent.
  • a specific Application Performance Model is calculated by combining the following:
  • the models of the Unbound Model specify not only the non-functional requirements of a system, but also a recipe for how to generate and evaluate possible software and hardware configurations that meet those requirements.
  • the generation of possible hardware configurations is constrained by the choice of infrastructure available from a specific Infrastructure Provider, using information in an Infrastructure Capability Model, and by the selected template.
  • a general principle that applies to deployable software elements described in the Unbound Model, such as the ApplicationExecutionComponent or ApplicationExecutionService, is that the model contains only the minimum number of instances of each type of element necessary to describe the structure of the application topology. For example, in the case of SD only a single instance of a Dialog Work Process ApplicationExecutionComponent associated with a single instance of an Application Server ApplicationExecutionService is needed in the Unbound Model to describe the myriad of possible ways of instantiating the grounded equivalents of both elements in the Grounded Model. It is the template and packaging information that determines exactly how these entities can be replicated and co-located.
  • Virtualization System Profile models hosting relationship as a "HostedDependency" association This does not seem to be required if there is only a need to model a finite number of resource types, so it does not appear in any of the models discussed here.
  • An instance of an infrastructure capability model contains one instance for each type of ComputerSystem or Device that can be deployed and configured by the underlying utility computing fabric. Each time the utility deploys and configures one of these types the configuration will always be the same. For a ComputerSystem this means the following.
  • Fig 13 shows an example of an infrastructure design template having predetermined parts of the computing infrastructure, predetermined relationships between the parts, and having a limited number of options to be completed. In this case it is suitable for a decentralised SD business process, without security or availability features.
  • the figure shows three computer systems coupled by a network labelled "AI network", the right hand of the three systems corresponding to a master application server, and the central one corresponds to slave application servers as shown in figure 7. Hence it is decentralized.
  • AI is an abbreviation of Adaptive Infrastructure.
  • the left hand one of the computer systems is for a database.
  • the type of each computer system is specified, in this case as a BL20/Xen.
  • the master application server is coupled to a box labelled AI_GroundedExecutionService:AppServer, indicating it can be used to run such a software element. It has an associated AIDeploymentSetting box which contains configuration information and deployment information sufficient to allow the AI_GroundedExecutionService to be automatically installed, deployed and managed.
  • AI_GroundedExecutionService:AppServer is shown as containing three components, labelled AI_GroundedExecutionComponents, and each having an associated AIDeploymentSetting box.
  • a first of these components is a dialog work process, for executing the application components of steps of the business process, another is an update process, responsible for committing work to persistent storage, and another is an enqueue process, for managing locks on a database.
  • the range attribute is 2..n for the update and the dialog work process, meaning multiple instances of these parts are allowed.
  • the slave application server has a GroundedExecutionService having only one type of AI GroundedExecutionComponent for any number of dialog work processes.
  • the master and slave application servers and the database computer system have an operating system shown as Al disk: OSDisk.
  • the master application server is shown with an AI_Disk: CIDisk as storage for use by the application components.
  • each computer system has a network interface shown as AI_Nicl, coupled to the network shown by AI_Network : subnet 1.
  • the database computer system is coupled to a box labelled AI GroundedExecutionService: Database, which has only one type of AI GroundedExecutionComponent, SD DB for the database.
  • the service and the execution component each have an associated AIDeploymentSetting box.
  • AIDeploymentSetting carries the configuration and management information used to deploy, configure, start, manage and change the component.
  • This computer system is coupled to storage for the database labelled AI Disk: DBDisk.
  • the template can have commands to be invoked by the tools, when generating the grounded model, or generating a changed grounded model to change an existing grounded model.
  • commands can be arranged to limit the options available, and can use as inputs, parts of the template specifying some of the infrastructure design. They can also use parts of the unbound model as inputs.
  • the Grounded Model may be generated by a design tool as it transforms the
  • Grounded Model until evaluated and selected as the chosen Grounded Model.
  • the following are some of the characteristics of the example Grounded Model of figure 14 compared to the template shown in Fig 13, from which it is derived.
  • the management system is arranged to make these choices to derive the Grounded Model from the template using the Unbound Model.
  • the criteria used for the choice includes the total capacity of the system, which must satisfy the time varying Performance Requirements in the Custom Model. The required capacity is determined by combining these Performance Requirements with the aggregated ResourceDemands [Direct and Indirect] of the Application Performance Model. If the first choice proves to provide too little capacity, or perhaps too much, then other choices can be made and evaluated. Other examples can have different criteria and different ways of evaluating how close the candidate grounded model is to being a best fit.
  • the server may only have an OS disk attached; that is because the convention in such installations is to NFS mount the CI disk to get its SAP executable files.
  • Other example templates could have selectable details or options such as details of the CIDisk and the DBDisk being 100 GB, 20MB/sec, non Raid, and so on.
  • the OS disks can be of type EVA800.
  • the master and slave application servers can have 2 to 5 dialog work processes. Computer systems are specified as having 3 GB storage, 2.6 GHz CPUs and SLES 10-Xen operating system for example. Different parameters can be tried to form candidate Grounded Models which can be evaluated to find the best fit for the desired performance or capacity or other criteria.
  • InfrastructureSettings such as threshold information for infrastructure management components, for example MaxCPUUtilization - if it rises above the set figure, say 60%, an alarm should be triggered.
  • Management policy can specify further policy information for the management components - e.g. flex up if utilization rises above 60%
  • GroundedDeploymentSettings which can include all command line and configuration information so that the system can be installed, configured and started in a fully functional state.
  • SettingData which can provide additional configuration information that can override information provided in the GroundedDeploymentSettings. This allows many GroundedConiponents to share the same GroundedDeploymentSettings (c.f. a notion of typing) with specific parameters or overrides provided by SettingData. Both the GroundedDeploymentSettings and SettingData are interpreted by the Deployment Service during deployment.
  • Data related to possible changes to the component such as instructions to be carried out when managing changes to the component, to enable more automation of changes.
  • Figure 15 shows an alternative adaptive infrastructure design template, in a form suitable for a centralised secure SD business process. Compared to fig 13, this has only one computer system, hence it is centralised. It shows security features in the form of a connection of the network to an external subnet via a firewall. This is shown by an interface AI_Nic:nicFW, and a firewall shown by AI_Appliance: Fire Wall.
  • Other templates can be envisaged having any configuration. Other examples can include a decentralised secure SD template, a decentralised highly available SD template, and a decentralised, secure and highly available SD template.
  • a Bound Model Instance for a SD system example could have in addition to the physical resource assignment, other parameters set such as subnet masks and MAC addresses.
  • a Deployed Model could differ from the Bound Model in only one respect. It shows the binding information for the management services running in the system. All the entities would have management infrastructure in the form of for example a management service.
  • the implementation mechanism used for the interface to the management services is not defined here, but could be a reference to a Web Service or a SmartFrog component for example.
  • the management service can be used to change state and observe the current state. Neither the state information made available by the management service, nor the operations performed by it, are necessarily defined in the core of the model, but can be defined in associated models.
  • One example of this could be to manage a virtual machine migration.
  • the application managing the migration would use the management service running on the PhysicalComputerSystem to do the migration. Once the migration is completed, the management application would update the deployed model and bound models to show the new physical system. Care needs to be taken to maintain consistency of models. All previous model instances are kept in the model repository, so when the migration is complete, there would be a new instance (version) of the bound and deployed models. Infonnation Hiding and the Model Information Flow
  • the management plane is trusted to manage a farm so that it gets the requested resources. Once the deployment service has finished working, one could use application installation and management services to install, start and manage the applications. In general different tools will see projections of the MIF. It is possible to extract from the MIF models the information these tools require and populate the models with the results the tools return. It will be possible to transform between the MIF models and the data format that the various tools use.
  • the software parts such as the models, the model repository, and the tools or services for manipulating the models, can be implemented using any conventional programming language, including languages such as Java, or C compiled following established practice.
  • the servers and network elements can be implemented using conventional hardware with conventional processors.
  • the processing elements need not be identical, but should be able to communicate with each other, e.g. by exchange of IP messages.

Abstract

L'invention concerne le déploiement d'un processus informatisé sur une infrastructure physique partagée (815) d'un fournisseur de service qui met en jeu la génération d'un modèle (827) du processus approprié pour un déploiement automatisé, pour satisfaire des exigences non fonctionnelles données, par la génération pour le modèle d'une représentation (829) d'un agencement de composants d'application logiciels, pour réaliser les étapes fonctionnelles, et une conception (834) d'une infrastructure informatique, pour lancer les composants d'application logiciels. Une interface visuelle (832, 834) pour des opérateurs génère une vue tridimensionnelle d'au moins la conception d'infrastructure informatique du modèle pour des opérateurs. Un interpréteur d'entrée traduit des entrées d'opérateur associées à la vue tridimensionnelle en changements apportés à des parties correspondantes du modèle. L'interface visuelle en 3D permet la gestion de systèmes plus complexes, ou de réduire le besoin d'opérateurs humains avertis.
PCT/US2007/088334 2007-12-20 2007-12-20 Interface visuelle pour un système pour déployer un processus informatisé sur une infrastructure partagée WO2009082385A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
PCT/US2007/088334 WO2009082385A1 (fr) 2007-12-20 2007-12-20 Interface visuelle pour un système pour déployer un processus informatisé sur une infrastructure partagée

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/US2007/088334 WO2009082385A1 (fr) 2007-12-20 2007-12-20 Interface visuelle pour un système pour déployer un processus informatisé sur une infrastructure partagée

Publications (1)

Publication Number Publication Date
WO2009082385A1 true WO2009082385A1 (fr) 2009-07-02

Family

ID=40801484

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2007/088334 WO2009082385A1 (fr) 2007-12-20 2007-12-20 Interface visuelle pour un système pour déployer un processus informatisé sur une infrastructure partagée

Country Status (1)

Country Link
WO (1) WO2009082385A1 (fr)

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20040002891A1 (en) * 2002-06-27 2004-01-01 Kay-Yut Chen Internet-enabled system and method for modeling economics environments
US20040019688A1 (en) * 2002-07-29 2004-01-29 Opinionlab Providing substantially real-time access to collected information concerning user interaction with a web page of a website
US7239311B2 (en) * 2002-09-26 2007-07-03 The United States Government As Represented By The Secretary Of The Navy Global visualization process (GVP) and system for implementing a GVP
US20070179828A1 (en) * 2000-03-22 2007-08-02 Alex Elkin Method and system for top-down business process definition and execution

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20070179828A1 (en) * 2000-03-22 2007-08-02 Alex Elkin Method and system for top-down business process definition and execution
US20040002891A1 (en) * 2002-06-27 2004-01-01 Kay-Yut Chen Internet-enabled system and method for modeling economics environments
US20040019688A1 (en) * 2002-07-29 2004-01-29 Opinionlab Providing substantially real-time access to collected information concerning user interaction with a web page of a website
US7239311B2 (en) * 2002-09-26 2007-07-03 The United States Government As Represented By The Secretary Of The Navy Global visualization process (GVP) and system for implementing a GVP

Similar Documents

Publication Publication Date Title
US8904341B2 (en) Deriving grounded model of business process suitable for automatic deployment
US11182152B2 (en) Methods and systems that share resources among multiple, interdependent release pipelines
US20110004564A1 (en) Model Based Deployment Of Computer Based Business Process On Dedicated Hardware
US20100262559A1 (en) Modelling Computer Based Business Process And Simulating Operation
US20100262558A1 (en) Incorporating Development Tools In System For Deploying Computer Based Process On Shared Infrastructure
US20110004565A1 (en) Modelling Computer Based Business Process For Customisation And Delivery
US20100280863A1 (en) Automated Model Generation For Computer Based Business Process
Petcu Consuming resources and services from multiple clouds: From terminology to cloudware support
US11265202B2 (en) Integrated automated application deployment
US20100110933A1 (en) Change Management of Model of Service
US20100114618A1 (en) Management of Variants of Model of Service
CN109561147A (zh) 一种异构云管理方法及系统、异构云管理系统构建方法
US20170161044A1 (en) Automated-application-release-management subsystem that incorporates script tasks within application-release-management pipelines
US11301262B2 (en) Policy enabled application-release-management subsystem
US20170364844A1 (en) Automated-application-release-management subsystem that supports insertion of advice-based crosscutting functionality into pipelines
US10452426B2 (en) Methods and systems for configuration-file inheritance
Singhal et al. Quartermaster-a resource utility system
US20190163355A1 (en) Persona-based dashboard in an automated-application-release-management subsystem
Zhou et al. Enabling integrated information framework as cloud services for chemical and petroleum industry
WO2009082387A1 (fr) Définition d'environnement de développement pour processus commercial informatisé
Watson et al. Scalable control and monitoring of supercomputer applications using an integrated tool framework
WO2009082385A1 (fr) Interface visuelle pour un système pour déployer un processus informatisé sur une infrastructure partagée
Ostermann et al. Multi‐layered simulations at the heart of workflow enactment on clouds
Ribeiro A Dashboard for Decision Support in Self-Adaptive Cloud Applications
Gimenes et al. A product line architecture for workflow management systems with component-based development

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 07855286

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 07855286

Country of ref document: EP

Kind code of ref document: A1