JP2006251974A - Information processor and processing method - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To differentiate executed sub-processing in response to executed processing, according to a request from a requester. <P>SOLUTION: An information processing system is provided with a processing execution means 55 for executing the processing according to the request from the requester, a sub-processing selection means 55 for selecting one or more of the sub-processings corresponding to the processing, among the plurality of sub-processings, based on the request, and a sub-processing execution means 55 for executing the selected sub-processing at least before or after execution. <P>COPYRIGHT: (C)2006,JPO&NCIPI

Description

  The present invention relates to information processing technology, and specifically, to information processing technology using, for example, EJB (Enterprise JavaBeans).

  For example, there is a system including a client machine and a server system. For example, the server system can be constructed in three layers including a presentation layer, a business logic layer, and a data store layer. The presentation layer is a layer that can provide a user interface for receiving input from the user and outputting information to the user, and can be realized by, for example, a WEB server. The business logic layer is a layer for performing information processing, and can be realized by an EJB server, for example. The data store layer is a layer for storing information, and can be realized by a database, for example.

  As information processing technology using EJB (Enterprise JavaBeans), for example, technologies disclosed in Patent Documents 1 to 5 are known.

JP 2000-250768 A JP 2002-082926 A JP 2003-323405 A JP 2004-086355 A JP 2004-318831 A

  In the above system, the EJB server can receive a request to execute processing from the WEB server, and can execute processing according to the request in response to the request. Here, in addition to the processing, the EJB server has a different sub-process (for example, logs the time when executing the first process, logs the failure when a failure occurs, etc.) In some cases, you may want to perform additional processing. At that time, if the executed sub-process can be changed depending on what is executed, the convenience is expected to increase.

  This is considered to be the same not only for the EJB server but also for other types of servers.

  Accordingly, one of the objects of the present invention is to make it possible to change the sub-process to be executed depending on what is executed according to the request from the request source.

  An information processing system according to one aspect of the present invention includes: a process execution unit that executes a process according to a request from a request source; and one or more sub-processes corresponding to the process from a plurality of sub-processes based on the request Sub-process selection means for selecting, and sub-process execution means for executing the selected sub-process at least one of before and after execution of the process.

  Here, the “information processing system” may be configured by a single computer machine or may be configured by a plurality of computer machines.

  In one embodiment, the information processing system can include a storage unit that stores a plurality of sub-process IDs and a plurality of sub-process selection conditions respectively corresponding to a plurality of sub-processes. The sub-process selection unit specifies one or more sub-process selection conditions that meet the request from the plurality of sub-process selection conditions, and one or more sub-process selection conditions corresponding to the specified one or more sub-process selection conditions. One or more sub-processes identified from the process ID can be selected.

  In one embodiment, the sub-process selection condition may include a keyword. The sub-process selection unit may specify one or more sub-process selection conditions that match the request based on a specific character string included in the request and a keyword constituting the sub-process selection condition. it can.

  In one embodiment, the sub-process selection condition may be composed of a combination of a keyword and a regular expression. The sub-process selection unit specifies one or more sub-process selection conditions that match the request based on a specific character string included in the request, and a keyword and a regular expression constituting the sub-process selection condition. can do.

  In one embodiment, the process may have one real name and one or more aliases. The request includes a specific character string, and the specific character string may represent either a real name or an alias of a process to be requested.

  The information processing system may include a storage resource that stores a plurality of computer programs and at least one computer that executes at least one of the plurality of computer programs stored in the storage resource. The plurality of computer programs may include an acceptance program that accepts a processing request from a request source, and one or more processing programs that execute predetermined processing. In the processing request, a plurality of processing targets to be executed and an execution order of the plurality of processing targets may be defined. The receiving program receives the processing request (for example, receives the processing request regardless of the content of the processing request from the request source), analyzes the received processing request, and is defined in the processing request In the execution order, each of a plurality of processing targets defined in the processing request may be requested to at least one of the one or more processing programs. The processing program that has received the processing request from the receiving program may perform the requested processing target processing.

  Here, the “information processing system” may be configured by a single computer machine or may be configured by a plurality of computer machines. Further, the “computer” may be a computer machine or a processor (for example, CPU) mounted on the computer machine. Further, the “storage resource” may be configured by at least one of a plurality of storage devices (for example, a hard disk or a memory).

  In one embodiment, the processing request may define at least one transaction isolation range and a processing target belonging to the transaction isolation range. For the processing target belonging to the transaction isolation range, the accepting program can request the one or more processing programs to perform processing independent of the transaction related to the processing target not belonging to the transaction isolation range.

  In one embodiment, the one or more processing programs include a first processing program for executing a first processing and a second processing program for executing a second processing different from the first processing. And can be included. When the acceptance program detects the transaction separation range by analyzing the received processing request, the processing is requested to the first processing program, and when the processing target is detected, Processing can be requested to the second processing program.

  In one embodiment, the accepting program and the second processing program may have the property of returning to the caller and committing (for example, it may be an EJB with a required attribute). The first processing program can have a property of creating a new transaction and completing the transaction without participating in the caller transaction (for example, it can be assumed that the EJB has an attribute of “Requires New”. ). The first processing program that has received a processing request from the accepting program can request the second processing program for processing to be processed belonging to the transaction isolation range. The second processing program that has received a processing request from the accepting program or the first processing program can execute the requested processing target process and return the execution result to the request source. When the first processing program receives the execution result from the second processing program, the first processing program may commit the transaction related to the requested processing without participating in the transaction of the receiving program that is the processing request source. it can. When receiving the execution result from the second processing program, the receiving program can commit the transaction related to the requested processing.

  In one embodiment, the processing request may define a further transaction isolation range included in the transaction isolation range. When the further transaction isolation range is detected, the first processing program can request the processing of the further transaction isolation range from itself.

  In one embodiment, the one or more processing programs may include an execution program that executes a requested processing target process. The accepting program and the execution program may have a property of returning to the caller and committing (for example, it may be an EJB with an attribute of Required). The execution program that has received a processing request from the receiving program can execute the requested processing target process.

  The information processing system may include a storage resource that stores a plurality of computer programs and at least one computer that executes at least one of a large number of computer programs stored in the storage resource. The multiple computer programs may include a plurality of processing element execution programs and a number of processing programs smaller than the number of processing element execution programs. Each of the plurality of processing element execution programs may execute a predetermined processing element among one or more processing elements constituting a predetermined processing target process. The processing program may execute the predetermined processing target process by executing one or more processing element execution programs that respectively execute one or more processing elements constituting the predetermined processing target process. .

  In one embodiment, each processing definition data corresponding to each processing target may be stored in the storage resource. Each process definition data can describe a definition relating to an execution procedure of one or more process elements constituting each process target process. The processing program can execute the processing of the predetermined processing target based on the process definition data corresponding to the predetermined processing target.

  In one embodiment, at least one of one or more computer programs other than the plurality of processing element execution programs is defined by the process definition data based on the process definition data corresponding to the predetermined process target. A process execution target for executing one or more process elements defined by the process definition data in the execution procedure can be generated. When the processing program executes the process execution target, the predetermined process target process can be executed.

  In one embodiment, the process definition data includes, as a definition relating to the execution procedure, an output of a first process element execution program that is input to a second process element execution program. Processing using the output may be described. In accordance with the process definition data, the process execution target inputs the output of the first process element execution program to a second process element execution program and performs processing using the output of the second process element execution program. Can be done.

  In one embodiment, the plurality of computer programs may include an acceptance program that accepts a processing request from a request source. The receiving program receives a processing request from the request source, analyzes the received processing request, and requests the processing program to process each of one or more processing targets defined in the processing request. Can do. The processing program can perform processing of a processing target requested by the receiving program. The acceptance program and the processing program may be an EJB as a stateless session bean.

  In one embodiment, the process definition data describes that a process execution target generated based on the process definition data releases resources reserved for the one or more process element execution programs. May be. The processing execution target can release resources reserved for the one or more processing element execution programs.

  In one embodiment, the plurality of computer programs may include an acceptance program that accepts a processing request from a request source. The receiving program receives a processing request from the request source, analyzes the received processing request, and requests the processing program to process each of one or more processing targets defined in the processing request. Can do. The processing program can perform processing of a processing target requested by the receiving program.

  In one embodiment, resource release means for releasing resources reserved for the one or more processing element execution programs to be executed out of one or more computer programs different from the plurality of processing element execution programs is provided. The resource releasing means is not the one or more processing element execution programs.

  Hereinafter, an embodiment of the present invention will be described with reference to the drawings.

  FIG. 1 is a block diagram showing an outline of a hardware configuration of a system according to an embodiment of the present invention.

  A server system 6 is communicably connected to the client system 3 (for example, via a communication network such as the Internet).

  The client system 3 is a computer system including hardware resources such as one or more CPUs (Central Processing Units) 13 and one or more storage resources (for example, one or more memories 15 and one or more hard disks 17). The client system 3 can be configured as, for example, a personal computer, a workstation, a main frame, or the like. The client system 3 can also include an information input device (not shown) such as a keyboard switch, a pointing device, and a microphone, and an information output device (not shown) such as a monitor display and a speaker, for example.

  The server system 6 can be configured in, for example, three layers including a presentation layer, a business logic layer, and a data store layer. In this case, for example, the presentation layer can be composed of the WEB server 5, the business logic layer can be composed of the EJB server 7, and the data store layer can be composed of the database 38. The WEB server 5 is a computer system including hardware resources such as one or more CPUs 23 and one or more storage resources (for example, one or more memories 25 and one or more hard disks 27). The EJB server 7 is also a computer system including hardware resources such as one or more CPUs 33 and one or more storage resources (for example, one or more memories 35 and one or more hard disks 37). Although not shown, the database 38 can also be a computer system provided with hardware resources such as one or more CPUs and one or more storage resources.

  The configuration of the server system 6 is not limited to the illustrated configuration, and other configurations can be employed. In addition, at least one of the client system 3, the WEB server 5, the EJB server 7, and the database 38 may be configured by a single computer system or may be configured by a plurality of computer systems. .

  FIG. 2 is a block diagram showing an outline of the software configuration of the system shown in FIG.

  The client system 3 can include a WEB browser 43. The WEB browser 43 can issue a request to the WEB server 5 and can receive and display information according to the request from the WEB server 5.

  The WEB server 5 includes a facade value storage area 49 and an external application 45.

  The facade value storage area 49 is provided on the storage resource described above, and can store one or more facade values. The facade value is one feature in the present embodiment, and is a command package that can describe a transaction as a flow. The facade value will be described in detail later.

  The external application 45 is an application program that exists outside the EJB server 7 and is read into the CPU 23 from the memory 25 to acquire information from the EJB server 7 or provide the acquired information to the WEB browser 43. can do. Specifically, for example, the external application 45 includes a facade value selection program 47, and the program 47 stores a facade value corresponding to a request (for example, a screen switching request) from the WEB browser 43 in the facade value storage area 49. The selected facade value is sent to the EJB server 7. Thereby, the external application 45 can receive information according to the request from the WEB browser 43 from the EJB server 7 and provide the received information to the WEB server 5. In this embodiment, it is assumed that a facade value is stored in the facade value storage area 49 for each process requested by the WEB server 5 to the EJB server 7. However, for example, the administrator of the WEB server 5 creates a facade value at an arbitrary timing using an information input device such as a keyboard, and stores the created facade value in the facade value storage area 49, or creates the created facade. The value can be transmitted from the WEB server 5 to the EJB server 7.

  The EJB server 7 has a bean flow definition file storage area 57 in which a bean flow definition file described later is stored, a bean flow storage area 59 in which a bean flow described later is stored, and a program module in which a plurality of program modules are stored. A storage area 61, an interceptor definition file storage area 63 in which an interceptor definition file described later is stored, and an EJB container 14 in which a plurality of EJBs are deployed are provided. Each of the storage areas 57, 59, 61 and 63 is provided on the storage resource described above. Examples of the program module stored in the program module storage area 61 include a bean and an interceptor (which may also be a bean). A bean stored in the storage area 61 can be a POJO (Plain Old Java Object) instead of an EJB by a device described later. As a plurality of EJBs deployed in the EJB container 14, for example, there are a facade layer EJB 51, a transaction separation layer EJB 53, and a bean flow execution layer EJB 55. The various computer programs such as the EJBs 51, 53, and 55, and beans and interceptors, which will be described later, are executed by being read from a storage resource by the CPU.

  The facade layer EJB 51 serves as a call port for the caller (the WEB server 5 in this embodiment), and is an EJB that receives and interprets the facade value issued from the caller. The same facade layer EJB 51 is called regardless of the description contents of the facade value. In other words, regardless of the flow defined by the facade value, the single facade layer EJB 51 is sufficient for the facade value reception port. The reason why this can be done will be described in detail later.

  The transaction layer EJB 53 is an EJB that processes a unit of work defined by a facade value. The unit of work will be described in detail later.

  The bean flow execution layer EJB 55 is an EJB that processes a command object defined by a facade value. The command object will be described later in detail.

  The three EJBs 51, 53, and 55 described above and the beans stored in the program module storage area 61 can operate by being read by the CPU 33. When the EJB server 7 is a distributed system constructed by a plurality of computer systems, it is stored in the EJB 51, 53 or 55 or the program module storage area 61 by being read by each CPU of each computer system. The program module being operated can operate.

  Although there are several types of EJBs, the above-described EJBs 51, 53, and 55 are all stateless session beans (that is, EJBs that do not hold state values).

  Among the EJBs 51, 53, and 55, the facade layer EJB 51 and the bean flow execution layer EJB 55 have, for example, an attribute “Required” as the first attribute, and the transaction layer EJB 53 has, for example, “Requires New ”Attribute. The EJB having the attribute “Required” has the property of participating in the caller transaction (specifically, the property of committing only after returning to the caller). An EJB with the attribute “Requires New” does not participate in the caller's transaction, and is newly independent within the scope of the call (ie, within the scope of reading the EJB method with the attribute “Requires New”). Has the property of creating transactions. For example, when an EJB having the attribute “Requires New” is called from the first EJB and calls the second EJB, the transaction of the second EJB is not participated in the transaction of the first EJB. Complete. As a result, for example, when a failure occurs in the processing of the first EJB, the first EJB transaction is rolled back, but the second EJB transaction is completed, so the second EJB transaction is completed. It is not rolled back until the EJB transaction.

  The above is the outline of the software configuration in the system according to this embodiment. Hereinafter, an outline of the flow of processing performed in the system will be described.

  FIG. 3 shows an outline of the flow of processing performed in the system shown in FIG.

  The external application 45 receives some instruction from the WEB browser 43 (step S1). The external application 45 can accept various instructions such as an instruction to change the screen configuration of the screen displayed on the WEB browser 43 or an instruction to withdraw from a bank account designated by the user.

  The external application 45 analyzes the received instruction, and searches the facade value storage area 49 (that is, among the plurality of facade values) for the facade value 46 corresponding to the analysis result by the facade value selection program 47 (S2). . Then, the external application 45 acquires the facade value 46 that has been searched for from the facade value storage area 49 (S3), calls the facade layer EJB 51, and transmits the acquired facade value 46 to the facade layer EJB 51 (S4).

  The facade layer EJB 51 is called from the external application 45, receives the facade value 46, analyzes the received facade value 46, and selects either the transaction separation layer EJB 53 or the bean flow execution layer EJB 55 according to the analysis result. Select whether to call, and call the selected EJB 53 or 55 to request processing. Specifically, when the facade layer EJB 51 detects a unit of work (transaction boundary object) described later as a result of the above analysis, it calls the transaction separation layer EJB 53 to request processing of the unit of work. If a command object to be described later is detected, the bean flow execution layer EJB 55 is called to request processing of the command object. When the transaction separation layer EJB 53 detects another unit of work in the unit of work during processing of the unit of work, the transaction separation layer EJB 53 calls itself to perform the processing of the other unit of work (that is, recursion). When a command object in the unit of work is detected, the bean flow execution layer EJB55 is called to request processing of the command object. The bean flow execution layer EJB 55 executes processing of the requested command object. As described above, the EJB server 7 performs processing according to the description of the facade value 46 received by the facade layer EJB 51 (S5).

  In the present embodiment, as described above, if there is one facade layer EJB 51 capable of interpreting the facade value 46 regardless of the flow defined by the facade value 46, the calling port is one of these. Just do it. Hereinafter, the configuration of the facade value 46 and the processing flow performed when the facade value 46 is processed (that is, an example of the details of the above S5) will be described.

  FIG. 4A shows an example of the configuration of the facade value.

  In the facade value 46, both a unit of work and a command object can be described.

  A unit of work is an object that represents a transaction boundary (in other words, “separation”). Another unit of work can be described in one unit of work, and one or a plurality of command objects can be described.

  The command object is an object corresponding to one command, and includes a key (for example, command name) for specifying a bean flow to be described later, and is for instructing execution of the bean flow corresponding to the key. The command object includes, for example, a bean flow key 72, an input object 74, an output object 76, and an exception object 78 as illustrated. The bean flow key 72 is a key for obtaining a bean flow from the bean flow storage area 59. The bean flow key 72 can also be used as a key for obtaining an interceptor from the program module storage area 61. The input object 74 is an object that can be input to a bean that executes a command (bean flow) specified by the command object. The output object 76 is an object that can hold the execution result of the command. The exception object 78 is an object that can hold an exception that occurred during execution of the command.

  The unit object and command object described in the facade value are processed in order from the top of the facade value. Therefore, depending on how the command object and unit of work are arranged on the facade value, and how the command object (or unit of work) is arranged in the unit of work, the flow of the transaction Can be defined. That is, a transaction can be controlled from a caller (a WEB server in this embodiment) by using a facade value. Hereinafter, one specific example will be described.

  For example, assume that the caller wants to execute commands (bean flow) A, B, and C. However, it is assumed that the execution of the command A and the command C is executed as a transaction independent from the caller, and the execution of the command B is desired to participate in the caller transaction.

  Transaction separation is performed by using a unit of work which is an object for separating transactions. That is, in order to perform the transaction control as in the above example, as shown in FIG. 4A, the first unit object including the command object A for executing the command A at the head of the object group in the facade value 46 is used. A work 10A is described, a command object B for executing the command B without being included in the unit of work is described next to the first unit of work 10A, and a command C is described next to the command object B. It is necessary to describe the second unit of work 10B including the command object C for executing the above.

  If the facade value 46 shown in FIG. 4A is transmitted from the external application (hereinafter referred to as an external AP) 45 to the EJB server 7, the EJB server 7 performs processing in the flow shown in FIG. 4B.

  FIG. 4B shows a processing flow of the facade value 46 shown in FIG. 4A.

  When the facade layer EJB 51 is called from the external AP 45 and the facade value 46 is transmitted (S4 in FIGS. 3 and 4B), the facade layer EJB 51 receives the facade value 46, and processing according to the description of the facade value 46 is performed. This is performed (S5 in FIG. 3).

  Specifically, the facade layer EJB 51 analyzes the received facade value 46. Thereby, it is detected that the flow is configured in the order of the first unit of work 10A, the command object B, and the second unit of work 10B.

  When the first unit of work 10A is detected, the facade layer EJB 51 calls the transaction separation layer EJB 53, and requests the transaction separation layer EJB 53 to process the first unit of work 10A (S5A).

  The called transaction separation layer EJB 53 performs processing of the first unit of work 10A in accordance with a request from the facade layer EJB 51. Specifically, for example, the transaction separation layer EJB 53 analyzes the first unit of work 10A. Since the first unit of work 10A includes the command object A, the command object A is detected. When the command object A is detected, the transaction separation layer EJB 53 calls the bean flow execution layer EJB 55 and requests the bean flow execution layer EJB 55 to process the command object A (S5B).

  The called bean flow execution layer EJB 55 executes processing of a command (bean flow) specified from the command object A in accordance with a request from the transaction separation layer EJB 53 (S5C), and sends a response (for example, processing result) to the caller. Is returned to the transaction separation layer EJB 53 (S5D).

  When receiving a response from the callee bean flow execution layer EJB 55, the transaction separation layer EJB 53 commits the command object A requested for processing in S5B (S5E-1 to S5E-3).

  Specifically, when the transaction separation layer EJB 53 receives a response from the callee bean flow execution layer EJB 55 and is ready to commit, it notifies the call facade layer EJB 51 (S5E). -1). When the facade layer EJB 51 receives a notification that the commit is ready, the facade layer EJB 51 sends a predetermined command (for example, commit execution command) to the transaction separation layer EJB 53 (S5E-2). The transaction separation layer EJB 53 commits the command object A when receiving a predetermined command from the facade layer EJB 51. Then, the transaction separation layer EJB 53 sends a notification that the commit has been completed to the facade layer EJB 51 (S5E-3). As a result, the facade layer EJB 51 can escape from the process for the command object A.

  As described above, when the unit of work is detected in the facade layer EJB 51, the transaction processing requested by the facade layer EJB 51 (that is, the transaction processing indicated by the unit of work) is changed from the facade layer EJB 51 to the transaction separation layer EJB 53. Newly requested. The new request destination is an EJB having the attribute “Requires New”, and the processing request of the command object in the unit of work from the EJB 53 of “Requires New” has the attribute “Required”. Issued to the bean flow execution layer EJB55. For this reason, the facade layer EJB 51 has the attribute “Required”. However, in the transaction processing represented by the unit of work, it is not necessary to participate in the transaction of the caller external AP 45. That is, transactions are separated.

  Next, the command object B described next to the first unit of work 10A is processed. That is, the facade layer EJB 51 calls the bean flow execution layer EJB 55 and requests the bean flow execution layer EJB 55 to process the command object B (S5F). In response to the request, the called bean flow execution layer EJB 55 processes the command object B (S5G), and returns a response (for example, a processing result) to the facade layer EJB 51 that is the call source (S5H).

  Next, regardless of whether the processing of the command object B is successful, the processing for the object described next to the command object B is performed. That is, here, the processing of the second unit of work 10B is performed. The processing flow for the second unit of work 10B is the same as the processing flow S5A to S5E-3 for the first unit of work 10A described above (S5I to S5M-3).

  When the preparation of the command object B is ready, the facade layer EJB 51 notifies the external AP 45 after S5M-3 (or at any timing of the facade layer EJB 51 after S5H). (S5N-1). When the external AP 45 receives notification from the facade layer EJB 51 that it is ready to commit, the external AP 45 sends a predetermined command (for example, a commit execution command) to the facade layer EJB 51 (S5N-2). When receiving the command, the facade layer EJB 51 commits the command object B, and when the commit is completed, sends a predetermined notification (for example, a completion notification of commit) to the external AP 45 (S5N-3).

  With the above flow, the facade value 46 illustrated in FIG. 4A is processed. As described above, since the transactions can be separated, for example, even if the processing of the command object B fails and the rollback occurs, the processing of the command object A can be performed independently without being rolled back. it can. That is, a process that is desired to be independent from the caller transaction is executed by the unit of work, and a process that is desired to participate in the caller transaction is executed by a command object that is not included in the unit of work.

  Next, the flow of processing performed by each of the EJBs 51, 53, and 55 will be described individually.

  FIG. 5A shows the flow of processing performed by the facade layer EJB51.

  When receiving the facade value (YES in S11), the facade layer EJB 51 analyzes the facade value (S12). Thereby, the execution order of the objects is known.

  If the object to be processed this time is a unit of work (YES in S13), the facade layer EJB 51 calls the transaction separation layer EJB 53 and requests the transaction separation layer EJB 53 to process the unit of work (S14). When the facade layer EJB 51 receives a response to the request (YES in S15), the facade layer EJB 51 performs specific processing (for example, performs the above S5E-2) (S15A). If all the objects in the facade value received in S11 have been processed (YES in S17), the facade layer EJB 51 waits for reception of the facade value, but if there is an unprocessed object remaining (in S17) NO), it returns to S13.

  If the object to be processed this time is a command object (NO in S13), the facade layer EJB 51 calls the bean flow execution layer EJB 55 and requests the bean flow execution layer EJB 55 to process the command object (S16). Thereafter, after a specific process is performed (for example, after the processes of S5H and S5N-1 to S5N-3 are performed) (S16A), the process of S17 is performed.

  FIG. 5B shows the flow of processing performed by the transaction separation layer EJB 53.

  When the transaction separation layer EJB 53 is called (YES in S20), it analyzes the unit of work requested to be processed (S21).

  If a command object is detected as a result of the analysis in S21 (NO in S22), the transaction separation layer EJB 53 calls the bean flow execution layer EJB 55 and requests the bean flow execution layer EJB 55 to process the command object (S24). ). Thereafter, if a response is received (YES in S25), the transaction separation layer EJB 53 performs a specific process (for example, performs the processes of S5E-1 to S5E-3) (S26).

  If the unit of work is detected as a result of the analysis in S21 (YES in S22), the transaction separation layer EJB 53 calls itself (S23) and returns to S21. That is, when a unit of work is detected in the unit of work, processing is performed recursively.

  FIG. 5C shows the flow of processing performed by the bean flow execution layer EJB55.

  When the bean flow execution layer EJB 55 is called (YES in S31), it processes the requested command object (S22), and sends a response (for example, a processing result) to its caller (facade layer EJB 51 or transaction separation). Return to the layer EJB53) (S33). When an exception (for example, an error) occurs in the process of S22, the bean flow execution layer EJB 55 can return a response (for example, an exception object) to the WEB server that is the transmission source of the facade value.

  According to the above description, it is possible to define a transaction flow on the facade value depending on what is described in the unit of work and how the command object and unit of work are arranged. The EJB server 7 is provided with a facade layer EJB 51 that receives and analyzes the facade value, a transaction separation layer EJB 53 that processes a unit of work, and a bean flow execution layer EJB 55 that processes a command object. The attribute of the facade layer EJB 51 and the bean flow execution layer EJB 55 is “Required”, and the attribute of the transaction separation layer EJB 53 is “Requires New”. A request for processing a command object not wrapped in a unit of work is sent from the facade layer EJB 51 to the bean flow execution layer EJB 55 without going through the transaction separation layer EJB 53, but the processing of the command object wrapped in the unit of work. The request is made from the facade layer EJB 51 to the bean flow execution layer EJB 55 via the transaction separation layer EJB 53. As described above, even if a lot of EJBs are not created, the caller controls the flow of transactions to the EJB server 7 regardless of the complicated EJB rules, by configuring the facade value on the call side. Can do. For example, if a facade value as illustrated in FIG. 6A is created and given to the EJB server 7, a transaction flow as illustrated in FIG. 6B can be executed (a dotted line in FIG. 6B indicates a transaction boundary).

  In the above description, the facade layer EJB 51 is called when the facade value is transmitted. Instead, for example, a queue for storing the facade value is provided in the EJB server 7 and received by the EJB server 7. The facade value is accumulated in the queue, and the facade layer EJB 51 can sequentially read the facade value from the queue and process it. That is, there is no need to worry about synchronization / asynchronization in stateless processing.

  Now, processing that can be performed by the above-described bean flow execution layer EJB 55 will be described in detail.

  FIG. 7A shows the flow of one process that can be performed by the bean flow execution layer EJB55.

  As shown in FIG. 7A, the bean flow execution layer EJB 55 selects one bean flow definition file 81 from one or more bean flow definition files stored in the bean flow definition file storage area 57, and selects the selected one. The bean flow definition file 81 is read (S41). The bean flow execution layer EJB 55 interprets the read bean flow definition file 81, creates a bean flow 83 based on the interpretation result, and stores the created bean flow 83 in the bean flow storage area 59. (S42).

  As a result, one or more bean flows are stored in the bean flow storage area 59.

  FIG. 7B shows an outline of the configuration of the bean flow definition file 81.

  The bean flow definition file 81 is a file in a predetermined format, for example, an XML (eXtensible Markup Language) format file. The bean flow definition file 81 is prepared, for example, one-to-one with a command object. The bean flow definition file 81 describes the definition of the bean flow. In the bean flow definition file 81, one or a plurality of bean flows can be defined. That is, it is possible to execute not only one bean flow but also a plurality of bean flows with one command object.

  The bean flow definition 90 includes, for example, a “flow name” that is the name of the bean flow, an “alias name” that is a false name of the bean flow, and resources that are to be secured when executing the bean flow. "Resource information" and "execution unit description" related to the execution of the beans constituting the bean flow.

  The alias name can be registered, for example, by the administrator on the call side or the administrator of the EJB server 7. Multiple alias names can be registered in one bean flow. For this reason, if the caller specifies a bean flow with an alias name for the EJB server 7, the same bean flow can be executed even with different alias names.

  The resource information includes, for example, a “resource name” that is the name of the resource and a “resource key” that is a key for acquiring the resource. Also, in the resource information, whether or not the bean flow performs flow control on the resource (for example, whether to instruct the resource to commit at the normal end and whether to instruct the resource to roll back at the abnormal end) Or information indicating whether or not the reserved resources are closed at the end of the bean flow.

  The execution unit description includes, for example, an “execution unit name” that is the name of the execution unit, a “class name” of the bean to be executed, a “method name” of the bean to be executed, and a getter that acquires an output object of the execution unit. The “getter name” that is the name of the name and “attribute information” regarding the attribute of the execution unit are included. When there are a plurality of execution units in one bean flow, a plurality of execution unit descriptions respectively corresponding to the plurality of execution units are arranged according to the execution order of the execution units. Here, the execution unit is a method (hereinafter, designated method) designated by a method name in a bean designated by a class name (hereinafter, designated bean). The attribute information includes, for example, a first attribute value that means that an instance of the specified bean is generated and the specified method is executed, and an input object to the bean flow is passed to the specified bean and the specified method is executed. At least one of the second attribute value meaning that the bean of the previous execution unit is passed to the designated bean and the designated method is executed can be included.

  8A, 8B, and 8C show specific examples of descriptions in the bean flow definition file 81. FIG. Specifically, FIG. 8A is an example of a description for one bean flow to execute one execution unit. FIG. 8B is an example of a description for one bean flow to execute two execution units and to acquire a value from a bean in one execution unit in the second execution unit. FIG. 8C is an example of a description in which one bean flow executes one execution unit, executes an input object method, and returns the execution result as an output object of the bean flow.

  The bean flow definition file 81 can be expressed in a structured tag language such as XML. The bean flow execution layer EJB 55 that interprets the bean flow definition file 81 determines a bean flow to be generated depending on what tag is present.

  Hereinafter, some tags will be described.

  The range set by the tag “flow” represents one bean flow definition. Here, “name” represents the name of the bean flow (flow name). The range set by the tag “flow” includes a plurality of resource elements, alias elements, and step elements (execution unit elements).

  Resource information is represented in the range set by the tag “resource”. Specifically, in order to perform flow control such as resource acquisition, resource commit or rollback (in other words, the bean itself excludes resource acquisition and flow control), Using this resource information, resource acquisition and flow control are performed by bean flow. “Name” in the range set by the tag here represents the name of the resource (resource name), and “key” represents the key for acquiring the resource. “Trancontrol” and “tranclose” are information for setting in the bean flow what to do with the resource. "Trancontrol" means that if the attribute value is "true", the bean flow performs flow control on the resource (that is, if all the execution units of the bean flow are completed normally, commit to the resource) This means that if an exception occurs during the execution of the bean flow, the resource is instructed to roll back). “Trancontrol” means that when the attribute value is “false”, the bean flow does not perform flow control on the resource. “Tranclose”, when the attribute value is “true”, means that when the bean flow ends, the bean flow executes close on the resource. When “tranclose” has an attribute value “false”, the bean flow does not perform closing on the resource. Note that at least one of "trancontrol" and "tranclose" can be omitted, and if omitted, one attribute value (for example, true) is treated as being set. .

  An alias name (alias name) is set in the range set by the tag “alias”.

  In the range set by the tag “step”, it is possible to define that any method of any bean is operated in association with one bean flow. Each execution unit (step) in the bean flow has a name, and other execution units (or beans therein) can be referred to by name. In this range, “name” represents the name of the execution unit, “class Name” represents the class name of the bean that is executed in the execution unit, and “method Name” is the name of the method of the bean that is executed in the execution unit. Represents. “Getter Name” represents the name of the getter that acquires the output object of the execution unit. Here, when “this” is specified, it means that the bean itself executed in the execution unit becomes the output object. “Type” represents an attribute related to the execution of a method in an execution unit. Specifically, for example, when the attribute value is “new”, it means that an instance of the bean specified by “className” is generated and the method specified by “methodName” is executed. Also, for example, in the case of the attribute value “input”, the input object to the bean flow is passed to the bean specified by “className”, and the method specified by “methodName” executes processing using the input object. means. Also, for example, in the case of the attribute value “step”, the output value of the previous execution unit is passed to the bean specified by “className”, and the method specified by “methodName” executes processing using the output value. Means that.

  Depending on how the tags and attribute values as described above are set in the bean flow definition file, for example, it is possible to create a bean flow that can execute the processes illustrated in FIGS. 11A to 11E described later.

  When a plurality of bean flows are defined in the bean flow definition file, for example, a tag <flows> is described before the plurality of bean flow definitions. From the tag, the bean flow execution layer EJB 55 generates a bean flow. The bean flow execution layer EJB 55 defines whether one bean flow is defined in the bean flow definition file 81 or a plurality of bean flows are defined. Can be determined.

  The bean flow execution layer EJB 55 interprets the above bean flow definition file and creates a bean flow 83 as defined in the bean flow definition file. If there are a plurality of bean flow definitions in one bean flow definition file, a plurality of bean flows corresponding to the plurality of bean flow definitions are created.

  FIG. 9A shows an example of a bean flow configuration.

  The bean flow 83 is an object for executing one or a plurality of beans. One bean flow 83 corresponds to one bean flow definition 90 in the bean flow definition file 81. In the bean flow 83, the bean flow name, the alias name, and the resource information represented by the corresponding bean flow definition 90 are set. In the bean flow 83, a plurality (for example, three) of execution unit settings 86A, 86B, and 86C respectively corresponding to the plurality of (for example, three) execution unit descriptions represented by the corresponding bean flow definition 90 are set. Is done. The plurality of execution unit settings 86A, 86B, and 86C are arranged according to the execution order of the execution units. In each execution unit setting 86A, 86B, 86C, various setting elements (for example, execution unit name, class name, method name, attribute information) represented by the execution unit description corresponding to the execution unit setting are set. The

  When receiving the command object processing request, the bean flow execution layer EJB 55 can identify which bean flow 83 corresponds to the command object and execute the specified bean flow 83.

  FIG. 9B shows the flow of processing performed by the bean flow execution layer EJB 55 when a processing request for a command object is received.

  When receiving the command object processing request, the bean flow execution layer EJB 55 refers to the bean flow key in the command object (S50). The bean flow key may be a key representing a bean flow name or a key representing an alias name. The bean flow execution layer EJB 55 can determine whether the referenced bean flow key represents a bean flow name or an alias name, for example, depending on whether a predetermined code is included in the bean flow key. it can. In this case, for example, when a command object is described on the caller side that creates a facade value, it is specified as a bean flow name or an alias name depending on whether or not a predetermined code is included in the bean flow key. Can be controlled.

  The bean flow execution layer EJB 55 searches for a bean flow and an interceptor corresponding to the referenced bean flow key (S51). Specifically, for example, the bean flow execution layer EJB 55 determines whether the referenced bean flow key represents a bean flow name or an alias name. If it is determined that it represents the bean flow name, the bean flow execution layer EJB 55 retrieves the bean flow 83 having the bean flow name that matches the bean flow key from the bean flow storage area 59, and A comparison with the interceptor definition file 80 is performed, and the interceptor 95 specified by the comparison is acquired from the program module storage area 61. On the other hand, when it is determined that the name represents an alias name, the bean flow execution layer EJB 55 searches the bean flow 83 having an alias name that matches the bean flow key from the bean flow storage area 59, and A comparison with the interceptor definition file 80 is performed, and the interceptor 95 specified by the comparison is acquired from the program module storage area 61.

  The bean flow execution layer EJB 55 executes the bean flow 83 and the interceptor 95 searched in S51 (S52). Here, for example, when a plurality of bean flows 83 are hit in S51 (specifically, when a plurality of bean flows 83 are acquired because there are a plurality of bean flow definitions 90 in the bean flow definition file 81). The bean flow execution layer EJB 55 can execute the plurality of bean flows 83 in the order defined in the bean flow definition file 81. The order of execution may be specified, for example, by referring to the bean flow definition file 81, or may be specified from the execution order if the execution order is written in the bean flow 83. In the execution of the bean flow 83, the bean 85 is retrieved from the program module 61 based on the information set in the bean flow 83, and instantiation of the bean 85, execution of the instantiated bean 85, and the like are performed. .

  The bean flow execution layer EJB 55 can provide a bean flow reference to the external AP 45 by, for example, the method illustrated in FIG. 10A.

  That is, the bean flow execution layer EJB 55 generates, for example, a name conversion map 201 that indicates an association between an alias name and a bean flow name for each bean flow by referring to each bean flow definition file 81.

  The bean flow execution layer EJB 55 receives a bean flow acquisition request including a bean flow key that is an alias name from the external AP 45, and in response to the request, references to the bean flow corresponding to the bean flow key (alias name) ( That is, the bean flow name) is acquired, and the acquired bean flow name is returned to the external AP 45.

  As a result, the external AP 45 can specify the bean flow not only by the alias name but also by the bean flow name (note that although not specifically illustrated, the exchange between the bean flow execution layer EJB 55 and the external AP 45 is as follows. Via the facade layer EJB 51).

  When a certain bean flow 83 is designated by an alias name or a bean flow name, the bean flow 83 performs the following processing.

  FIG. 10B shows an example of the flow of processing performed by the bean flow 83.

  (1) The bean flow 83 receives an execution instruction from the bean flow execution layer EJB 55. Specifically, for example, the method specified in the bean flow 83 is called from the bean flow execution layer EJB 55 that has received the command object processing request, using the input object in the command object as an argument.

  (2) The bean flow 83 acquires a resource 94 specified by a resource name from a resource group (for example, a memory area, a JMS (Java Messaging System) session, etc.) 92 using a resource key based on the resource information. And secure.

  (3) The bean flow 83 constructs an execution unit 88A based on the execution unit setting 86A (see FIG. 9A) of the bean flow 83. Specifically, the bean flow 83 selects a bean that matches the class name in the execution unit setting 86A from the program module storage area 61, and instantiates the selected bean (makes the bean loadable). . A bean stored in the program module storage area 61 is a POJO, not a bean created according to the EJB rules. The plurality of POJOs stored in the storage area 61 include POJOs for operating the database 38 such as POJOs for searching in the database 38 and POJOs for updating the database 38. include.

  (4) The bean flow 83 sets all or part of the attribute information in the execution unit setting 86A for the instantiated bean (POJO). The execution unit 88A is constructed by such processing. Specifically, for example, the bean (instanced bean) in the execution unit 88A becomes operable.

  (5) Thereafter, processing is performed in the processing order defined in the bean flow 83 (in other words, processing order defined in the bean flow definition file 81). Here, the specified method in the bean 85 </ b> A is executed by the bean flow 83.

  (6) When all execution units are performed, the processing result of the method (or the bean itself that executed the process itself) in a certain execution unit (for example, the last execution unit) is output as the bean flow execution layer. Returned to EJB55.

  (7) When the execution of the bean flow 83 ends normally, the bean flow 83 closes (that is, releases) the reserved resource 94 based on the resource information. Further, the bean flow 83 releases the resource 94 even if the bean flow is not normally terminated when, for example, an exception (for example, a failure) occurs.

  As described above, a plurality of execution units can be registered in the bean flow definition file 81. In this case, for example, the processes (3) to (5) are repeated for the number of execution units.

  Depending on the description of the bean flow definition file 81, the following is also possible. That is, for example, in each execution unit description in the bean flow definition file 81, “the first processing result by the first bean is passed to the second bean and the second bean that has received the first processing result is It is assumed that a definition such as “holding the first processing result and returning the second processing result based on the processing result of the second bean to the processing request source” is made. In this case, the bean flow 83 causes each bean to be executed according to the definition. Thereby, the first processing result by the first bean is passed to the second bean, and the second bean that has received the first processing result retains the first processing result, and the second bean. The second processing result based on the bean processing result is returned to the processing request source.

  In the series of processes described above, the bean flow 83 uses the reserved resource 94 when processing the bean 85A when executing the bean 85A, but does not cause the bean 85A to perform control until the resource 94 is controlled. For example, when an exception (for example, a failure) occurs during the processing of the bean 85A, the bean 85A may send the exception object in the command object to the processing request source (or the caller of the main book). .

  This completes the description of the execution of the bean flow 83 created in accordance with the bean flow definition file 81. An administrator (for example, the administrator of the EJB server 7 or the WEB server 5) causes the EJB server 7 to create various bean flows 83 depending on what information is set in the bean flow definition 90 of the bean flow definition file 81. In other words, the EJB server 7 can execute various processes with a single command object.

  For example, a plurality of execution units can be defined by one bean flow. Specifically, for example, as illustrated in FIG. 11A, information acquired by the bean getter (specified from the getter name) in the execution unit of the execution unit name “step1” and the execution unit name “step2” The information acquired by the bean getter in the execution unit can be set in the bean in the execution unit having the execution unit name “step3”.

  Also, for example, as illustrated in FIG. 11B, an input object 87A in the command object can be input to the execution unit 88D, and the instantiated bean 85D can execute processing using the input object 87A. .

  Further, for example, as illustrated in FIG. 11C, the execution method 88E can be caused to execute the specified method using the input object 87B in the command object as a bean.

  For example, as illustrated in FIG. 11D, the bean flow output object 89 can be acquired using the getter of the bean 85E that has executed the process.

  For example, as illustrated in FIG. 11E, the reference of the bean 85 </ b> F that has executed the process can be returned as the return value of the bean flow to the command object processing requester (or the caller of the main book). .

  The following can be said from the description of the embodiments described above.

  For example, conventionally, in order to operate a database by an EJB server, it is necessary to create an entity bean and deploy it to an EJB container.

  However, according to the above-described embodiment, since the transaction control can be performed by the three EJBs 51, 53, and 55, it is not necessary to create an entity bean. As described above, as long as a large number of program modules for executing a predetermined process are prepared, depending on the definition in the bean flow definition file 81, the bean flow execution layer EJB 55 may include a large number of program modules. One or a plurality of program modules are selected from the above, the execution order of the selected one or a plurality of program modules is determined, and the one or a plurality of program modules are executed in the determined order. Thus, for example, even when it is desired to perform various transaction controls on the EJB server, it is not necessary to create various entity beans to execute the various transaction controls.

  Further, according to the embodiment described above, depending on the definition of the bean flow definition file 81, for example, the information acquired by the getter of the first bean is set in the second bean, or the output of the first bean flow ( For example, the processing result) can be input to the second bean flow, and the output can be used to cause the second bean flow to execute the processing. In other words, if you say something different, you can say that you can represent stateful beans statelessly. That is, the EJBs 51, 53, and 55 are stateless beans, but depending on the attribute information input to the instantiated POJO (that is, depending on the definition of the bean flow definition file 81), the POJO is a stateful bean. It can be operated.

  As described above, one or more bean flows are specified from the bean flow key included in the command object. In addition, one or more interceptors are specified based on the bean flow key. The processing by the identified one or more interceptors is performed at least one of before and after execution of the identified one or more bean flows. Hereinafter, this will be described in detail.

  FIG. 12 shows an example of the interceptor definition file 91.

  The interceptor definition file 91 can be a file in a predetermined format, for example, an XML format file. In the interceptor definition file 91, definitions for all the interceptors (for example, Java (registered trademark) classes) existing in the program module storage area 61 may be described. Further, an interceptor definition file 91 may be prepared for each predetermined type, and an interceptor definition corresponding to the type may be described in each interceptor definition file 91.

  In the interceptor definition file 91, for example, for each of a plurality of interceptors 95 out of a large number of interceptors 95, an interceptor name and a condition for selecting an interceptor having the interceptor name (hereinafter, interceptor selection condition) are included. Is set. In FIG. 12, the interceptor name is a description existing between the tags <intercepter-name> and </ intercepter-name>, and the interceptor selection condition exists between the tags <pattern> and </ pattern>. It is a description to do.

  The interceptor selection condition can be expressed by various methods, but in this embodiment, it can be expressed by a combination of a keyword and a regular expression (wild card). That is, according to the interceptor definition file 91 illustrated in FIG. 12, the interceptor name “bank # Inter-cepter-A” (hereinafter referred to as “interceptor A” for convenience of explanation) is the bean flow key. Is selected as long as it contains the keyword "bank." An interceptor named “bank # Inter-cepter-B” (hereinafter referred to as “interceptor B” for convenience of explanation) may include the keyword “bank.service.” In the bean flow key. Selected. In addition, an interceptor named “bank # Inter-cepter-C” (hereinafter referred to as “interceptor C” for convenience of explanation) includes the keyword “bank.service.furikomi” in the bean flow key. If it exists, it is selected. An interceptor named “bank # Inter-cepter-D” (hereinafter referred to as “interceptor D” for convenience of explanation) is selected as long as the keyword “master.” Is included in the bean flow key. Is done.

  For example, even if the same bean flow is executed, the interceptor to be selected can be changed depending on whether the bean flow key indicates the bean flow name or the alias name. For example, if there is a bean flow with the bean flow name “bank.service.” And the alias name “master.”, Even if the bean flow key is “bank.service.” ”, The bean flow is executed, but the interceptor selected when the bean flow is executed is different. That is, when the bean flow key is “bank.service.”, Interceptors A and B are selected. When the bean flow key is “master.”, Interceptor D is Will be selected.

  In the interceptor definition file 91 as described above, the names of the four interceptors A to D and the interceptor selection conditions are defined. When a plurality of interceptors are selected according to the interceptor selection condition, for example, if the selected plurality of interceptors are executed before the execution of the bean flow, the selected plurality of interceptors are the interceptor definition file 91. It is executed in the order of description. Further, for example, if the selected plurality of interceptors are executed after the execution of the bean flow, the selected plurality of interceptors are executed in the reverse order of the description order in the interceptor definition file 91. The

  Hereinafter, the case where the interceptors selected based on the bean flow key in the command object are A and B will be described as an example, and the flow of processing performed in that case will be described.

  FIG. 13A is an explanatory diagram of processing executed when the interceptors selected based on the bean flow key in the command object are A and B. FIG. FIG. 13B shows the flow of the processing.

  The bean flow execution layer EJB 55 includes an interceptor management object 402 and a bean flow execution object 403. The bean flow execution layer EJB 55 selects one or more interceptors based on the bean flow key and the interceptor selection condition by the interceptor management object 402, or selects one or more selected based on the description in the interceptor definition file 91. The execution order of the interceptors can be specified. In addition, the bean flow execution layer EJB 55 can execute a bean flow suitable for the bean flow key by the bean flow object 403 for executing the bean flow.

  Specifically, when the interceptor management object 402 is specified to be executed in the order of interceptors A and B, first, the interceptor A is executed (S60). Thereby, the interceptor A executes predetermined preprocessing (predetermined processing to be executed before execution of the bean flow) (S61), and when the preprocessing is completed, the interceptor management object 402 is called. Next, the interceptor management object 402 executes the interceptor B (S62). Thereby, the interceptor B executes predetermined preprocessing (S63), and when the preprocessing is completed, the interceptor management object 402 is called. If called from the last interceptor B, the interceptor management object 402 calls the bean flow execution object 403 (S64). The called bean flow execution object 403 causes a bean flow matching the bean flow key to be executed.

  Thereafter, if the end of execution of the bean flow is detected (for example, if the bean flow execution object 403 receives a predetermined output from the bean flow), the bean flow execution object 403 calls the interceptor management object 402. The invoked interceptor management object 402 causes the interceptors to be executed in the reverse order to the specified execution order (preprocessing execution order). That is, the interceptor management object 402 executes the interceptor B (S66). After predetermined post-processing (predetermined processing to be executed after execution of the bean flow) is executed by the interceptor B (S67), if called from the interceptor B, the interceptor management object 402 causes the interceptor A to be executed ( S68). After a predetermined post-process is performed by the interceptor A (S69), if called from the interceptor A, the interceptor management object 402 outputs information (for example, the execution result of the selected one or more interceptors). (S70).

  According to the above description, one or more interceptors to be executed and their execution order are determined according to the bean flow key included in the command object by the combination of the keyword set in the interceptor definition file 91 and the regular expression. Can be different.

  The preferred embodiment of the present invention has been described above, but this is an example for explaining the present invention, and the scope of the present invention is not limited to this embodiment. The present invention can be implemented in various other forms. For example, in the above description, a name is used as a key for specifying a certain target. However, the present invention is not limited to this, and various IDs may be adopted. In addition, the method of defining transaction boundaries on the facade value is not limited to the method of including the command object that is the target of transaction separation in the unit of work. For example, a predetermined code is added to the command object that is the target of transaction separation. It is also possible to adopt a method such as.

