JP2009009207A - System design support method for soa architecture and system design support deice for soa architecture - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To provide a system design support device of an SOA architecture for generating a macro-service as a coarse virtual service by combining a business process and a service in fine granularity in designing an SOA system. <P>SOLUTION: This system design support device of an SOA architecture for constructing a business process, and for assigning a service to the components is provided with a main storage device 105 in which a processing means is stored and a central processing unit 101 for executing a processing means stored in the main storage device 105. The central processing unit 101 executes the processing means, and generates a macro-service as a virtual service whose detail level of the system components is coarse from the subset of the business process to which the service has been already assigned in the detail level of the fine system components. <P>COPYRIGHT: (C)2009,JPO&INPIT

Description

  The present invention relates to an apparatus and method for designing a Web service, and in particular, details of a system component of a business process to be designed (hereinafter referred to as “granularity”) and a granularity of a service assigned to the business process component. The system design support method of the SOA architecture and the system design support device of the SOA architecture that facilitate the design work of the business process designer by preparing a service of the granularity of the business process when

  When a service is assigned to a component of a business process, functional information / non-functional information provided by the service is taken into consideration. The functional information of the service used in the present invention is “program”. "Non-functional information" means "items indicating properties related to program movement (response time, etc.)".

  In designing a computer system, a high level of technology is required, so the burden on the designer is great. Therefore, in order to reduce the burden, a design tool that can be easily designed is required. Regarding the construction of SOA architecture systems using Web services, design support tools have already been sold by several companies, but there are still a lot of issues to be solved when using them for actual on-site design. The development of overcoming design support tools is awaited.

  For example, the design can be divided into several levels depending on the granularity / abstraction level of the object to be handled. In this section, we will simplify this process by focusing on the more granular “business level design” and the more fine-grained “implementation level design” that requires knowledge of the functions of the application interface of each computer system. The problem is illustrated using FIG. 17 assuming that there are three levels. FIG. 17 is an explanatory diagram for explaining a problem that the current SOA system design means has.

  Business-level business process designers do not want to consider implementation-level function calls, but want to have business-level discussions. This target area is 301 in FIG. On the other hand, what exists in the world is an implementation level service in which an existing computer system is directly converted into an SOA service (302 in FIG. 17).

  Thus, there is a difference between the level that the business level designer wants to handle and the level at which the service is actually prepared, and the implementation level service cannot be assigned to the business level business process. Resolving such divergence is an important issue in constructing a system that conforms to the SOA architecture.

In order to solve this problem, conventionally, in the hierarchical business process (BP) definition as disclosed in, for example, Japanese Patent Application Laid-Open No. 11-316780 (Patent Document 1), the sub-BP is assigned to the upper main. There has been a workflow system having a hierarchical business process definition that performs systematic and easy-to-understand BP definition by making it independent from the BP, and improves its maintainability.
JP-A-11-316780

  However, using the method disclosed in Patent Literature 1 to solve the above-mentioned “divergence in granularity between business processes and services” results in the form shown in FIG. FIG. 18 is a diagram showing an outline when the problem of the current SOA system design means is solved by applying the technique of Patent Document 1. In FIG.

  That is, the business-level business process components (eg, 401 in FIG. 18) are expanded as implementation-level fine-grained business processes (eg, 402 in FIG. 18), and the implementation-level business process components are used. On the other hand, it is a method of trying to construct a complete SOA model by allocating service at the implementation level (403 in FIG. 18).

