JP2005085240A - Programming framework for executing commands - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To provide a programming framework which switches between local execution and remote execution of commands only by changing an external setting without absolutely changing command module. <P>SOLUTION: The programming framework reads in a setting file 140 of a client 100. In the case where a command is dummy-executed in the determination in S905, the dummyExecute method of a cmd object is executed. In the case where the command is not dummy-executed and local-executed in the determination in S907, the execute method of the cmd object is executed. In the case of remote execution, the transfer method is called out via a network N with respect to an object of a Sever class 122 of a command server 200. The cmd object is designated as an argument of the transfer method, and the transfer method returns an object of a Command derived class as a return value via the network. This object is defined as the cmd object, and the cmd object which finished its execution is returned as the return value. <P>COPYRIGHT: (C)2005,JPO&NCIPI

Description

  The present invention relates to a programming framework for executing a command that is an entity that abstracts a request on a program in a network environment in which at least a first information processing apparatus and a second information processing apparatus are connected.

  Conventionally, means for encapsulating “request” on a program as an object is well known as “Command” of a design pattern (see, for example, Non-Patent Document 1). The essential configuration and operation of the Command pattern can be expressed as shown in FIGS. 11 and 12 using a UML (Unified Modeling Language) class diagram and a sequence diagram, respectively.

  FIG. 11 is a UML class diagram showing the configuration of the Command pattern.

  An Application class 1101 is an arbitrary class that uses a command. An invoker class 1102 is a class responsible for starting a command. Use the storeCommand method of the Invoker class to start the command. The storeCommand method takes an object of the Command derived class as an argument, and also returns an object of the Command derived class as a return value.

  The Command class 1103 is an abstract base class for all commands. Only the abstract method execute is declared in the Command abstract base class. The execute method is declared as a placeholder for the actual operation executed by each Command derived class, and is called from the storeCommand method of the Invoker class 1102. This execute method has no arguments / return values.

  The ConcreteCommand class 1104 is described as an example of a Command derived class. In the ConcreteCommand class, the abstract method execute of the Command abstract base class 1103 is implemented. Here, setA and setB are setters that are methods for giving arguments to the execute method, and getC and getD are getters that are methods for acquiring an execution result (return value) after execution of the execute method.

  FIG. 12 is a UML sequence diagram for explaining the operation of the Command pattern.

  Reference numeral 1201 denotes an object obtained by instantiating the Application class 1101 in FIG. Reference numeral 1202 denotes an object obtained by instantiating the ConcreteCommand class 1104 in FIG. 11, and is given the name cmd. 1203 is an object that instantiates the Invoker class 1102 of FIG.

  First, in 1204, the Application object 1201 generates an instance of the ConcreteCommand class. Hereafter, this object is described with the name cmd.

  Next, a setter that is a setter of the cmd object 1202 is called in 1205, and a setB that is a similar setter is called in 1206, whereby an argument for calling the execute method is set in the cmd object 1202.

  Next, in 1207, the Application object 1201 calls the storeCommand method of the Invoker object 1203 with the cmd object 1202 as an argument.

  Next, in 1208, the storeCommand method of the Invoker object 1203 calls the execute method on the cmd object 1202 given by the argument. When the execute method call ends, the storeCommand method of the Invoker object 1203 returns the cmd object 1202 after the execute method ends as a return value (since the end of the method can be omitted in UML, the illustration is omitted in FIG. 12).

  Thereafter, the Application object 1201 can obtain the result of calling the execute method by calling getC that is the getter of the returned cmd object 1202 with 1209 and calling the similar getter getD with 1210.

  By applying such a Command pattern via a network, it becomes possible to execute a command remotely. Here, an example in which an EJB is used on the server side is known as an “EJB Command” pattern (see, for example, Non-Patent Document 2). The essential configuration and operation of the EJB Command pattern can be expressed as shown in FIGS. 13 and 14, respectively, using UML class diagrams and sequence diagrams. However, the “network boundary” in both figures is not a UML notation, but a notation used for convenience in describing “an original figure” as “one figure”.

  FIG. 13 is a UML class diagram showing the configuration of the EJB command pattern.

  Reference numeral 1305 denotes a network boundary. In the drawing, the configuration above the network boundary 1305 is the configuration on the client side, and the configuration below is the configuration on the server side. As shown in the figure, the configuration on the client side is the same as the configuration of the Command pattern in FIG.

  A server class 1306 is an EJB implementation class, and is a class for receiving a command execution request from a client via a network. The transfer method of the Server class 1306 receives a command execution request. The transfer method takes an object of the Command derived class as an argument, and returns an object of the Command derived class as a return value.

  The Command class 1307 and the ConcreteCommand class 1308 are exactly the same as the Command class 1303 and the ConcreteCommand class 1304, respectively. In other words, the exact same Command class and ConcreteCommand class exist on the client side and the server side.

  FIG. 14 is a UML sequence diagram for explaining the operation of the EJB command pattern.

  Reference numeral 1416 denotes a network boundary. In the drawing, the left side of the network boundary 1416 shows the operation on the client side, and the right side shows the operation on the server side.

  Reference numerals 1401, 1402, and 1403 denote client-side objects, and reference numeral 1401 denotes an object obtained by instantiating the Application class 1301 in FIG. Reference numeral 1402 denotes an object obtained by instantiating the ConcreteCommand 1304 in FIG. 13 and its name is cmd. Reference numeral 1403 denotes an object obtained by instantiating the Invoker class 1302 of FIG.

  Reference numerals 1404 and 1405 denote server-side objects, reference numeral 1404 denotes an object that instantiates the Server class 1306 in FIG. 13, and reference numeral 1405 denotes an object that instantiates the ConcreteCommand class 1308 in FIG.

  First, the application object 1401 generates a cmd object 1402 of the ConcreteCommand class in 1406, sets an argument in 1407 and 1408, and calls the storeCommand method of the invoker object 1403 in 1409, similar to 1204 to 1207 in FIG. is there.

  Next, the invoker object 1403 executes serialization (serialization) processing on the cmd object in 1410 in order to pass the object as an argument via the network.

  Next, the invoker object 1403 calls the transfer method of the server object 1404 via the network 1416 in 1411. The argument at this time is a cmd object serialized in 1410. Upon receiving the serialized cmd object, the Server object 1404 first executes deserialization (deserialization) processing in 1412 to restore the cmd object. The restored cmd object is 1405, which is an entity that is logically equivalent to the cmd object 1402.

  Finally, the Server object 1404 calls the execute method of the cmd object 1405 in 1413. This completes the transfer method call 1411 via the network, but the end of the method is not shown as in FIG.