FIG. 1 is a block diagram showing an outline of a hardware configuration of a system according to an embodiment of the present invention. FIG. 2 is a block diagram showing an outline of the software configuration of the system shown in FIG. FIG. 3 shows an outline of the flow of processing performed in the system shown in FIG. FIG. 4A shows an example of the configuration of the facade value. FIG. 4B shows a processing flow of the facade value 46 shown in FIG. 4A. FIG. 5A shows the flow of processing performed by the facade layer EJB51. FIG. 5B shows the flow of processing performed by the transaction separation layer EJB 53. FIG. 5C shows the flow of processing performed by the bean flow execution layer EJB55. FIG. 6A shows another example of the configuration of the facade value. FIG. 6B shows a process flow of the facade value shown in FIG. 6A. FIG. 7A shows the flow of one process that can be performed by the bean flow execution layer EJB55. FIG. 7B shows an outline of the configuration of the bean flow definition file 81. 8A, 8B, and 8C show specific examples of descriptions in the bean flow definition file 81. FIG. FIG. 9A shows an example of a bean flow configuration. FIG. 9B shows the flow of processing performed by the bean flow execution layer EJB 55 when a processing request for a command object is received. FIG. 10A is an illustration of a method for providing a bean flow reference to an external AP. FIG. 10B shows an example of the flow of processing performed by the bean flow 83. FIG. 11A shows a first process execution example of the bean flow. FIG. 11B shows a second execution example of the bean flow. FIG. 11C shows a third process execution example of the bean flow. FIG. 11D shows a fourth process execution example of the bean flow. FIG. 11E illustrates a fifth process execution example of the bean flow. FIG. 12 shows an example of the interceptor definition file 91. FIG. 13A is an explanatory diagram of processing executed when the interceptors selected based on the bean flow key in the command object are A and B. FIG. FIG. 13B shows the flow of the processing.