However, this solution has the following problems.
The SOA model is completed as a combination of a business process and a service only at the implementation level where the service is prepared, and a closed discussion cannot be made at the business level.
・ Existing BPEL ("Business Process Execution Language for Web Services", an XML-based language specification for defining business processes that combine multiple Web services) + WSDL ("Web Services Description Language," an abbreviation of "Language of Web Services Description") The level that can be handled using the XML-based tools for describing Web services) is limited to the implementation level, so business level designers can perform operating environments and simulations, and design with trial and error. To proceed, you are forced to have knowledge of the implementation level.

  Therefore, in patent document 1, there existed a problem that a subject could not be solved in the form which satisfy | fills the request | requirement of the designer of the business level who handles a coarser model.

  Accordingly, an object of the present invention is to provide a business with a fine granularity so that the SOA system design can be completed in the form of a business process + service even at a granularity (detail level of system components) where a service is not prepared at the time of designing the SOA system. An object of the present invention is to provide an SOA architecture system design support method and an SOA architecture system design support apparatus capable of generating a "macro service" that is a coarse-grained virtual service from a combination of processes and services.

  The above and other objects and novel features of the present invention will be apparent from the description of this specification and the accompanying drawings.

  Of the inventions disclosed in the present application, the outline of typical ones will be briefly described as follows.

  The SOA architecture system design support method according to the present invention is a SOA architecture system design support method for constructing a business process and allocating a service to its constituent elements. The processing means is executed on the information processing apparatus, and the processing means A macro service, which is a virtual service with a low level of detail of system components, is generated from a subset of business processes to which a service has been assigned in the level of detail of detailed system components.

  An SOA architecture system design support apparatus according to the present invention is an SOA architecture system design support apparatus that constructs a business process and allocates services to its components, and includes a main storage device that stores processing means, A central processing unit that executes processing means stored in the storage device, the central processing unit executing the processing means, and from the subset of business processes to which the service has been assigned in the detail level of fine system components, the system A macro service, which is a virtual service with a low level of detail of components, is generated.

  According to the present invention, when the SOA system is designed, the business process at a fine granularity can be completed so that the SOA system design can be completed in the form of a business process + service even at a granularity where the service is not prepared (detail of system components). From the combination of services, it is possible to generate a “macro service” which is a coarse-grained virtual service.

  First, an outline of the present invention will be described.

  The present invention includes means [means 1] for constructing a business process at a specific granularity, means [means 2] for accumulating information on a service having non-functional information at a specific granularity, and business services at a specific granularity. Means [means 3] to be assigned to the constituent elements of the system, means [means 4] for converting between variables to be exchanged with the service among the constituent elements of the business processes to which the service has been assigned, and service assignment at a finer granularity Means [means 5] for generating a “macro service”, which is a coarser granular coarse-grained virtual service, from a subset of the existing business processes.

  [Means 5] is expressed in BPEL format for a subset of business processes, which is a set of components (hereinafter referred to as “activity”) to which a service having non-functional information such as “response time” is assigned. Business process analysis / macro service generation means [means 5-A] for generating a macro service expressed in WSDL format from a subset of business processes, and non-functional information of individual activities constituting the subset (for example, individual activities Simulating means [means 5-B] for calculating non-functional information of the entire subset (for example, the response time of the entire subset) from the response time of the service assigned to.

  By providing these means, the above-mentioned “problem of divergence between a service group with a more detailed granularity small and a business process with a coarser granularity large” can be solved as follows.

  [Step 1] First, a business process of granularity large is configured by [Means 1].

  [Step 2] Based on the business process of Step 1, a business process having a granularity small in which a service actually exists is generated. At this time, each activity of the granularity large corresponds 1: 1 with a subset of the business processes of the granularity small.

  [Step 3] Using [Means 4], the service of the granularity small stored in [Means 3] is allocated to the activity of the business process of the granularity small generated in Step 2 above. At this time, the non-functional information held by the service is handed over to the activity of the assignment destination.

[Step 4] Using the means [5-A], the WSDL of the macro service of the granularity large is generated from the BPEL expressing each subset of the business processes of the granularity small. Further, the non-functional information of the entire subset is calculated by simulation from the individual non-functional information constituting the subset using the means [5-B], and this is used as the non-functional information of the macro service (at this time, the granularity small). Each subset of the business process corresponds 1: 1 with each macro service in the granularity large). Then, the generated macro service is registered in the service information storage means [means 3] of the granularity large.
[Step 5] The macro service generated in Step 4 and stored in the service information storage means [means 3] of the granularity large is assigned to each activity of the business process of the granularity large by [means 1].

  As a result, a service with a larger granularity, which is a coarser granularity, can be prepared, so that business processes and services are completed in the granularity large.

  Here, it is not enough to simply group services with a granularity small when generating a “macro service”, and it is necessary to generate a macro service from a business process with a granularity small. This is due to the following two reasons.

  [Reason 1] In general, the name of a variable representing the input / output of a service may differ depending on the service. It is a business in the field of SOA using BPEL + WSDL, associating variables such as “the output variable Vp of service P and the input variable Vq of service Q are actually the same, and the value of Vp is substituted into Vq”. This is done in BPEL that represents the process. When associating a plurality of services, a business process is required to associate variables, and the association cannot be realized simply by grouping WSDLs representing services.

  [Reason 2] Non-functional information as a whole macro service of the granularity large) (for example, “response time” of the macro service itself), the order in which the services of the granularity small are called, and what conditional branching / Depends on the processing flow of a business process with a small granularity, such as whether parallel processing exists. Therefore, the non-functional information of the macro service cannot be derived only from the service group having the granularity small.

  For the above reasons, in order to generate a macro service, it is not sufficient to simply group services having a granularity small, and it is necessary to generate a macro service from a business process having a granularity small.

  Next, referring to FIG. 1, the configuration of a system design support apparatus of the SOA architecture according to an embodiment of the present invention will be described. FIG. 1 is a block diagram showing a configuration of a system design support apparatus for an SOA architecture according to an embodiment of the present invention.

  In FIG. 1, an SOA architecture system design support apparatus 100 constituted by an information processing apparatus or the like includes a central processing unit (CPU) 101, a keyboard 102, a display 103, a pointing device 104, a main storage device (memory) 105, a magnetic field. It comprises a disk device 106 and a bus 107 connecting them.

  The magnetic disk device 106 is one of secondary storage devices, and stores a business process design information repository 120 and a service information repository 121. The magnetic disk device 106 may be configured to be connected to another device connected via a communication line (not shown in FIG. 1) or the like.

  The main storage device 105 includes a control program 110, a business process construction program 111, a data association program 112, a business process analysis / macro service generation program 113 as a business process analysis / macro service generation means, and a simulation program as a simulation means. 114 is stored, and each of these programs constitutes processing means. Each of the above programs can be stored in a storage medium that can be read and written by a computer, such as a magnetic disk device 106 or a floppy (registered trademark) disk.

  The control program 110 is activated in response to a user instruction from the keyboard 102 or the pointing device 104, a function call from another program, or the like, and starts a business process construction program 111, a data association program 112, a business process analysis / macro service generation program 113. The simulation program 114 is controlled.

  Next, referring to FIG. 2, an overview of the functions of each program in the system design support apparatus of the SOA architecture according to one embodiment of the present invention and the relationship with each information stored in the magnetic disk apparatus will be described. FIG. 2 is an explanatory diagram for explaining the function outline of each program in the system design support apparatus of the SOA architecture according to one embodiment of the present invention and the relation with each information stored in the magnetic disk apparatus.

  In FIG. 2, the user uses a business process construction program 111 to construct a business process (business flow) with a desired granularity. When service information of the granularity exists in the service information repository 121, the service information can be assigned to an activity in the business process. The business process designed here can be stored in the business process design information repository 120.

  The data association program 112 is a program that is called during the operation of the business process construction program 111 and associates variables (names can generally vary depending on the service) used when calling a service assigned to an activity of the business process. It is a program to do. The association information generated by this program is described in the business process as an activity dedicated to data association.

  The business process analysis / macro service generation program 113 is a program for generating a macro service that is a coarser granularity service from a subset of business processes having a certain granularity to which services are assigned. Having this program is a feature of the present embodiment not found in the prior art.

  The simulation program 114 is a program called from the business process analysis / macro service generation program. For a subset of business processes, the non-functional information (such as response time) of services assigned to the activities constituting the subset is stored. Based on this, non-functional information as a whole subset, that is, non-functional information of the macro service is calculated.

  Next, referring to FIG. 3, an outline of a procedure for designing a SOA architecture system using the SOA architecture system design support apparatus according to an embodiment of the present invention will be described. FIG. 3 is a flowchart showing a procedure for designing a SOA architecture system using the SOA architecture system design support apparatus according to the embodiment of the present invention. Hereinafter, in this embodiment, a coarser granularity is represented by “business level granularity”, and a finer granularity is represented by “mounting level granularity”. It is assumed that a service is not prepared at the business level, but a service is prepared only at the implementation level.

  First, in step S000, a business-level designer activates the design apparatus. Next, in step S001, a business-level designer uses the business process construction program 111 to construct a business-level business process. At this stage, there are no business-level services, so business-level designers cannot assign services to business process activities.

  Next, in step S002, the implementation level designer constructs the implementation level business process using the business process construction program 111 based on the business level business process in step 001. Since the service exists at the implementation level, the designer at the implementation level assigns the service to the created business process activity.

  Further, when the variable names are different between the assigned services, the data association program 112 is used to associate the variables, and the activity for associating is embedded in the business process.

  Next, in step S003, the designer at the implementation level uses the business process analysis / macro service generation program 113 to generate a macro service from the designated subset of business processes. At this time, the non-functional information of the macro service is calculated using the simulation program 114.

  Then, the generated macro service is stored in the service information repository 121. As a result, business-level services are prepared, so that the business-level designer can assign a macro service to a business process using the business process construction program 111 in the next step S004. That is, it is possible to design a complete SOA system to which services have been assigned.

  Further, since non-functional information is assigned to the macro service, it is possible to apply the simulation program 114 to a business process at the business level and execute a simulation at the business level.

  Next, with reference to FIG. 4 to FIG. 15, details of each step of a procedure in designing a SOA architecture system using the SOA architecture system design support apparatus according to an embodiment of the present invention will be described. 4 to 15 are explanatory diagrams for explaining the details of each step of the procedure when designing the SOA architecture system using the SOA architecture system design support apparatus according to the embodiment of the present invention. 4 shows a display example of a business process construction screen (granularity is business level) used by the business process construction program of FIG. 2, and FIG. 5 shows a business process construction screen (granularity is implemented) used by the business process construction program of FIG. 6 is a diagram showing an example of a data association screen used by the data association program of FIG. 2 and a rough structure of data-related information generated by the screen, and FIG. Figure showing WSDL notation of address book service handled as an example, Figure 8 is a postal mail handled as an example of an implementation level service FIG. 9 is a diagram showing the WSDL notation of the number book service, FIG. 9 is a diagram showing the BPEL notation of the integrated service treated as an example of the implementation-level business process, and FIG. 10 is associating variables between the address book service and the zip code book service. FIG. 11 is a diagram showing details of the processing procedure of the business process analysis / macro service generation program of FIG. 2, and FIG. 12 is an output from the macro service used by the business process analysis / macro service generation program of FIG. FIG. 13 shows a macro service WSDL generated by the business process analysis / macro service generation program of FIG. 2, and FIG. 14 shows a macro used by the business process analysis / macro service generation program of FIG. Example of display of function summary screen for service, Fig. 15 shows business pro (In granularity operational level, the macro after service generation) business process building screen to build the program uses a display example of.

  In FIG. 4, a business process construction screen 400 includes a granularity display unit 4001, a tool unit 4002 that collects parts for graphically designing a business process, a design field 4003 that serves as a place for assembling a business process by arranging parts. A registration button 4004 for registering the registered business process in the business process design information repository (120 in FIG. 2), a macro service generation button 4005 for generating a macro service from a subset of business processes, and a service information repository (121 in FIG. 2). The service information display unit 4006 that displays a list of services belonging to this granularity in the service information registered in (1)) and the activity selected in the design field 4003 are allocated to the service selected in the service information display unit 4006. Consisting of service allocation button 4007 for shining.

  The tool unit 4002 includes, for example, a transition icon 40021, a service call icon 40022, a determination icon 40023, a merge icon 40024, a branch icon 40025, a data conversion icon 40026, a subset designation icon 40027, and the like as shown in FIG.

  In FIG. 4, only the data heading is displayed on the service display unit 4006 and no specific service is displayed. This is because the service of the “business level” granularity indicated by the granularity display unit 4001 is the service information repository. This is because it is not registered in (121 in the figure).

  In step S001 of FIG. 3, when the business level designer uses the screen as shown in FIG. 4 to construct the business level business process, the implementation level designer in step S002 of FIG. Create implementation level process from business level business process. About the business process of a certain granularity, since the means for creating a business process with a finer granularity is described in a publicly known example (for example, Patent Document 1 above), it is omitted here.

  For example, in FIG. 5 showing a business process at an implementation level granularity, the service call 40031 in FIG. 4 is in the service call group 5002, the service call 40032 in FIG. 4 is in the service call group 5003, and the service call 40033 in FIG. Each group 5004 is detailed.

  Of these three service call groups, only 5002 is subjected to subset designation which can be designated by clicking the subset designation icon 40027, and the other two service call groups are indicated by dotted rectangles for convenience of explanation. Surrounding. At this implementation level, unlike the business level, a service information repository 121 is prepared, which is read by the business process construction program 111 and listed in the service information display unit 4006 as shown in FIG.

  Here, in addition to ID 40060, URL 40061, and function summary 40067 as service information, minimum processing time 40062, maximum processing time 40063, average processing time 40064, waiting time 40065, average processing number 40046, etc. are held as non-functional information. . The designer at the implementation level first selects one service call on the design field 4003, then selects one appropriate service from the service information display unit 4006, and presses the assign button 4007 to select on the 4003. The service selected on 4006 is assigned to the service call made.

  By performing this operation for each service call, it is possible to create a SOA business process that is completed at the implementation level, that is, to which a service has been allocated.

  In step S002 of FIG. 3, data association is performed as necessary. Data association means associating variables that are called differently depending on services while pointing to the same concept. For example, it is assumed that the service ID “Service A” is assigned to the service call “Web11” 50021 in the service call group 5002 in FIG. 5 and the service ID “Service B” is assigned to the service call “Web12” 50023.

  In service A, the name of the product is handled by a variable name “product name” and the price of the product is handled by a variable name “price”. In service B, the name of the product is handled by a variable name “name” and the price of the product is handled by a variable name “price”. Shall. At this time, in order to link Service A and Service B in a business process, it is necessary to associate variables.

  For this purpose, the designer at the implementation level places a data conversion activity 50023 and double-clicks this activity icon. By this operation, the data association program (112 in FIG. 2) is activated, and a data association screen as shown in (a) of FIG. 6 is presented to the designer. This screen includes a node (such as 6001) representing a service, a node (such as 6002) representing a variable handled by the service, and a determination button 6004. The designer defines the association between the variables by connecting the nodes of the variables to be associated with an association line (such as 6003) (FIG. 6B).

  Then, when the designer presses the decision button 6004, the data association program 112 generates data related information as shown in FIG. 6C from the related line given by the designer. This data related information is held in the business process as internal data of the data conversion activity 50022 (a specific holding format will be described later).

  This data association method is a publicly known technology (for example, an implementation in the product “WebSphere” manufactured by IBM Corporation) → http://www-06.ibm.com/jp/domino01/mkt/websphere.nsf/499721c3388537bd49256b1001aab 49256dcd001965530492570a000201ff4 / $ FILE / WPSV6_08_WSBPEL20.pdf, etc. P.13), and therefore detailed description of the method is omitted here.

  Next, a procedure for the business process analysis / macro service generation program 113 to generate a macro service from a subset of implementation level business processes in step S003 of FIG. 3 will be described.

  This program is activated when a designer designates a specific activity group as a subset as indicated by 5002 in FIG. 5 and presses a macro service generation button 4005. FIGS. 7 and 8 are examples of address book service and postal code service WSDL files (files in the WSDL format describing the interface of the service) used in the following description. FIG. 9 shows an example of a business process BPEL file (BPEL file for describing a business process) for calling an address book service and a postal code service.

  “Http://www.w3.org/TR/wsdl” for WSDL, “http://www.oasis-open.org/apps/org/workgroup/wsbpel/documents.php” (free) for BPEL Refer to the standard document group.

  FIG. 7 is an example of WSDL related to the “address book service” (see the second line). In lines 13-18, this service has a portType called “Address Book portType” (a concept similar to the “interface” of Java (registered trademark)), and an operation (function) called “Obtain Current Address” exists in the portType. The operation indicates that it has an input message (variable group) “name” and an output message (variable group) “current address”.

  The 7th to 9th lines indicate that the message (variable group) “name” is composed of a character string type part (variable) “name”, and the 10th to 12th lines are the message (variable group) “current address”. Is composed of a character string type part (variable) “current address”.

  FIG. 8 is an example of WSDL related to the “postal code book service” (see the second line). Lines 13 to 18 show that this service has a port type called “zip code search portType” (a concept similar to the “interface” of Java (registered trademark)), and the operation (function) called “postal code acquisition” is included in the portType. It indicates that the operation has an input message (variable group) “address” and an output message (variable group) “zip code”.

  The 7th to 9th lines indicate that the message (variable group) “address” is composed of the character string type part (variable) “address”, and the 10th to 12th lines are the message (variable group) “zip code”. "Is composed of a character string type part (variable)" number ".

  FIG. 9 is a part of a business process called “integrated service”, mainly using a subset for obtaining a zip code from a person's name by using the two services shown in FIG. 7 and FIG. It is excerpted.

  The third and fourth lines indicate that the name space prefix “address” corresponds to the address book service, and the name space prefix “postal” corresponds to the postal code service. The 9th to 12th lines are “address book address”, “address book name”, “postal code book address”, “postal code” variable (variable group in BPEL), “current address” of address book service, address book service, respectively. "Name", postal code book service "address", and postal code book service "zip code" message (a variable group in WSDL).

  The <sequence> element from the 15th line to the 40th line represents the processing of the entire “integrated service”, and as a subset of the process, invoke (service call) on the 19th to 23rd lines, assign (variable) on the 25th to 30th lines , There is an invoke (service call) on the 32nd to 36th lines. Invoke on lines 19-23 calls current address acquisition operation (function) of address book portType belonging to address book service, gives variable address book name as input variable group, and receives variable address book address as output variable activity It is.

  Invoke on lines 32 to 36 calls a zip code acquisition operation (function) of a zip code search portType belonging to the zip code book service, gives a variable zip code book address as an input variable group, and variable mail as an output variable group. An activity that receives a number.

  The assignments in the 25th to 30th lines are activities that define the relationship between the variables between the above two invokes, and the variable “address” variable of the variable address book address is set to the variable of the variable postal code book address. Copying to "Address".

  That is, when the notation of FIG. 6C is used, the relationship shown in the table of FIG. 10 exists, and the variable “current address” of the address book service is related to the variable “address” of the postal code book service. Indicates that Such a relationship is expressed by using an assign activity as exemplified in the 25th to 30th lines in BPEL.

  The above is an example of WSDL and BPEL handled in step S003 in FIG. 3. Next, a procedure for generating a macro service WSDL by analyzing a subset of BPEL in step S003 will be described.

  As shown in FIG. 11, step S1401 is a step of extracting input variables in all service calls of the BPEL subset. For example, in the example of the subset of BPEL in FIG. 9, the “name” of the variable address book name in the service call (invoke) on the 19th to 23rd lines and the variable zip code list in the service call (invoke) on the 32nd to 36th lines. There is an “address” for the address.

  In the next step S1402, except for the input variable extracted in step S1401, the variable itself or a variable associated with the variable is included in the output variable of another service call, the “input variable to the macro service” It is a step.

  In the example of FIG. 9, the “address” of the variablebe postal code book address that was one of the input variables is associated with the “current address” of the variable address book address by the <assign> element on the 25th to 30th lines. The variable address book address is included in an output variable (outputVariable) in the service call on the 19th to 23rd lines.

  Therefore, the “address” of the variable zip code book address is excluded from the two input variables extracted in step S1401, and only the “name” of the variable address book name is set as the “input variable to the macro service”.

  Next, in step S1403, the present system presents output variables of a subset of BPEL to the designer, and the designer selects “output variables from the macro service” from among them. In this step, since the system cannot automatically determine the output variables required for this service, a selection process by the designer is necessary.

  Here, an example of an “output variable selection screen from the macro service” presented to the user by the business process analysis / macro service generation program 113 is shown in 1501 of FIG. Reference numeral 1502 denotes an output variable display unit. The designer highlights and selects a variable to be output from the macro service from among the output variables displayed here, and finally presses a decision button 1503. Decide by.

  In the example of FIG. 12, the “number” of the postal code book service, that is, the “number” of the variable postal code is selected as the “output variable from the macro service”.

  Next, in step S1404, the business process analysis / macro service generation program 113 generates a macro service input message element from the “input variable to the macro service”, and the macro service output variable from the “output variable from the macro service”. An output message element is generated. FIG. 13 shows an example of a macro service WSDL generated by the business process analysis / macro service generation program 113.

  In step S1404, the input message element “address book name” (6th to 8th lines) including the input variable “name” (7th line) to the macro service obtained in step S1402, and the output obtained in step S1403. An output message element “zip code” (9th to 11th lines) including the variable “number” (10th line) is generated.

  The names of these messages (name attribute) are acquired from the names of variables that included variables. In step S1405, the business process analysis / macro service generation program 113 generates an operation element that uses the input message as an input element and the output message as an output element.

  In the example of FIG. 13, an operation (lines 13 to 16) in which the input message “name of address book” is an input element (14th line) and the output message “zip code” is an output element (15th line). ).

  In step S1406, the business process analysis / macro service generation program 113 generates a portType having the above operation as the only child element. In the example of FIG. 13, this is a step of generating a portType (12th to 17th lines) in which the operation (13th to 16th lines) generated in step S1405 is the only child element.

  Finally, in step S1407, the business process analysis / macro service generation program 113 generates a definitions element that includes all the elements generated in steps S1404 to S1406. In the example of FIG. 13, the definition elements (2nd to 18th lines) including all the elements (6th to 17th lines) generated in steps S1404 to S1406 are generated.

  As described above, the business process analysis / macro service generation program 113 generates the WSDL-format macro service interface as illustrated in FIG. 13 from the subset of the BPEL-type business processes by the procedure shown in steps S1401 to S1407. Can do.

  Next, in step S1408, the designer gives a functional overview to the macro service. An example of a function outline addition screen displayed by the business process analysis / macro service generation program 113 is shown in 1701 of FIG. Reference numeral 1702 denotes a function outline input unit for inputting a character string representing the outline of the function. Reference numeral 1703 denotes a service granularity input part for the designer to input the granularity of the macro service.

  By inputting these items and subsequently pressing the enter button 1704, the macro service is provided with the function outline and granularity.

  Finally, in step S1409, the business process analysis / macro service generation program 113 calls the simulation program 114 to execute simulation based on the non-functional information of the detailed level service, thereby setting the non-functional information of the macro service. To do. Non-functional information and simulation based thereon are existing technologies, and non-functional information management is realized by Japanese Patent Application No. 2006-201907 (in this patent, non-functional information is described as “non-functional requirements”). The simulation is implemented by IBM's product WebSphere (http://www-06.ibm.com/jp/software/websphere/) and the like, so detailed description is omitted here.

  A business-level macro service is generated through steps S1401 to S1409, and step S003 in FIG. 3 is completed.

  Next, in step S004 of FIG. 3, a business-level designer assigns a macro service to a business-level business process. This is performed using a business process construction screen at the business level displayed by the business process construction program 111.

  FIG. 15 shows an example of the business process construction screen. In the stage of FIG. 4 corresponding to step S001 of FIG. 3, the service information display section 4006 is blank because the service at the business level is not prepared, but the service of FIG. 15 corresponding to step S004 of FIG. In the information display unit 4006, the macro service generated in step 003 in FIG. 3 is listed as a business level service.

  The business-level designer selects a service to be assigned to the activity (ex. 40031) selected on the design field 4003 from the service information display unit 4006 and presses an assign button 4007 to assign the service to the corresponding activity. .

  Thus, the design procedure shown in FIG. 3 is completed. The business-level designer proceeds with the design of the SOA system by trial and error using this design data, or uses the non-functional information of the service assigned to each activity to perform simulation using the simulation program 114 Can be performed.

  Thus, in this embodiment, for example, the effect is exhibited in the following scenario (see FIG. 16). FIG. 16 is a diagram showing an outline in the case where the problem of the current SOA system design means is solved using the technique of the present invention.

  There are two characters, a designer in charge at a business level (a level of coarser granularity) and a designer in charge of an implementation level (a level of finer granularity). Business level personnel want to complete the design of the SOA system at the business level, but services are available only at the implementation level.

  [Scenario Step 1] The business level designer informs the implementation level designer of the content of the business he / she thinks.

  [Scenario Step 2] The designer at the implementation level constructs an implementation-level business process that realizes the interviewed business in such a manner that one activity at the business level corresponds to one subset of the implementation level (501 in FIG. 16). .

  [Scenario Step 3] A designer at the implementation level generates a macro service in a form corresponding to each subset of the implementation level at 1: 1 (502 in FIG. 16).

  [Scenario Step 4] A business designer can implement knowledge level design at the implementation level that is closed at the business level by assigning a macro service to each activity of the business process at the business level (503 in FIG. 16). It becomes like this.

  As a result, a business-level designer can use an existing BPEL + WSDL-compatible tool to perform operation verification and simulation at the business level, and to proceed with design by trial and error.

  As mentioned above, the invention made by the present inventor has been specifically described based on the embodiment. However, the present invention is not limited to the embodiment, and various modifications can be made without departing from the scope of the invention. Needless to say.

  The present invention relates to a Web service design apparatus and method, and is widely applicable to apparatuses and systems in which the granularity of system components of a business process to be designed differs from the granularity of services assigned to the components of a business process.