Here, the transfer method serializes and returns the cmd object 1405 as a return value, and the invoker object 1403 deserializes the returned cmd object and replaces it with the cmd object 1402. As a result, the Application object 1401 can obtain the processing result by calling getC and getD with the getters 1414 and 1415.
"Design patterns for object-oriented reuse" by Erich Gamma, Richard Helm, Ralph Johnson, and John Vissides "EJB Design Pattern" by Floyd Marinescu

  As described above, the command can be executed locally or remotely. However, when a general-purpose library is created using a command, there is a problem in that it cannot be determined in advance whether the command is executed locally or remotely.

  In addition, when executing a command, it is often necessary to set an execution authority that associates the command executor with the command type, but when the number of executors and the types of commands increase, There was a problem that the setting of the execution authority was too complicated.

  Furthermore, especially in the early stages of development, there is a request to urgently prepare an environment in which commands can be executed even if they are not complete, but if remote execution is selected, at least the client, server, resource (database, etc.) There was a problem that it was difficult to meet this demand.

  The present invention has been made in view of the above circumstances, and an object of the present invention is to switch between local execution and remote execution of a command only by changing external settings without changing the command module at all. It is to provide a programming framework that can.

  It is another object of the present invention to provide a programming framework that can be executed not on the server side but on the client side regardless of whether the command execution authority is set for local execution or remote execution.

  Furthermore, the purpose of setting the command execution authority is to provide a programming framework in which a complicated combination can be set only by switching the policy representing the execution authority.

  It is another object of the present invention to provide a programming framework that can perform dummy processing (dummy execution) only by a client without accessing a server or a resource (such as a database).

  To achieve the above object, a programming framework according to claim 1 is an entity that abstracts a request on a program in a network environment in which at least a first information processing apparatus and a second information processing apparatus are connected. In a programming framework for executing a command, a command module stored in the first information processing apparatus that requests execution of the command, and the first module connected to the first information processing apparatus through the network A command module stored in the second information processing apparatus, the same command module as the command module, and a setting file provided in the first information processing apparatus for controlling the execution of the command. The first information processing apparatus executes the command set in the setting file. An execution authority determining step for determining authority setting contents, a dummy execution determining step for determining whether or not the setting of the setting file is a setting for executing a dummy command, and an execution destination of the command by the setting of the setting file is a local An execution destination determining step for determining whether the information processing apparatus is the first information processing apparatus that performs the execution or the second information processing apparatus that performs the remote execution, and the setting of the setting file is a dummy execution setting In this case, the first information processing apparatus executes the command locally regardless of the result of the execution destination determination step.

  According to a second aspect of the present invention, in the programming framework according to the first aspect, the execution authority determining step refers to the setting of the setting file, and in the setting, a command executor and a command type are determined. It is characterized by having a plurality of policies in which execution rights are matrix-defined for combinations.

  The programming frame according to claim 3 is the programming framework according to claim 1 or 2, wherein an execution environment of the first information processing apparatus and the second information processing apparatus is Java (registered trademark), The means for realizing the remote execution by the information processing apparatus 2 is EJB (Enterprise JavaBeans).

  To achieve the above object, the storage medium according to claim 4 stores the program according to any one of claims 1, 2, or 3 in a computer-readable storage medium. It is characterized by.

  According to the programming framework of claim 1 and the recording medium of claim 4, in the command execution process, the first information processing apparatus determines the setting contents of the command execution authority set in the setting file, It is determined whether or not the setting of the setting file is a setting for executing a dummy command, and second information for performing remote execution to determine whether the execution destination of the command based on the setting file setting is the first information processing apparatus performing local execution Since the first information processing apparatus executes the command locally regardless of the result of the execution destination determination when the setting file is determined to be a dummy execution setting, the command module is determined. It is possible to switch between local execution and remote execution of a command simply by changing the external setting without changing the That. Also, the command execution authority can be determined on the first information processing apparatus side, not on the second information processing apparatus side, in the case of local execution or remote execution. Furthermore, dummy execution can be performed only by the first information processing apparatus without accessing the second information processing apparatus or the database.

  According to the programming framework according to claim 2 and the recording medium according to claim 4, the execution authority is determined by referring to the setting file setting, and in the setting, a combination of a command executor and a command type is used. On the other hand, since there are a plurality of policies in which execution authority is defined in a matrix, execution authority settings can be set to complex combinations by simply switching the policies representing these execution authorities.

  Hereinafter, embodiments of the present invention will be described in detail with reference to the drawings.

  In the present embodiment, description will be made on the assumption that Java is used as a programming language and EJB is used for a remote call mechanism on the server side.

  FIG. 1 is an overall configuration diagram of a network in which a programming framework according to the present embodiment is implemented.

  Reference numeral 100 denotes a client (first information processing apparatus) that requests execution of a command, and reference numeral 200 denotes a command server (second information processing apparatus) for remotely executing a command. Reference numeral 300 denotes a DB server. The client 100, the command server 200, and the DB server 300 can communicate with each other through the network N, and the client 100 and the command server 200 can access the DB server 300 through the network N. These client 100, command server 200, and server 300 are information processing apparatuses.

  Although the DB server 300 is illustrated as a separate and independent information processing apparatus, the DB server function may be provided in the client 100 or the command server 200.

  FIG. 2 is a block diagram illustrating an example of a configuration of an information processing apparatus used as the client 100, the command server 200, and the DB server 300 in FIG.

  A CPU 10 controls the entire apparatus according to a control program. Reference numeral 20 denotes a RAM of an internal storage unit that stores a control program of the apparatus such as processing executed by the CPU 10 and a document image. Reference numeral 30 denotes a network interface (Net I / F) that transmits and receives data and the like by connecting to a network such as the Internet under the control of the CPU 10.

  Reference numeral 40 denotes an external storage device such as a magnetic disk for storing files. 50 is a display, 60 is a keyboard, and 70 is a pointing device such as a mouse.

  The program stored in the RAM 20 uses the function of an OS (Operating System) also stored in the RAM 20 as necessary, reads / writes the contents of data temporarily stored in the RAM 20, and stores data on the external storage device 40. To perform predetermined operations such as reading and writing the contents of the file, transmitting and receiving data through the network interface 30, receiving input from the keyboard 60 and pointing device 70, and displaying an image on the display 50. belongs to.

  Although the program is stored in the RAM 20, the present invention is not limited to this, and the program may be read from the external storage device 40 and executed. Further, the program may be received and executed via the network interface 30. Although not shown in FIG. 2, the program may be read from a read-only internal storage unit such as a ROM and executed.

  Further, instead of or in addition to the keyboard 60 and the pointing device 70, other input devices such as voice input may be provided. In addition, the command server 200 and the DB server 300 may omit the display 50 in many cases and share the keyboard 60 and the pointing device 70 with other information processing apparatuses. Or you may.

  Next, a block configuration in the information processing apparatus used in the present embodiment will be described with reference to FIGS.

  FIG. 3 is a block diagram illustrating an overall configuration of logical blocks (modules) mainly related to operations of the client, the command server, and the DB server in the present embodiment.

  Reference numeral 100A denotes a block boundary of the client 100, which indicates a Java execution environment. A setting file 140 exists on the external storage device 40. Reference numeral 120a denotes a program stored in the RAM 20, which is a client module that requests execution of a command.

  The client module 120a is further logically divided into two types of modules: an Admin authority module and a User authority module. Since the Admin authority module and the User authority module operate in different threads, it is possible to determine which module is operating by examining the thread.

  Reference numeral 120b denotes a program stored in the RAM 20, which is a command module including a module for executing a command and a command group to be executed.

  Reference numeral 200A denotes a block boundary of the command server 200, and here, a Java execution environment including an EJB container function is shown. A program 220 stored in the RAM 20 is a command module including a module for executing a command and a command group to be executed. The command module 220 is exactly the same as the command module 120b of the client 100, and differs only in whether it is stored in the RAM 20 of the client 100 or the RAM 20 of the command server 200.

  Reference numeral 300A denotes a block boundary of the DB server 300, which indicates a management range of a DB program (not shown) stored in the RAM 20. Reference numeral 340 denotes a database (DB) constructed on the external storage device 40 by the DB program. The programs of the client 100 and the command server 200 can read and write data in the DB 340 via the network N by accessing the DB server 300 by a method defined by the DB program.

  FIG. 4 is an active block diagram representing modules used when a command is operating in remote execution.

  In FIG. 4, the modules and communication paths used are indicated by bold lines. As illustrated, only the communication path between the client 100 and the DB server 300 is not used.

  FIG. 5 is an active block diagram representing modules used when a command is operating in local execution. As in FIG. 4, the modules and communication paths used are indicated by bold lines. As illustrated, the command module 220 of the command server 200 is not used as the module. Further, the communication path between the client 100 and the command server 200 and the communication path between the command server 200 and the DB server 300 are not used.

  FIG. 6 is a UML class diagram of classes included in the command module.

  As shown in the figure, it is roughly divided into modules 121 and 122 for executing commands and command groups 123 to 127.

  The Invoker class 121 plays the same role as the Invoker class 1102 of FIG. 11 and the Invoker class 1302 of FIG. As described above, the command module 120b of the client 100 and the command module 220 of the command server 200 are exactly the same, and the invoker class 121 is stored in both the client 100 and the command server 200. The Invoker class 121 is not used.

  The Server class 122 plays the same role as the Server class 1306 of FIG. The Server class 122 is stored in both the client 100 and the command server 200, but the Server class 121 is not used in the client 100.

  The Command class 123 is an abstract base class for all commands. Execute and dummyExecute are declared as abstract methods. Here, it is assumed that execute is defined in the derived class as a method for normal execution, and dummyExecute is a method for dummy execution.

  The UserCommand class 124 is an abstract base class representing a command executed with the User authority, and is declared inheriting from the Command class 123. Similarly, the AdminCommand class 125 is an abstract base class representing a command executed with the Admin authority, and is declared inheriting from the Command class 123.

  Reference numeral 126 denotes a RegistCommand which is an example of a User authority command. RegistCommand 126 is a command for registering a user name. User name is received by setName method as setter. After executing the command, the user ID is returned by the getId method of the getter. In the execute method, the user name received by the setter is registered in the DB 340, and a unique user ID is newly issued. The dummyExecute method does not actually register in the DB 340 but generates a user ID with a random number.

  Reference numeral 127 denotes a DeleteCommand which is an example of an Admin authority command. DeleteCommand 127 is a command for deleting the user name. User ID is received by setId method as setter. There is no getter. In the execute method, the user ID received by the setter is searched from the DB 340 and deleted if it exists. The dummyExecute method does not actually access the DB 340 and ends the process without doing anything.

  The command groups 123 to 127 are stored in both the client 100 and the command server 200, but are not used in the command server 200 in the case of local execution.

  Although only the minimum necessary methods are defined in the class diagram of FIG. 6, the present embodiment can be realized while freely defining and using other fields and methods in these classes.

  FIG. 7 shows the contents of the setting file.

  This configuration file is described as a Java property file. The Java property file is a text file and defines one item per line. Lines starting with # are simply ignored as comment lines. Here, three types of items 141 to 143 are defined.

  141 is the command execution destination setting as described in the comment, and either target = remote line or target = local line is set (other lines are commented out = comment line is invalidated) To use. In FIG. 7, the line of target = remote is set. If target = remote is set, remote execution is designated, so the command is executed by the command server 200. On the other hand, when target = local is set, the local execution is designated, and the command is executed by the client 100.

  142 is a command execution right setting as described in the comment, and any one of a policy = strict line, a policy = normal line, and a policy = tolerate line is set (others). Comment out the line and use it. In FIG. 7, a line of policy = strict is set. The difference in operation depending on the command execution authority setting will be described later with reference to FIG.

  Reference numeral 143 denotes a dummy execution setting as described in the comment. Either dummy = true or dummy = false is set (other lines are commented out). In FIG. 7, a line of dummy = true is set. If dummy = true is set, the command is in the dummy execution mode, and the dummyExecute method (see FIG. 6) of each command is executed. If dummy = false is set, the command is in the normal execution mode, and the execute method (see FIG. 6) of each command is executed.

  The configuration file has been described as a Java property file. However, the configuration file is not limited to this, and may be a text file or a binary file as long as it can be analyzed. Moreover, it is good also as a format which stores setting content in DB.

  FIG. 8 is a diagram showing whether or not a command can be executed according to the setting of the client module type, the command type, and the command execution authority. FIG. 8A shows a case where the command execution authority setting 142 is strict. (B) shows the case where the command execution authority setting 142 is normal, and (c) shows the case where the command execution authority setting 142 is tolerate.

  In the figure, ◯ represents that execution is possible, and x represents that execution is not possible. As indicated by 142 in FIG. 7, there are three types of setting of execution authority: strict, normal, and tolerate.

  In the case of (a), the command execution authority is checked strictly. As shown in the figure, the Admin authority command 125 can be executed only from a client module of the Admin authority in the client module 120a. The user authority command 124 can be executed only from the client module of the user module 120a.

  In the case of (b), the command execution authority is checked by a policy that is neither strict nor tolerate. As shown in the figure, the Admin authority command 125 can be executed only from the Admin authority client module of the client modules 120a. On the other hand, the command 124 with the User authority can be executed from both the client module with the User authority and the client module with the Admin authority in the client module 120a.

  In the case of (c), the command execution authority is checked for tolerance. As shown in the figure, both the Admin privilege command 125 and the User privilege command 124 can be executed from either the Admin privilege client module or the User privilege client module 703 of the client module 120a.

  Although three types of execution authority setting examples are shown, the present invention is not limited to this, and any number of necessary policies can be determined.

  The operation at the time of command execution will be described with reference to the flowcharts of FIGS.

  FIG. 9 is a flowchart showing command execution processing.

  Specifically, this is an operation when the storeCommand method is called from the client module 120a of the client 100 to an object that instantiates the invoker class 121 in the command module 120b. The argument at this time is an object obtained by instantiating an arbitrary derived class of Command 123 existing in the command module 120b.

  First, processing is started in step S901. Here, the command object passed as an argument is described with the name cmd.

  In step S902, the setting file 140 of the client 100 is read. Here, the contents of the command execution destination setting 141 are described with a variable name tgt. The contents of the dummy execution setting 143 are described with a variable name dmy. tgt takes a value of 'remote' or 'local' as shown in execution destination setting 141. dmy takes a value of ‘true’ or ‘false’ as shown in the dummy execution setting 143.

  In step S903, a command execution authority check process is performed. Details of this check processing will be described later with reference to the flowchart of FIG. This check process returns whether the check result is “success” or “failure”.

  In step S904, it is determined whether the check result is successful. If the check is not successful (failure), the execution of the command is terminated as failure (step S911).

  If the result of determination in step S904 is that the command execution authority check is successful, it is determined in step S905 whether or not the command is to be executed in dummy. This determination is made based on whether or not the value of the variable dmy is 'false'. When the value of dmy is not “false” (when the value of dmy is “true”), it is determined that dummy execution is designated, and the process proceeds to step S906, where the dummyExecute method of the cmd object (see FIG. 6). ) Is then executed, and the cmd object whose execution has been completed is returned as a return value in step S910, and this process ends.

  If the result of determination in step S905 is that dummy execution is not performed (dmy value is 'false'), the command execution destination is determined in step S907. This determination is made based on whether or not the value of the variable tgt is “remote”. When the value of tgt is not “remote” (when the value of tgt is “local”), it is determined that local execution is designated, and the process proceeds to step S908 to execute the execute method of the cmd object (see FIG. 6). Then, in step S910, the cmd object that has been executed is returned as a return value, and this process ends.

  If it is determined in step S907 that the value of tgt is “remote”, it is determined that remote execution is designated, and the process proceeds to step S909. In step S909, the transfer method is called via the network N for the object of the Server class 122 of the command module 220 stored in the command server 200. Here, a cmd object is specified as an argument to the transfer method. Since the transfer method returns an object of a class derived from Command 123 as a return value via the network, the returned object is newly set as a cmd object.

  In Java, when a remote call is made to an EJB server, serialization / deserialization processing of arguments and return value objects is not performed directly by the program but in the Java execution environment, so each processing is not shown in the flowchart. . Subsequently, in step S910, the cmd object that has been executed is returned as a return value, and the process is terminated.

  FIG. 10 is a flowchart showing the execution authority check process executed in step S902 of FIG. From step S902, a command object to be checked is passed as an argument.

  Processing starts in step S1001. Here, the command object passed as an argument is described with the name cmd.

  In step S1002, the setting file 140 is read. Here, the contents of the execution authority setting 142 are described with a variable name pcy. pcy takes a value of ‘strict’, ‘normal’ or ‘tolerate’ as shown in the execution authority setting 142.

  In step S1003, it is determined whether the calling module is a User authority module. That is, it is determined whether the user authority module or the Admin authority module. If it is not the User authority module, that is, if it is the Admin authority module, the process proceeds to step S1004. If it is a User authority module, the process advances to step S1006.

  Step S1004 is a process starting point when called from the Admin authority module, and determines whether the command is an Admin authority command, that is, whether it is a derived class of the Admin authority command 125 or not. In Java, this can be done by evaluating the expression cmd instanceof AdminCommand. If cmd is an Admin authority command, that is, a class derived from the Admin authority command 125, the execution is possible regardless of the execution authority setting content 142, and thus the process proceeds to step S1009 and the process ends as a successful check. .

  As a result of the determination in step S1004, if cmd is not the Admin authority command, that is, if it is not a derived class of the Admin authority command 125 (when cmd is a derived class of the User authority command 124), the process proceeds to step S1005. It is determined whether the setting is tolerate, that is, tolerate or other strict or normal. At this point, it is determined that the module is an Admin authority module and the command is a User authority command. Referring to FIG. 8, it can be seen that if the execution authority is set to strict or normal, execution is impossible, and if it is tolerate, execution is possible.

  Therefore, in step S1005, the value of pcy is compared with 'tolerate' to determine whether pcy = 'tolerate'. If pcy = 'tolerate', the process proceeds to step S1009 and the process is terminated as a successful check. To do. If pcy = “tolerate” is not satisfied (that is, if the value of pcy is “strict” or “normal”), the process proceeds to step S1008 and the process ends as a check failure.

  Steps S1006 to S1007 are also the same as steps S1204 to S1205, and a description thereof will be omitted.

  In the present embodiment, Java is used as a programming language, but the present invention is not limited to this, and any programming language can be used. Moreover, although EJB was used for the remote call mechanism, this is not limited to EJB, and any remote call mechanism can be used as long as it is available from the programming language.

  The program for executing this embodiment can be provided by being stored in a storage medium. Examples of the storage medium for supplying the program include a floppy (registered trademark) disk, hard disk, optical disk, magneto-optical disk, CD-ROM, CD-R, magnetic tape, and nonvolatile memory card.

