JP5496829B2 - Transformation from service-oriented architecture model to service-oriented infrastructure model - Google Patents

Description

  The present invention relates to the transformation from a service-oriented architecture (SOA) model to a service-oriented infrastructure (SOI) model. Specifically, the present invention relates to a conversion method for achieving a conversion from SOA to SOI.

  In order to drive information technology (IT) changes in the business and not be restricted by IT changes, the full potential of service-oriented architecture (SOA) is flexible between service applications and the corresponding IT infrastructure. In addition to determining dynamic interoperability, applications need to be deployed and run on the IT infrastructure. SOA provides extremely flexible and scalable service applications, but only if the underlying IT hardware infrastructure can meet changing needs and conditions in the same flexible manner. Given current systems, IT infrastructure has proven to be a bottleneck. This results in a service-oriented infrastructure that allows the IT infrastructure to be defined as a service. In SOI, virtualization is applied to achieve flexibility and scalability by treating the IT infrastructure as a service that displays a pool of resources (eg, web servers, application servers, database servers, servers and storage instances). Is done.

  Computerized methods and systems for SOA to SOI conversion are described herein. In one embodiment, the method receives a SOA model instance and detects a pattern of the SOA model instance that can be converted according to one or more used cases of the database that includes the used case of the pre-converted pattern. Including. The method also includes transforming the detected pattern, thereby generating an intermediate state model instance, and selecting an optimal SOI model instance through dynamic performance and business data analysis.

  In another embodiment of the present invention, the system is operable to support a conversion engine that is operable to convert from a SOA model to an SOI model and a sophisticated business analysis feature. A memory having stored instructions associated with the business engine; The system also provides a processor for executing instructions in memory associated with the conversion engine and business engine, and a used case for providing a set of known convertible patterns for SOA to SOI conversion. Including database. The transformation engine is also supported by a performance database for providing the hardware part properties available for the SOI model and a business value database including historical information on business analysis features, cost facts and efficiency data.

  The present invention is described by way of example and is not limited by the features of the accompanying drawings, where like reference numbers indicate similar elements. It is understood that references to embodiments in the present disclosure or “one” embodiment need not be the same embodiment, and such references mean at least one.