It is a block diagram which shows the structure of the system design support apparatus of the SOA architecture which concerns on one embodiment of this invention. It is explanatory drawing for demonstrating the outline | summary of the function of each program in the system design support apparatus of the SOA architecture which concerns on one embodiment of this invention, and the relationship with each information stored in a magnetic disc unit. It is a flowchart which shows the procedure in the case of designing the system of SOA architecture using the system design support apparatus of SOA architecture which concerns on one embodiment of this invention. It is a display example of the business process construction screen (granularity is business level) used by the business process construction program of the SOA architecture system design support apparatus according to the embodiment of the present invention. It is a display example of the business process construction screen (granularity is implementation level) used by the business process construction program of the system design support apparatus of the SOA architecture according to the embodiment of the present invention. It is a figure which shows the example of the rough structure of the data correlation screen which the data correlation program of the system design support apparatus of the SOA architecture which concerns on one embodiment of this invention uses, and the data relevant information produced | generated by the screen. It is a figure which shows the WSDL description of the address book service handled as an example of the service of the implementation level of the system design support apparatus of the SOA architecture which concerns on one embodiment of this invention. It is a figure which shows the WSDL description of the postal code book service handled as an example of the implementation level service of the system design support apparatus of the SOA architecture which concerns on one embodiment of this invention. It is a figure which shows the BPEL notation of the integrated service handled as an example of the business process of the implementation level of the system design support apparatus of the SOA architecture which concerns on one embodiment of this invention. It is a figure which shows the example which associates a variable between the address book service of the system design support apparatus of the SOA architecture which concerns on one embodiment of this invention, and a postal code book service. It is a figure which shows the detail of the process sequence of the business process analysis / macro service generation program of the system design support apparatus of the SOA architecture which concerns on one embodiment of this invention. It is a display example of the output variable selection screen from the macro service used by the business process analysis / macro service generation program of the system design support apparatus of the SOA architecture according to the embodiment of the present invention. It is a figure which shows WSDL of the macro service which the business process analysis / macro service generation program of the system design support apparatus of the SOA architecture which concerns on one embodiment of this invention produces | generates. It is a display example of the function summary addition screen to the macro service used by the business process analysis / macro service generation program of the system design support apparatus of the SOA architecture according to the embodiment of the present invention. It is a display example of the business process construction screen (after the generation of the macro service at the granularity at the business level) used by the business process construction program of the system design support apparatus of the SOA architecture according to the embodiment of the present invention. It is a figure which shows the outline | summary in the case of trying to solve the problem which the present SOA system design means has using the method of this invention. It is explanatory drawing for demonstrating the subject which the present SOA system design means has. It is a figure which shows the outline | summary in the case of trying to solve the subject which the present SOA system design means has by applying the method of patent document 1. FIG.