It is the whole network block diagram with which the programming framework concerning this Embodiment is implemented. It is a block diagram which shows an example of a structure of the information processing apparatus used as a client in FIG. 1, a command server, and DB server. It is a block diagram which shows the whole structure of the logical block (module) mainly concerned with operation | movement of the client in this Embodiment, a command server, and DB server. It is an active block diagram showing a module used when a command is operating by remote execution. It is an active block diagram showing a module used when a command is operating in local execution. It is a UML class diagram of a class included in a command module. It is a figure which shows the content of the setting file. It is a figure which shows the propriety of the execution of the command according to the setting of the client module type, the command type, and the command execution authority, (a) shows the case where the setting of the command execution authority is strict, (b) Indicates a case where the command execution authority is set to normal, and (c) indicates a case where the command execution authority is set to tolerate. It is a flowchart which shows the execution process of a command. 10 is a flowchart showing execution authority check processing executed in step S902 of FIG. It is a UML class diagram which shows the structure of Command pattern. It is a UML sequence diagram explaining operation | movement of a Command pattern. It is a UML class diagram which shows the structure of an EJB command pattern. It is a UML sequence diagram explaining operation | movement of an EJB command pattern.

Explanation of symbols

100 Client 120a Client module 120b Command module 140 Setting file 141 Command execution destination setting 142 Command execution authority setting 143 Dummy execution setting 200 Command server 220 Command module 300 DB server N Network S903 Command execution authority check processing S905 Determination of whether to execute the command dummy S907 Determination of the execution destination of the command