FIG. 1 is a block diagram with an illustration of a SOA to SOI property conversion method. FIG. 2 is a block diagram with an illustration of a method of service-to-service conversion from SOA to SOI. FIG. 3a is a block diagram displaying an exemplary schematic system architecture for SOA to SOI conversion according to an embodiment of the present invention. FIG. 3b is a block diagram displaying an exemplary SOA to SOI conversion including intermediate states, according to an embodiment of the present invention. FIG. 3c is a block diagram displaying an exemplary schematic system architecture for SOA to SOI conversion according to an embodiment of the present invention. FIG. 4 is an entity relationship diagram for an exemplary design of a used case database. FIG. 5 is a flow diagram describing an exemplary SOA to SOI conversion method according to an embodiment of the present invention. FIG. 6 is a block diagram with an exemplary description of an attribute mapping method by SOA to SOI conversion. FIG. 7 is a block diagram displaying pattern recognition and conversion steps of an overall example of a SOA to SOI conversion method. FIG. 8 is a block diagram displaying pattern recognition and conversion steps of an overall example of a SOA to SOI conversion method. FIG. 9 is a block diagram displaying pattern recognition and conversion steps of an overall example of a SOA to SOI conversion method. FIG. 10 is a block diagram that displays pattern recognition and conversion for an overall example of a SOA to SOI conversion method. FIG. 11 is a block diagram displaying the business engine analysis steps of the overall example of the SOA to SOI conversion method. FIG. 12 is a block diagram of an embodiment of a computer system invention for SOA to SOI conversion.

  The SOA model describes software-based services. This provides a complete and abstract non-physical representation for the service with all its software components, interfaces and implementation details. Some exemplary SOA model aspects and scopes include service descriptions, service bindings, service dependencies, service properties, service topologies, service components, service internal component dependencies, component properties, component topologies, inductive components Includes modeling, implementation aspects and deployment aspects. One example of a SOA model language that incorporates these ranges is the Service Component Architecture (SCA).

  In the SOI model, the goal is to describe a physically based computer infrastructure with all the physically based aspects of the deployed computer parts and links. In addition to these points, the SOI model needs to describe other aspects such as installed software and network topology. Some exemplary SOI model aspects and ranges include the hardware part and its location, the network part and topology configuration of the network, the hardware part equipment and functionality, installed applications, software parts and services, (hardware System (shown as a top-level model object consisting of a network, etc.), and metrics for the described system and elements. An exemplary SOI model language that incorporates these aspects is the Common Information Model (CIM).

  According to one embodiment, the SOA model describes a software-based service. For example, in the SOA model, software-based services are represented by their component, interface and implementation details. Usually there is no physical in such a model and the display is completely abstract. For example, in FIG. 1, the SOA model property 100 is partially described as a condition of 300 GB Filespace 110, 10 ms Reaction time 120, and 100 MBit / sec speed 130. Conversely, the SOI model describes a physics-based computer infrastructure with all the necessary hardware parts. Thus, the SOI model displays the hardware necessary to implement the SOA model. In the example of FIG. 1, the property 100 is converted to a virtual file server 140 and comprises three single Hewlett Packard superstore systems 160, each comprising a 100 GB hard disk and a 10 ms reaction time 150, and the system is 100 MBit / sec Gigabit. It is connected to Ethernet (registered trademark) 170. This is an example regarding the conversion from SOA to SOI, and the service condition (for example, 100) is implemented in a hardware part (for example, 140). In addition to the hardware part, the SOI model describes other aspects, such as installed applications, software parts, and services, but does not describe the service in a way that is described in the SOA model, but rather the SOA service. Describe as part of the hardware infrastructure required to implement.

  The example of FIG. 2 shows a request for a business process that is composed of different services (eg, 212, 214, 222, and 224), and the relationship between the services of the processes affects the conversion from SOA to SOI. The definition of the relationship between services depends on the business process and its form, which is determined according to business needs. One such relationship is the level of coupling between services (eg, an approximate measure for their interdependencies), and in one embodiment shown in FIG. 2, can be defined as weak or strong coupling. . Strong coupling 220 means, for example, that two adjacent services have a strong dependency. For example, the real-time financial service 222 should be processed immediately after the reservation service 224. This means high communication conditions including bandwidth and speed. Conversely, a weak coupling 210 means that there is no strong dependency between services, for example, the archive service 212 can be performed only twice a year after the reservation service 214.

  Such relationships between business process services can be described in an SCA assembly drawing. Thus, the service relationship can be one of many factors described in more detail below that affect the conversion to the corresponding infrastructure component. With respect to the example shown in FIG. 2, services with weak coupling can be operated at different locations, such as Bonn 230 and Paris 235, and only the ISDN network 240 is needed to connect to the two locations. Strong coupling, for example, operates on different application servers A 250 and B 255 but estimates two services 222 and 224 to be combined at one location, such as Paris 235. A high-speed connection such as the 1 Gbit optical network 260 needs to satisfy high communication bandwidth and speed conditions between the application servers A 250 and B 255.

  FIG. 3a illustrates an exemplary schematic system architecture for implementing SOA to SOI conversion according to one embodiment of the present invention. The system includes an SOA model 310, an SOI model 320, a conversion engine 330 and a used case database 335. According to one embodiment, the conversion engine 330 uses the previously resolved conversion instance to determine the appropriate conversion for the current conversion request. The conversion engine 330 uses “used cases” from the used case database 335. Used cases provide an SOA to SOI conversion solution for a particular pattern, which is part of a complete SOA or SOI model.

  The pattern can be an aspect or component of the SOA or SOI model. For example, the pattern may include dependencies between services, service components, dependencies of internal components of the service, hardware parts and their locations, network parts and network topology configuration, equipment and hardware part functions. The pattern may be transformed by one or more used cases. Thus, some used cases can convert a single pattern in various ways. These various methods define alternative transformations into the same single pattern. Transforming this same single pattern according to all possible alternative transformations results in different intermediate state model instances.

  For example, the pattern from the SOA model instance 310 of FIG. 3b is transformed according to all existing used cases for such a pattern, thus creating an intermediate state model instance 350. Each intermediate state model instance branches to another lower intermediate state model instance. For example, the intermediate state model instance 355 is further converted to a lower intermediate state model instance 360, which is again converted to a lower intermediate state model instance, and this process continues until there are no more convertible patterns, A pool containing a number of possible SOI models 320 is created. The pool provides all possible transformations of the SOA model 310. The number of SOI models 320 depends on the “used cases” available for converting patterns in the used case database 335.

  The more used cases exist in the used case database 335 for transforming patterns, the more intermediate model instances can be generated and hence the SOI model 320 can be further generated. There may be only one possible conversion of the SOA 310. An example of such a conversion may be the conversion shown in FIG. For service conditions (eg 100), only one possible set of hardware infrastructure (eg 140) is proposed. In this case, there is only one instance in the SOI model 320, which is the virtual file server 140 with its components 150, 160 and 170. If there are more than one SOA model 310 solution, for example, an alternative conversion in converting service conditions for 500 terabytes of network traffic is achieved by different hardware components with the same characteristics, but different manufacturers May be produced by. Similarly, the service condition of the 300 GB file space may be realized by either one 300 GB hard disk or a plurality of hard disks having the same or higher total capacity as 300 GB.

  Returning to FIG. 3a, in one embodiment, the used cases are retained for reuse in the used case database 335. The transformations therefore transform these patterns by the transformation engine 330 based at least in part on the known “used case” pattern recognition. The conversion engine 330 uses a used case database 335 that provides conversions. Therefore, new approaches and facts on the SOA or SOI level may be incorporated into the used case database 335, and the new case database 335 is replaced with new solutions for new transformation aspects and problems that have not yet been resolved. Update and improve.

  The entity relationship (ER) diagram shown in FIG. 4 illustrates one exemplary implementation of the used case database 335. Used case 400 may include a name 410 and a brief description 420 of used case 400. Additional details (e.g., conversion level ID 430) are one of the conversions associated with the used case, including the relationship of the service being converted, properties and objects and / or classes considered when performing the conversion. Or it can be added to describe multiple attributes. A pattern for displaying a used case may be partially defined by the pattern ID 440. Also, different conversion algorithm parameters 450, used conversion algorithms 460, used performance parameters 470 and used business parameters 480 may be set. All these set parameters and algorithms characterize the used case 400 and the transformation it describes. The used conversion algorithm 460 may be, for example, a script, a calculation method, or a fine software part that converts the pattern 440. Different transformation algorithm parameters 450, used performance parameters 470 (eg, response time, error rate, etc.) and used business parameters 480 (eg, cost calculation) may all be used as variables in the transformation algorithm. Changing the parameters can cause different conversion results for a single pattern. These different transformation results are just alternatives to transformations, also referred to as intermediate state model instances 350 and 360 in connection with FIG. 3b. Information 445 may also be provided regarding patterns 440 such as pattern definitions 446 and recognition data 447. In one embodiment, conversion level information 435 may also be provided because pattern recognition is performed at the level.

  Returning to FIG. 3a, in one embodiment, the used case conversion agent 340 is involved in a single pattern conversion. In one embodiment, pattern recognition agent 345 may be used to recognize SOA model 310 patterns. In one embodiment, the pattern recognition agent 345 uses a pattern recognition method based on hierarchical case-based reasoning. Transformation is specified for all models, rather than once, according to a hierarchical case-based reasoning approach that determines which patterns of the entire model are searched first and, if present, the resulting transformation. This is partially executed for the pattern.

  Some parameters that can change the conversion result are a used performance parameter 470 and a used business parameter 480. In one embodiment, these parameters are incorporated into the performance database 375 and the business value database 385, respectively, as shown in FIG. 3c. In one embodiment, both these databases are used by the business engine 370. Business engine 370 enriches the SOA model with performance and business facts. The performance database 375 provides current current hardware parts and their specific metrics via performance parameters 470, which can affect specific pattern conversion algorithms. Business value database 385 provides business analysis data based on historical information, cost facts and efficiency data used for business analysis via business parameters 480. This allows the conversion algorithm to provide further business-oriented conversion.

  In some embodiments, real-time monitoring and analysis (RTMA) agent 380 provides continuous monitoring of the isolated components provided from SOI model 320 and conversion engine 330. Thus, the RTMA agent 380 dynamically examines the SOI model 320 and its components and simultaneously generates data for the performance database 375 used by the business engine 370 and the conversion engine 330. The RTMA agent 380 can also perform bottleneck analysis based on the monitoring information. In SOI, the bottleneck analysis includes workload information and thus performance information of the components of the SOI model. In one embodiment, the business agent 390 examines the SOI model 320 and provides business data such as a bottleneck analysis report or cost report to verify that the SOI meets service level agreement (SLA) conditions and constraints. Guarantee. In one embodiment, an SLA is an agreement negotiated between two parties, one is a consumer and the other is a service provider. The SLA can define other service attributes such as availability, usability, performance, behavior, or billing. Such information may be collected by business agent 390 and stored in business value database 385.

  In some embodiments, the business engine 370, along with the business agent 390 and the RTMA agent 380, uses its dynamic analysis to reduce the SOI model 320 to only one SOI model, which is a concurrent performance and business It is optimal for satisfying conditions and constraints.

  FIG. 5 shows a flow diagram describing an exemplary SOA to SOI conversion method. The conversion begins with receiving an SOA model instance at block 510. At block 520, a pattern of SOA model instances is detected, which can be converted according to at least one used case of the used case database. The used case database includes one or more used cases of previously converted patterns. Hence, the used case provides a solution for a particular pattern, which is part of a complete (complete) model. Used cases that can convert a particular pattern are considered applicable to this pattern. In one embodiment, pattern detection is performed at the conversion level to recognize the pattern. In one embodiment, there are four conversion levels for recognizing patterns. The first level may be a property conversion level. At this level, each SOA property or SOA object or instance is converted to a corresponding property of the SOI component or artifact, as illustrated in FIG. The second level may be an object or class conversion level. In this regard, SOA components and elements are converted to SOI in all or subordinate parts of their properties. The third level may be a service internal level. Through analysis of dependencies such as wires, interfaces, etc., and dependencies between components and software processes, a more sophisticated SOI design can be generated during the conversion process.

  An example of service internal dependencies is shown in FIG. Since strong coupling is determined between the component AA 710 and the component AB 720 of the service A ′ 700, the service A 740 of the updated SOI model changes the service condition 730 of the component AA 710 and the service condition 735 of the component AB 720 to the service condition 750. To join. The fourth level may be an inter-service level. At this level, the dependency between a set of services is analyzed. Therefore, as illustrated in FIG. 2, the relationship between services such as weak or strong coupling, the location of the hardware part of the SOI model, and the network configuration method between the hardware parts can be recognized.

  Returning again to FIG. 5, at block 530, the detected pattern is transformed according to at least one used case, so that at least one intermediate state model instance is generated. Applicable used cases differ from each other depending on the used conversion algorithm, conversion algorithm parameters, performance parameters and business parameters. In one embodiment, the used performance parameter displays the static performance data of the hardware portion available for at least one intermediate state model instance. In one embodiment, business parameters are set depending on cost and profit estimates. At block 540, a check is performed on the convertible pattern in the intermediate state model instance. If a convertible pattern is detected at block 540, ie if there is at least one applicable used case in the used case database for this pattern, the pattern is converted according to at least one used case. Thus, one or more lower intermediate state model instances are generated. The steps described in blocks 530 and 540 for detecting and transforming the pattern are repeated until no transformable pattern is found in the lower intermediate state model instance. At least one lower intermediate state model instance is generated each time the pattern is transformed. At block 550, the lower intermediate model that can no longer be converted is not stored as an instance of the service-oriented infrastructure model. Finally, at block 560, one of the service-oriented infrastructure models is selected according to predetermined selection criteria. In one embodiment, the predetermined selection criteria is based on dynamic performance and business data analysis. In one embodiment, dynamic performance and business data analysis is performed on real-time performance information and business value to help selected SOI model instances meet service level agreement constraints and service level agreement conditions. Based on bottleneck analysis reports and on-demand reports such as cost reports. The cost report may include information such as purchase price, repair cost and initial replacement price for infrastructure components.

  In one embodiment, pattern matching is defined as described in connection with FIG. FIG. 6 is a block diagram with an exemplary description of an attribute mapping method by SOA to SOI conversion. From the SOA side, the SOA request 610 sends a request to the conversion engine 620. The required resource request is identified and sent in attribute format. On the SOI side, all infrastructure components that reside in a resource pool can be modeled by a common information model (CIM), which is then described in XML Schema (XSD) format. Hence, infrastructure components can be described by XML, corresponding instances of XSD. The attributes of the request received by the transformation engine 620 may be looked up in XML elements or attributes that describe some infrastructure components such as 630, 640 and 650 in FIG. "Execute the query. If a particular attribute matches, the corresponding infrastructure component is controlled by the conversion engine 620. When all attributes match, the result is sent back to the SOA.

  The exemplary transformation shown in FIG. 1 is performed in one step. This means that there are no intermediate state models (eg, 350 and 360 described with respect to FIG. 3b). Conversely, the transformations shown in FIGS. 7, 8, 9, 10 and 11 are performed in several steps. During these steps, several intermediate state model instances, including some intermediate properties and objects, should be created. These intermediate state model instances can be applied in other used case recognition patterns. Thus, multi-step transformations are processed in an inductive manner. For each step that achieves a transformation, a lower intermediate state model instance is generated. This lower intermediate state model instance is also processed for known patterns until no more patterns are detected. 7, 8, 9, 10 and 11 are block diagrams displaying an overall example of SOA to SOI conversion according to the present invention. The process of transformation is divided into steps indicating service internal dependencies, recursive transformation, object transformation, property transformation and intermediate state. The overall example displays one branch of the conversion process, as shown in FIG. 3b. This does not show the different alternatives shown for each step (eg, the intermediate state model instance 350 of FIG. 3b), but rather the initial SOA model (eg, the SOA model 310 of FIG. 3b), some Of intermediate states (eg, intermediate state models 355 and 365 of FIG. 3b) and optimal SOI model instance (eg, SOI model 369 of FIG. 3b). Thus, the examples shown in FIGS. 7-11 show the path along the branch that yields the optimal SOI model instance. Beginning with FIG. 7, conversion begins. This is the first step 760 of inductive pattern recognition. Since strong binding is detected at the service internal level, the applied strong binding pattern provides binding of both SOA component conditions 730 and 735 to one service condition 750. Thus, components AA 710 and AB 720 are combined in the first step 760 of the transformation. In the next inductive pattern recognition step 800 shown in FIG. 8, RAM / Computing power pattern 810 is detected. The property of RAM / Computing power on the SOA level is converted to the corresponding property RAM / CPU on the SOI level. The applied RAM / Computing power pattern accesses the performance database by analyzing the current latest hardware parts and provides a grid structure with a 66% efficient interconnect grid 820. Based on this provision, the currently available CPU / RAM portion 830 is selected. In an alternative transformation, the grid structure provided by the performance database may be, for example, a 50% or 75% efficient interconnect grid. Such a provision may cause a selection of different CPU / RAM parts. FIG. 9 displays the next inductive pattern step 900. In this step 900, the “unknown” motherboard intermediate state is converted from the performance database to a known selected motherboard XY910. Some of these selected motherboards are further inserted along with other properties on the SOI level such as server housing, slots and network adapters 920. Here, if the performance database provides several motherboard variants, different alternatives may appear. Motherboards with the same metrics but different manufacturers (trademarks) can also cause the creation of several alternative intermediate state model instances. The next inductive step 1000 shown in FIG. 10 shows the steps of network pattern recognition 1010. The intermediate state is coupled and translated to SOI level network adapters and links 1020. The specific server rack 1030 and switch 1040 are selected from the performance database. Finally, FIG. 11 shows a step 1100 of analyzing the generated SOI model instance in step 1000 by the business engine. The business engine confirms that the step 1000 model is the optimal 1110. This defines the Step 1000 model as the optimal SOI model instance. The business engine can also access its business value database, for example, to find that an SOI infrastructure provider operates a server farm that is not fully loaded. Based on this information, the placement of services on this server farm is provided by the business engine 1120.

  FIG. 12 is a block diagram of an inventive embodiment of a computer system 1200 for SOA to SOI conversion. Computer system 1200 incorporates memory 1210, processor 1230, and I / O interface 1240. Memory 1210 includes an internal database 1270, a conversion engine 1220 and a business engine 1250. A conversion engine 1220 is used to convert from the SOA model to the SOI model. The conversion engine 1220 performs the conversion by accessing a used case database that provides known convertible patterns for SOA to SOI conversion. The used case database resides in either the internal database 1270 or the external database 1260. The external database is connected to the computer system 1200 using the I / O interface 1240. The conversion engine 1220 is supported by a business engine 1250 with business analysis features. In one embodiment, the conversion engine 1220 and the business engine 1250 perform the conversion using data from a performance database that provides the properties of the hardware part available to the SOI model. The performance database may reside in either the internal database 1270 or the external database 1260. In one embodiment, transformation engine 1220 and business engine 1250 perform transformations using data from a business value database that provides historical information, cost facts, and efficiency data regarding business analysis features. The business value database may reside in either the internal database 1270 or the external database 1260. In one embodiment, the recognition agent (not shown) may be part of the computer system 1200 and provides a sophisticated pattern recognition method based on a hierarchical case-based reasoning system approach. In one embodiment, a conversion agent (not shown) is used to convert a single recognition pattern to generate an updated SOI model instance, which is another convertible in the updated SOI model instance. Depending on the availability of different patterns, it may be intermediate or last with respect to the transformation. In one embodiment, the business value database is supplied with business data by a business agent (not shown). In one embodiment, a real-time monitoring and analysis (RTMA) agent (not shown) is used to provide data for the performance database.

  Embodiments of the present invention relate to a computer stored product with a computer readable medium having computer code on the medium for performing various computer operations. The media and computer code may be specifically designed and configured for the purposes of the present invention and may be well known and available to those skilled in the computer software art. Examples of computer readable media include magnetic media such as hard disks, floppy disks and magnetic tape, optical media such as CD-ROM, DVD and holographic devices, magneto-optical media, integrated circuits for applications ( "ASIC"), programmable logic devices ("PLD") and hardware devices specifically configured to store and execute program code, such as, but not limited to, ROM and RAM devices. Examples of computer code include files containing machine code, such as generated by a compiler, and high-level code that is executed by a computer using an interpreter. For example, embodiments of the present invention may be implemented using Java, C ++, or other object-oriented programming languages and development tools. Another embodiment of the present invention may be implemented with hardwired circuitry instead of or in combination with machine-executable software instructions.

  The foregoing description has used certain terminology for the purpose of explanation to provide a thorough understanding of the present invention. However, one skilled in the art will recognize that details are not required to practice the invention. Thus, the foregoing descriptions of specific embodiments of the present invention are provided for purposes of illustration and description. They are not intended to be exhaustive or limited to the invention in the form disclosed only, and many modifications and variations are possible in light of the above teaching. The embodiments have been selected and described in order to best explain the principles of the invention and its practical application, so that those skilled in the art will appreciate that various implementations with various modifications suitable for the invention and the particular use contemplated. The form can be used optimally. The following claims and equivalents are intended to define the scope of the invention.

310 SOA model 320 SOI model 330 Conversion engine

Claims (16)

A computer readable medium containing computer readable instructions when executed by a computer,
The process of receiving a service-oriented architecture model instance;
Detecting a pattern of service-oriented architecture model instances that can be converted according to at least one used case in a used case database, wherein the used case is part of a service-oriented architecture model or a service-oriented infrastructure model; The pattern is a feature or component of a service-oriented architecture model or a service-oriented infrastructure model, corresponding to one or more of the used cases, and the used case database is a service-oriented architecture model A process involving one or more used cases corresponding to patterns in which the transformation from a service-oriented infrastructure model has already been performed;
Transforming a detected pattern according to at least one used case to generate at least one intermediate state model instance, wherein the intermediate state model instance is more than the intermediate state model instance; A process that is a model instance that can be converted to a model instance in a subordinate concept state;
At least one to detect a pattern of at least one intermediate state model instance that can be transformed according to at least one other used case in the used case database and to generate one or more sub-intermediate model instance instances Transforming the detected pattern according to one other used case, wherein the other used case is different from the used case used to generate the intermediate state model instance A process that is a finished case,
Detecting and converting patterns of lower intermediate state model instances until the lower intermediate state model is no longer convertible according to used cases in the used case database;
Storing an inferior intermediate state model that is no longer convertible as an instance of a service-oriented infrastructure model;
Selecting one of the service-oriented infrastructure models according to the lower intermediate state model and predetermined selection criteria;
The service-oriented architecture model is information describing a software-based service, and is information indicating the content of the service without specifying hardware for providing the service ,
The service oriented infrastructure model, Ri information der to indicate the hardware required to implement the service oriented architecture model,
The predetermined selection criteria is based on dynamic performance and business data analysis,
The dynamic performance and business data analysis includes a bottleneck analysis report and a cost report based on business value, etc. to support the selected service-oriented infrastructure model to satisfy the conditions of service level agreement and the constraints of service level agreement, etc. A computer-readable medium that causes a computer to execute a method based on an on-demand report and real-time performance information .   The computer of claim 1, wherein the step of detecting a pattern convertible according to at least one used case of used cases is performed at one or more conversion levels to recognize the pattern. A readable medium.   The computer-readable medium of claim 2, wherein the one or more transformation levels for recognizing a pattern include a property level, an object or class level, an inter-service level, and a service internal level.   The computer-readable medium of claim 1, wherein used cases that can convert detected patterns differ from each other by one or more used conversion algorithms, conversion algorithm parameters, performance parameters, and business parameters. .   5. The computer-readable medium of claim 4, wherein the performance parameter is substituted depending on static performance data of the hardware portion available for the intermediate state model instance.   The computer-readable medium of claim 4, wherein the business parameter comprises a cost and profit estimate. A computerized method for a service-oriented architecture for service-oriented infrastructure transformation, comprising:
The process of receiving a service-oriented architecture model instance;
Detecting a pattern of service-oriented architecture model instances that can be converted according to at least one used case in a used case database, wherein the used case is part of a service-oriented architecture model or a service-oriented infrastructure model; The pattern is a feature or component of a service-oriented architecture model or a service-oriented infrastructure model, corresponding to one or more of the used cases, and the used case database is a service-oriented architecture model A process involving one or more used cases corresponding to patterns in which the transformation from a service-oriented infrastructure model has already been performed;
Transforming a detected pattern according to at least one used case to generate at least one intermediate state model instance, wherein the intermediate state model instance is more than the intermediate state model instance; A process that is a model instance that can be converted to a model instance in a subordinate concept state;
At least to detect a pattern of at least one intermediate state model instance that can be transformed according to at least one other used case in the used case database and to generate one or more subordinate intermediate state model instances; Transforming the detected pattern according to one other used case, the other used case being different from the used case used to generate the intermediate state model instance The process of being a used case,
Detecting and converting patterns of lower intermediate state model instances until the lower intermediate state model is no longer convertible according to used cases in the used case database;
Storing a model of a lower intermediate state that is no longer convertible as an instance of a service-oriented infrastructure model;
Selecting one of the service-oriented infrastructure models according to the lower intermediate state model and predetermined selection criteria;
The service-oriented architecture model is information describing a software-based service, and is information indicating the content of the service without specifying hardware for providing the service ,
The service oriented infrastructure model, Ri information der to indicate the hardware required to implement the service oriented architecture model,
The predetermined selection criteria is based on dynamic performance and business data analysis,
The dynamic performance and business data analysis includes a bottleneck analysis report and a cost report based on business value, etc. to support the selected service-oriented infrastructure model to satisfy the conditions of service level agreement and the constraints of service level agreement, etc. Based on real-time performance information and on-demand reports . The method of claim 7 , wherein the step of detecting a convertible pattern according to at least one used case of used cases is performed at one or more conversion levels to recognize the pattern. . 9. The method of claim 8 , wherein the one or more transformation levels for recognizing a pattern include a property level, an object or class level, an inter-service level, and a service internal level. 8. The method of claim 7 , wherein the used cases that can convert the detected pattern differ from one another by one or more used conversion algorithms, conversion algorithm patterns, performance parameters, and business parameters. The method of claim 10 , wherein the performance parameter is substituted depending on the static performance data of the hardware part available for the intermediate state model instance. The method of claim 10 , wherein the business parameter comprises a cost and profit estimate. A computer system for converting from a service-oriented architecture model to a service-oriented infrastructure model,
One having stored instructions for a conversion engine operable to convert the service-oriented architecture model into a service-oriented infrastructure model and a business engine operable to support the conversion engine with sophisticated business analysis features. Or a plurality of memory devices,
A processor operable to communicate with the memory and execute instructions in the memory relating to the conversion engine and the business engine;
A used case database to provide a set of known convertible patterns for converting a service-oriented architecture to a service-oriented infrastructure;
A performance database to provide the hardware part properties available to the service-oriented infrastructure model;
Business value database including historical information on business analysis features, cost facts and efficiency data,
The used case database includes one or more used cases corresponding to patterns in which a conversion from a service-oriented architecture model to a service-oriented infrastructure model has already been performed,
The used case is part of a service-oriented architecture model or a service-oriented infrastructure model,
The pattern is a feature or component of a service-oriented architecture model or a service-oriented infrastructure model, corresponding to one or more of the used cases,
The transformation engine transforms the detected pattern according to at least one used case to generate at least one intermediate state model instance, the intermediate state model instance being more than the intermediate state model instance. Is also a model instance that can be converted into a model instance in a subordinate concept state,
The conversion engine detects a pattern of at least one intermediate state model instance that can be converted according to at least one other used case in the used case database and generates one or more sub-intermediate model instance instances Transforming the detected pattern according to at least one other used case, the other used case being different from the used case used to generate the intermediate state model instance Used case,
The transformation engine detects and transforms the pattern of lower intermediate state model instances until the lower intermediate state model is no longer convertible according to the used cases in the used case database;
The transformation engine stores, as an instance of a service-oriented infrastructure model, a lower intermediate state model that is no longer translatable;
The transformation engine selects one of the service oriented infrastructure models according to the lower intermediate state model and predetermined selection criteria;
The service-oriented architecture model is information describing a software-based service, and is information indicating the content of the service without specifying hardware for providing the service ,
The service oriented infrastructure model, Ri information der to indicate the hardware required to implement the service oriented architecture model,
The predetermined selection criteria is based on dynamic performance and business data analysis,
The dynamic performance and business data analysis includes a bottleneck analysis report and a cost report based on business value, etc. to support the selected service-oriented infrastructure model to satisfy the conditions of service level agreement and the constraints of service level agreement, etc. Based on on-demand reports and real-time performance information,
A computer system characterized by that. The computer system of claim 13 , further comprising a recognition agent for use in a pattern recognition method based on a hierarchical case-based reasoning approach. The computer system of claim 13 , further comprising a business agent for providing business data for the business value database. The computer system of claim 13 , further comprising a real-time monitoring and analysis agent for providing data for the performance database.

Images