Explanation of symbols

  DESCRIPTION OF SYMBOLS 100 ... System design support apparatus, 101 ... Central processing unit, 102 ... Keyboard, 103 ... Display, 104 ... Pointing device, 105 ... Main storage device, 106 ... Magnetic disk apparatus, 107 ... Bus, 110 ... Control program, 111 ... Business process construction program, 112 ... Data association program, 113 ... Business process analysis / macro service generation program, 114 ... Simulate program, 120 ... Business process design information repository, 121 ... Service information repository.

Claims (5)

An SOA architecture system design support method for building a business process and allocating services to its components,
A macro service that is a virtual service with a high degree of detail of system components from a subset of business processes to which the details of the details of system components are assigned by executing the processing means on the information processing apparatus. A system design support method for an SOA architecture, characterized in that: The SOA architecture system design support method according to claim 1,
By the business process analysis / macro service generation means included in the processing means, a macro service that is a virtual service with a high degree of detail of system components from a subset of business processes to which a service is assigned with a fine degree of detail of system components. Produces
A SOA architecture system design support method, wherein non-functional information of the entire subset is calculated from non-functional information of individual components constituting the subset of the business process by a simulation means included in the processing means. The system design support method of the SOA architecture according to claim 1 or 2,
The business process construction means included in the processing means constructs a business process at a specific granularity,
A system design support method for an SOA architecture, wherein a service is assigned to a component of the business process at a specific granularity by a data association means included in the processing means. An SOA architecture system design support device that builds a business process and allocates services to its components,
A main storage device in which processing means is stored;
A central processing unit that executes the processing means stored in the main storage device,
The central processing unit executes the processing means, and generates a macro service, which is a virtual service with a high degree of detail of system components, from a subset of business processes to which a service is assigned with a fine level of details of system components. An SOA architecture system design support device characterized in that: The SOA architecture system design support apparatus according to claim 4,
The processing means includes a business process analysis / macro service generation means for generating a macro service from a subset of business processes to which a service having non-functional information that is information on performance and architecture is assigned, and the business A system design support apparatus for SOA architecture, comprising: a simulating means for calculating non-functional information of the entire subset from non-functional information of individual components constituting the subset of processes.

Images