Explanation of symbols

  DESCRIPTION OF SYMBOLS 1 ... Information processing server 3 ... Client system 5 ... WEB server 7 ... EJB server 13, 23, 33 ... CPU 15, 25, 35 ... Memory 17, 27, 37 ... Hard disk 38 ... Database 43 ... WEB browser 45 ... External application 47 ... Facade value selection program 49 ... Facade value storage area 51 ... Facade layer EJB 53 ... Transaction separation layer EJB 55 ... Bean flow execution layer EJB 57 ... Bean flow definition file storage area 59 ... Bean flow storage area 61 ... Program module storage area 63 ... interceptor definition file storage

Claims (6)

Processing execution means for executing processing according to the request from the request source;
Sub-process selection means for selecting one or more sub-processes corresponding to the process from a plurality of sub-processes based on the request;
An information processing system comprising: a sub-process executing unit that executes the selected sub-process at least one of before and after the execution of the process. A storage unit that stores a plurality of sub-process IDs and a plurality of sub-process selection conditions respectively corresponding to a plurality of sub-processes,
The sub-process selection unit specifies one or more sub-process selection conditions that match the request from the plurality of sub-process selection conditions, and one or more sub-process selection conditions corresponding to the specified one or more sub-process selection conditions. Selecting one or more sub-processes identified from the process ID;
The information processing system according to claim 1. The sub-process selection condition includes a keyword,
The sub-process selection unit specifies one or more sub-process selection conditions that match the request, based on a specific character string included in the request and a keyword constituting the sub-process selection condition.
The information processing system according to claim 2. The sub-processing selection condition is composed of a combination of a keyword and a regular expression,
The sub-process selection unit specifies one or more sub-process selection conditions that match the request based on a specific character string included in the request and a keyword and a regular expression constituting the sub-process selection condition. To
The information processing system according to claim 3. The process has one real name and one or more aliases,
The request includes a specific character string, and the specific character string represents either a real name or an alias name of a process to be requested.
The information processing system according to claim 2. Executing a process according to the request from the requester;
Selecting one or more sub-processes corresponding to the process from a plurality of sub-processes based on the request;
An information processing method comprising: executing the selected sub-process at least one of before and after executing the process.

Images