Claims (4)

In a programming framework for executing a command that is an entity that abstracts a request on a program in a network environment in which at least a first information processing apparatus and a second information processing apparatus are connected,
A command module stored in the first information processing apparatus that requests execution of the command;
A command module identical to the command module stored in the second information processing apparatus connected to the first information processing apparatus via the network;
A setting file provided in the first information processing apparatus for controlling execution of the command;
The execution process of the command is as follows:
An execution authority determining step in which the first information processing apparatus determines a setting content of an execution authority of a command set in the setting file;
A dummy execution determination step of determining whether or not the setting of the setting file is a setting for dummy execution of a command;
An execution destination determining step of determining whether the execution destination of the command based on the setting file setting is the first information processing apparatus performing local execution or the second information processing apparatus performing remote execution;
When the setting of the setting file is a setting for dummy execution, the first information processing apparatus executes the command locally regardless of the result of the execution destination determination step.   The execution authority determining step refers to the setting of the setting file, and the setting includes a plurality of policies in which execution authority is matrix-defined for combinations of a command executor and a command type. Item 1. A programming framework according to item 1.   The execution environment of the first information processing apparatus and the second information processing apparatus is Java, and the means for realizing the remote execution by the second information processing apparatus is EJB (Enterprise JavaBeans) The programming framework according to claim 1 or 2.   A computer-readable storage medium storing the program according to any one of claims 1, 2, and 3.

Images