JP5927930B2 - Information processing apparatus and program - Google Patents

Description

  The present invention relates to an information processing apparatus and a program.

  Conventionally, simple applications called widgets, desktop widgets, gadgets, and the like are provided via the Internet or the like. Hereinafter, such application names will be unified as “widgets”.

  Similar to Web pages, general widgets use HTML (HyperText Markup Language) or XML (eXtensible Markup Language), JavaScript (registered trademark), VBSscript, and the like (hereinafter, simply referred to as “script”). And is executed on a web browser-based platform. Therefore, the functions provided only by the widget are limited to acquisition of information through HTTP communication, provision of GUI (Graphical User Interface), and the like. The web browser-based platform refers to a platform having a web browser basic function (hereinafter referred to as “widget runtime”). The basic function of the Web browser refers to a function for executing HTTP communication as a client, a function for drawing a screen by interpreting HTML or XML, a function for interpreting and executing a script, and the like.

  In the widget runtime, in order to be able to implement a widget that can provide more advanced functions, the functions of the agent can be used for the widget.

  As used herein, an agent refers to a program that provides a function via a Web API. Specifically, the agent refers to a program that provides a function corresponding to a URL (Uniform Resource Locator) specified in the HTTP request in response to the HTTP request. That is, the Web API is an API (Application Program Interface) that accepts a function execution request by specifying a URL.

  FIG. 1 is a diagram for explaining the relationship between a widget, a widget runtime, and an agent.

  In FIG. 1, the widget 501 a requests execution of the function A by specifying the URL (A) to the widget runtime 502. The widget 501b makes a request to execute the function B by designating the URL (B) to the widget runtime 502. The widget runtime 502 transmits an HTTP request in which the URL (A) is specified to the agent 503 in response to the specification of the URL (A). The widget runtime 502 also transmits an HTTP request in which the URL (B) is specified to the agent 503 in response to the specification of the URL (B).

  When the agent 503 receives the HTTP request in which the URL (A) is specified, the agent 503 executes the function A. When the agent 503 receives an HTTP request in which the URL (B) is specified, the agent 503 executes the function B.

  The agent 503 is installed on the same PC (Personal Computer) as the widget and the widget runtime. The agent 503 is implemented by a programming language capable of advanced processing such as Java (registered trademark). Therefore, according to the configuration shown in FIG. 1, the widget 501a or 502a can provide the user with a high-level function A or function B that cannot be implemented by HTML or XML, script, or the like.

  However, conventionally, the agent function has been fixedly installed inside the agent. Therefore, in order to provide a new function unique to the widget, it has been necessary to enhance the function of the agent and to reinstall the agent. In addition, when distributing a widget that provides a new function, it is also necessary to distribute an agent whose function has been enhanced, which makes it difficult for users to introduce the widget. As a result, the introduction of the widget is avoided, and there is a possibility that the developer may not use the developed widget very much.

  In addition, there is a possibility that the operation of an agent that has been operating stably until now will become unstable due to a bug accompanying the enhancement of functions. As a result, even widgets that are unrelated to the function enhancement may be affected by the bug and become unstable.

  The present invention has been made in view of the above points, and it is an object of the present invention to improve the convenience and safety of function expansion with respect to programs that provide functions to other programs.

  Accordingly, in order to solve the above-described problem, the information processing apparatus includes: a first function execution unit that executes a function related to the identification information in response to reception of a function execution request for which the function identification information is specified; A second function execution that functions in a process different from the function execution means of the first and executes the function related to the identification information specified in the execution request transferred from the first function execution means based on the identification information And when the identification information specified in the received function execution request indicates an additional function of the program module, the first function executing means is specified in the execution request. A program module is added to the second function execution means, and the second function execution means relates to the identification information specified in the execution request transferred from the first function execution means. The ability to execute the program module that is added to the second function executing unit.

  The convenience and safety of function expansion can be improved with respect to programs that provide functions to other programs.

It is a figure for demonstrating the relationship between a widget, widget runtime, and an agent. It is a figure which shows the hardware structural example of the information processing apparatus in embodiment of this invention. FIG. 3 is a diagram illustrating a software configuration example regarding a basic function of the information processing apparatus. It is a sequence diagram for demonstrating the 1st example of the process sequence for publishing the interface with respect to the function of a program module as WebAPI. It is a sequence diagram for demonstrating the 2nd example of the process sequence for publishing the interface with respect to the function of a program module as WebAPI. It is a figure which shows an example of the utilization form of the additional function of the program module which an extension module has. It is a sequence diagram for demonstrating the process outline | summary performed according to the addition request | requirement of the program module from a widget. It is a sequence diagram for demonstrating the 1st example of the process sequence performed according to the addition request | requirement of the program module from a widget. It is a sequence diagram for demonstrating the 2nd example of the process sequence performed according to the addition request | requirement of the program module from a widget. It is a sequence diagram for demonstrating an example of the process sequence performed according to the execution request of the program module in an extended agent.

  Hereinafter, embodiments of the present invention will be described with reference to the drawings. FIG. 2 is a diagram illustrating a hardware configuration example of the information processing apparatus according to the embodiment of the present invention. The information processing apparatus 10 in FIG. 2 includes a drive device 100, an auxiliary storage device 102, a memory device 103, a CPU 104, an interface device 105, a display device 106, an input device 107, and the like that are mutually connected by a bus B.

  A program for realizing processing in the information processing apparatus 10 is provided by a recording medium 101 such as a CD-ROM. When the recording medium 101 storing the program is set in the drive device 100, the program is installed from the recording medium 101 to the auxiliary storage device 102 via the drive device 100. However, the program need not be installed from the recording medium 101 and may be downloaded from another computer via a network. The auxiliary storage device 102 stores the installed program and also stores necessary files and data.

  The memory device 103 reads the program from the auxiliary storage device 102 and stores it when there is an instruction to start the program. The CPU 104 realizes functions related to the information processing apparatus 10 according to a program stored in the memory device 103. The interface device 105 is used as an interface for connecting to a network. The display device 106 displays a GUI (Graphical User Interface) or the like by a program. The input device 107 includes a keyboard and a mouse, and is used for inputting various operation instructions.

  FIG. 3 is a diagram illustrating a software configuration example related to the basic functions of the information processing apparatus. In FIG. 3, the information processing apparatus 10 includes a widget 11, a widget runtime 12, an agent 13, and the like.

  The widget 11 is a simple application program generally called a widget, a desktop widget, or a gadget. The widget 11 is implemented using, for example, HTML (HyperText Markup Language) or XML (eXtensible Markup Language), JavaScript (registered trademark) or VBSscript (hereinafter simply referred to as “script”) and the like.

  The widget runtime 12 is a software program that implements the execution environment of the widget 11. The widget runtime 12 has functions of a general Web browser such as a function of executing HTTP communication as a client, a function of interpreting HTML or XML and drawing a screen, and a function of interpreting and executing a script. Is provided. The widget runtime 12 displays the screen of the widget 11, executes a script defined in the widget 11, and the like by such functions.

  The agent 13 is a group of programs that provide functions via WebAPI. Specifically, the agent 13 provides a function corresponding to a URL (Uniform Resource Locator) specified in the HTTP request in response to the HTTP request from the client. That is, the Web API is an API (Application Program Interface) that accepts a function execution request using a URL as function identification information.

  In the present embodiment, the widget runtime 12 that receives the URL designation from the widget 11 corresponds to a client for the agent 13.

  In FIG. 3, the agent 13 includes one or more program modules 131, a module platform 132, a module runtime 133, and the like.

  Each program module 131 is a program module that executes a unique function. In the figure, as an example of the program module 131, an A module 131a, a B module 131b, a Web API module 131w, an extension module 131e, and the like are illustrated. Among these, the Web API module 131w and the extension module 131e are program modules 131 having special functions and roles.

  The WebAPI module 131w plays a role of publishing an interface for functions of other program modules 131 as a WebAPI. Specifically, the Web API module 131w opens a port having a predetermined port number and calls the program module 131 corresponding to the URL specified in the HTTP request addressed to the port. That is, a URL is assigned to each program module 131, and the WebAPI module 131w manages the URL of each program module 131 in association with each program module 131.

  The extension module 131e is a program module 131 that realizes an additional function of the program module 131 that realizes a function that is not implemented in the agent 13. The additional meaning of the program module 131 will be described later. The expansion of the function of the agent 13 is performed simply and safely by the expansion module 131e.

  The module runtime 133 provides a module execution environment. An example of the module runtime 133 is Java (registered trademark) VM (Virtual Machine).

  The module platform 132 is a platform for facilitating modularization or componentization of programs in the execution environment provided by the module runtime 133. An example of the module platform 132 is an OSGi (Open Services Gateway Initiative) platform. The OSGi platform is a standardized technology by the OSGi alliance, and is a software platform that provides an execution environment for the program module 131 created based on an open software componentization technology based on the Java (registered trademark) language. On the OSGi platform, program modules in the Java (registered trademark) language are implemented in the form of software components called “bundles”. One bundle can be installed dynamically independently (without requiring the information processing apparatus 10 to be restarted). Therefore, when the OSGi platform is adopted as the module platform 132, each program module 131 in the present embodiment is mounted as a bundle.

  In FIG. 3, the widget runtime 12 and the agent 13 operate as different processes. The widget 11 is activated on the widget runtime 12 process. Each program module 131 is activated as a thread on the process on the agent 13.

  Hereinafter, a processing procedure executed in the information processing apparatus 10 will be described. FIG. 4 is a sequence diagram for explaining a first example of a processing procedure for publishing an interface for a function of a program module as a Web API. For example, the process of FIG. 4 is executed when the process of the agent 13 is started.

  In step S <b> 101, the module platform 132 issues a start instruction to each program module 131 registered in the module platform 132. Activation means, for example, that each program module 131 is activated as a thread.

  Each program module 131 notifies the WebAPI module 131w of a URL for identifying the function of the program module 131 and address information (for example, a pointer) related to the function in response to the activation instruction (S102). The notification is performed, for example, by calling a predetermined method of the Web API module 131w. Note that the URL is identification information used to publish an interface for the function of the program module 131 to the outside of the agent 13.

  The address information (pointer or the like) is identification information that is necessary inside the agent 13 due to the implementation of the calling mechanism of the program module 131. The URL is static information, and the address information can be said to be dynamic identification information. This is because the address information may change every time the program module 131 is activated.

  For example, the extension module 131e notifies a URL such as “/ exmodule”. That is, the URL notified here is a relative path to the URL of the route defined by the WebAPI module 131w. In the present embodiment, it is assumed that the URL of the route defined by the Web API module 131w is “<host>: <port> / platform”. <Host> is actually replaced by a specific host name or IP address. <Port> is actually replaced by a specific port number.

  Subsequently, the Web API module 131w associates the notified URL with the address information and stores them in the memory device 103 (S103). As a result, the interface of the program module 131 related to the URL is published as a Web API. This is because the WebAPI module 131w can call the program module 131 corresponding to the URL based on the address information corresponding to the URL in response to the reception of the HTTP request in which the URL is specified.

  For example, the URL for the Web API of the extension module 131e is disclosed to the outside of the agent 13 as “<host>: <port> / platform / ex module”. In other words, if the widget 11 wishes to use the function of the extension module 131e, it sends an HTTP request in which “<host>: <port> / platform / ex module” is specified as the URL to the Web API module 131w. Good.

  Subsequently, the WebAPI module 131w returns a response to each program module 131 (S104). Each program module 131 returns a response to the module platform 132 (S105).

  Subsequently, a modified example with respect to FIG. 4 will be described. FIG. 5 is a sequence diagram for explaining a second example of a processing procedure for publishing an interface for a function of a program module as a Web API. In FIG. 5, steps that are the same as or correspond to those in FIG. 4 are given the same step numbers as those in FIG. 4 or step numbers given branch numbers with respect to the step numbers in FIG.

  FIG. 5 shows an example in which the exchange between the Web API module 131w and each program module 131 in steps S102 and S104 is mediated by the module platform 132.

  That is, the URL for the function of each program module 131 and the address information related to the function are notified from each program module 131 to the Web API module 131w via the module platform 132 (S102-1 and S102-2).

  Also, the response from the WebAPI module 131w is returned to each program module 131 via the module platform 132 (S104-1, S104-2).

  According to the processing procedure shown in FIG. 5, the dependency of each program module 131 on the Web API module 131 w can be reduced. That is, each program module 131 can publish an interface for its function as a Web API without being aware of the existence of the Web API module 131w.

  When a new program module 131 is added on the module platform 132, the processing described in FIG. 4 or FIG. 5 is executed for the program module 131 at the added timing. As a result, the interface of the program module 131 is automatically disclosed as a Web API.

  Next, functions of the extension module 131e will be described. As described above, the extension module 131e has an additional function of the program module 131. The additional function is used as follows, for example.

  FIG. 6 is a diagram illustrating an example of a usage form of the additional function of the program module included in the extension module.

  In FIG. 6, the widget 11a is a widget 11 that requires the function of the C module 131c, which is a program module 131 that realizes a function that the agent 13 does not have. In this case, for example, when the widget 11a is distributed, the C module 131c may be distributed together with the widget 11a. As an example of the distribution form of the widget 11, for example, downloading the widget 11 from a predetermined site can be cited.

  When the widget 11a is activated, it designates the URL corresponding to the additional function of the program module 131 (that is, the URL for the extension module 131e) and the file path name of the storage location of the C module 131c, and sends it to the widget runtime 12 A call to WebAPI is requested (S201). Instead of the file path name of the storage destination of the C module 131c, a URL that can specify the C module 131c may be specified.

  The widget runtime 12 transmits an HTTP request in which the URL corresponding to the additional function of the program module 131 and the file path name are designated to the Web API module 131w (S202). The WebAPI module 131w calls the program module 131 corresponding to the URL. As described above, the program module 131 corresponding to the URL indicating the additional function of the program module 131 is the extension module 131e. Therefore, here, the extension module 131e is called (S203).

  In response to the call, the extension module 131e activates the extension agent 13a (S204). The extended agent 13a is activated as a process different from the agent 13 by using the same program as the agent 13 with respect to the module platform 132 and the module runtime 133. Therefore, the extended agent 13a includes the module platform 132a and the module runtime 133a in the same manner as the agent 13.

  However, as illustrated in FIG. 6, the program module 131 included in the extension module 131e as a basic configuration is a proxy module 131p. The proxy module 131p cooperates with the extension module 131e (S205), and registers the C module 131c in the module platform 132a of the extension agent 13a (S206). The proxy module 131p also performs processing for publishing an interface for the function of the C module 131c as a Web API in cooperation with the extension module 131e.

  Thus, the C module 131c is registered not in the agent 13 but in the extended agent 13a. Since the program module 131 can be added to the extended agent 13a due to the convenience of the widget 11, it is possible to realize functions exceeding the restrictions on the implementation of the widget 11. Here, the reason why the C module 131c is registered not in the agent 13 but in the extended agent 13a is as follows.

  That is, if free addition of the program module 131 is permitted, there is a possibility that the program module 131 whose operation stability is not guaranteed, such as the program module 131 whose test is insufficient, may be registered in the agent 13. When such a program module 131 is registered in the agent 13, the operation of other program modules 131 in the agent 13 may be adversely affected due to a malfunction of the program module 131, memory consumption, or the like. Since each program module 131 included in the agent 13 operates on the same process, when the process ends due to an illegal operation by any one of the program modules 131, the other program modules 131 become inoperable. Because it ends up.

  Therefore, in the present embodiment, the program module 131 requested to be added by the widget 11 is registered in the extended agent 13a that is a different process from the agent 13. By doing so, the stability or safety of the process of the agent 13 can be ensured.

  The process executed in response to the request for adding the program module 131 by the widget 11 described with reference to FIG. 6 will be described using a sequence diagram.

  FIG. 7 is a sequence diagram for explaining an outline of processing executed in response to a program module addition request from a widget. The step number in parentheses indicates the step number of the corresponding step in FIG. Also in FIG. 7, it is assumed that the widget 11 that requests addition of a new program module 131 is a widget 11a. The new program module 131 is assumed to be a C module 131c. In FIG. 7, the Web API module 131w, the extension module 131e, and the proxy module 131p are shown as abstracted as the agent 13 or the extension agent 13a.

  When the widget 11a is activated, it designates the URL corresponding to the additional function of the program module 131 and the file path name of the storage destination of the C module 131c, and requests the widget runtime 12 to call the Web API (S301). . Here, “<host>: <port> / platform / ex module” is designated as the URL. Note that the C module 131c is not necessarily distributed with the widget 11a. FIG. 6 shows only an example of the distribution form of the C module 131c.

  Subsequently, the widget runtime 12 transmits an HTTP request in which the URL and the file path name are specified to the agent 13 (S302). In response to the HTTP request, the agent 13 activates the extended agent 13a as a process (S303).

  Subsequently, the agent 13 designates the file path name of the C module 131c and transmits a request for adding the C module 131c to the extended agent 13a (S304). In response to the addition request, the extended agent 13a registers the C module 131c as the program module 131 on the extended agent 13a. Subsequently, the extended agent 13a returns a response indicating completion of addition of the C module 131c (S305).

  Subsequently, the agent 13 transmits an activation request for the C module 131c to the extended agent 13a (S306). In response to the activation request, the extended agent 13a activates the C module 131c as a thread. In response to the activation of the C module 131c, the processing as described in FIG. 4 or 5 is executed on the extended agent 13a with respect to the C module 131c. That is, the URL for the function of the C module 131c and the address information related to the function are notified from the C module 131c to the extended agent 13a. The correspondence between the URL and the address information is managed by the extended agent 13a.

  Subsequently, the extended agent 13a designates the URL and transmits a WebAPI registration request to the agent 13 regarding the function of the C module 131c (S307). The agent 13 stores the URL and the identification information related to the extended agent 13a in association with each other in the memory device 103 (S308). As a result, the interface of the C module 131c is published as a Web API. That is, the agent 13 can call the extended agent 13a related to the identification information corresponding to the URL in response to receiving an HTTP request in which the URL is specified. At this time, the URL is notified to the extended agent 13a. The extended agent 13a manages the URL and address information in association with each other. Therefore, the extended agent 13a can call the C module 131c based on the address information corresponding to the URL.

  Subsequently, the agent 13 returns a response indicating that the interface of the C module 131c is registered as a Web API to the extended agent 13a (S308). In response to the response, the extended agent 13a returns a response indicating that the activation of the C module 131c is completed to the agent 13 (S309).

  Subsequently, the agent 13 returns an HTTP response indicating completion of addition of the C module 131c to the widget runtime 12 (S310). The widget runtime 12 returns a response indicating completion of addition of the C module 131c to the widget 11a (S311).

  Next, the processing content of FIG. 7 will be described by subdividing it into the level of the program module 131 in the agent 13 or the extended agent 13a.

  FIG. 8 is a sequence diagram for explaining a first example of a processing procedure executed in response to a program module addition request from a widget. The step number in parentheses indicates the step number of the corresponding step in FIG. In FIG. 8, the widget runtime 12 is omitted for convenience. That is, in FIG. 8, the communication between the widget 11a and the WebAPI module 131w is strictly performed via the widget runtime 12.

  In step S401, the Web API module 131w specifies the URL corresponding to the additional function of the program module 131 and the file path name of the storage destination of the C module 131c, which are transmitted based on the request from the activated widget 11a. The HTTP request is received (S401). The WebAPI module 131w calls the extension module 131e based on the address information associated with the URL corresponding to the additional function of the program module 131 (S402). At this time, the extension module 131e is notified of the file path name of the C module 131c.

  Subsequently, the extension module 131e activates the extension agent 13a including the module platform 132a as a process (S403). Subsequently, the extension module 131e designates the file path name of the C module 131c and transmits an addition request for the C module 131c to the module platform 132a (S404). In response to the addition request, the module platform 132a registers the C module 131c as the program module 131 on the module platform 132a. In response to the registration, an ID is assigned to the C module 131c. The ID is hereinafter referred to as “registration ID”. Here, it is assumed that “001” is assigned as the registration ID. The module platform 132a returns a response including the registration ID (“001”) to the extension module 131e (S405).

  The extension module 131e generates a root URL of the C module 131c based on the registration ID. For example, “/ exmodule / 001” is generated as the root URL. That is, a character string in which the registration ID of the C module 131c is added to the relative path (“/ ex module”) of the URL of the extension module 131e is used as the root URL of the C module 131c. Note that the root URL of the C module 131c is not a function of the C module 131c but a URL indicating the C module 131c itself. For example, when the C module 131c is deleted, the root URL is used to specify the deletion target C module 131c.

  The extension module 131e registers the root URL as a Web API, specifies the root URL and address information (for example, a pointer or the like) regarding the additional function of the program module 131 included in the extension module 131e, and the Web API module 131a. (S406).

  Subsequently, the Web API module 131w associates the root URL of the C module 131c with the address information related to the additional function of the program module 131 included in the extension module 131e, and stores it in the memory device 103, for example (S407). As a result, the root URL is published as a Web API. For the outside of the agent 13, the absolute path of the root URL of the C module 131 c is “<host>: <port> / platform / exclude / 001”.

  Subsequently, the Web API module 131w returns a response indicating that the root URL is registered as the Web API to the extension module 131e (S408).

  Note that what has been registered or published as a Web API so far is the root URL of the C module 131c, not the URL for the function of the C module 131c. Therefore, for example, the widget 11a cannot call the function of the C module 131c at this stage.

  Subsequently, the extension module 131e designates the registration ID (“001”) of the C module 131c, and transmits an activation request for the C module 131c to the module platform 132a (S409). In response to the activation request, the module platform 132a activates the C module 131c specified based on the registration ID as a thread (S410).

  When activated, the C module 131c notifies the proxy module 131p of the URL for the function of the C module 131c and address information (for example, a pointer) regarding the function, as in step S102 of FIG. 4 (S411). ). The proxy module 131p stores the URL and the address information in association with each other, for example, in the memory device 103. Here, it is assumed that the relative path of the URL for the function of the C module 131 c is “/ 001 / functionC”. The URL is obtained by adding “functionC” to the registration ID of the C module 131c. The original identifier for the function of the C module 131c is “functionC”. By adding the registration ID, it is possible to increase the possibility that URL duplication between the C module 131c and other modules is avoided. This is because the registration ID basically does not overlap.

  However, the registration ID may not be added to the URL. In this case, the proxy module 131p may check for URL duplication. When duplicate URLs are detected, the proxy module 131p may request the C module 131c to specify another URL, or the proxy module 131p may automatically generate another URL. .

  Note that the proxy module 131p appears to the program module 131 in the extended agent 13a in the same manner as the Web API module 131w. That is, the proxy module 131p exposes the same interface (method) as the WebAPI module 131w to the program module 131 in the extended agent 13a. Therefore, each program module 131 including the C module 131c may call a predetermined method without being aware of whether the environment in which the program module 131 is started is the module platform 132 or the module platform 131a. By doing so, each program module 131 can notify the Web API module 131w or the proxy module 131p of the URL for the function of the program module 131 and the address information related to the function.

  Subsequently, the proxy module 131p designates the URL (“/ 001 / functionC”) for the function of the C module 131c, and transmits a registration request as a Web API for the function of the C module 131c to the extension module 131e (S412). . At this time, a communication identifier for the proxy module 131p may be notified to the proxy module 131p together with the URL. The identifier for communication with the proxy module 131p is an identifier for the extension module 131e to identify the proxy module 131p in communication between the proxy module 131p and the extension module 131e. The entity of the identifier depends on the communication protocol. However, if the identifier is known to the extension module 131e, the identifier may not be notified. Note that the communication between the proxy module 131p and the extension module 131e may be performed based on, for example, RMI (Remote Method Invocation). Alternatively, it may be performed based on a communication protocol independent of a program language such as HTTP or SOAP (Simple Object Access Protocol).

  In step S412, the address information of the C module 131c is not notified because the address information is a valid value in the process of the extended agent 13a and an invalid value in the agent 13. .

  Subsequently, the extension module 131e requests the Web API module 131w to register as a Web API regarding the function of the C module 131c (S413). In the request, the URL in which the URL of the extension module 131e is added to the URL for the function of the C module 131c notified in step S412 and the address information related to the mediation function of the extension module 131e are specified. In the present embodiment, the URL obtained by adding the URL of the extension module 131e to the URL for the function of the C module 131c is “exmodule / 001 / functionC”. Hereinafter, the URL is referred to as a URL for the function of the C module 131c.

  The WebAPI module 131w associates the URL for the function of the C module 131c with the address information related to the mediation function of the extension module 131e, and stores them in the memory device 103, for example. The mediation function of the extension module 131e refers to a function of mediating or transferring an HTTP request received by the WebAPI module 131w to the program module 131 in the extension agent 13a. As described above, the extension module 131e has an additional function of the program module 131 in addition to the mediation function. The address information of the additional function is stored in association with the URL for the additional function by the WebAPI module 131w. In step S413, in order to be able to distinguish between the additional function and the mediation function, address information different from the additional function is notified to the Web API module 131w as the address information of the mediation function.

  For example, the URL for the Web API of the C module 131c is disclosed to the outside of the agent 13 as “<host>: <port> / platform / exclude / 001 / functionC”. The URL is obtained by adding “/ functionC” to the root URL of the C module 131c.

  Subsequently, the Web API module 131w returns a response indicating that the interface for the function related to the notified URL is registered as the Web API to the extension module 131e (S415).

  The extension module 131e returns a response indicating that the interface for the function of the C module 131c is registered as a Web API to the proxy module 131p (S416). Subsequently, the proxy module 131p returns a response indicating that the interface for the function of the C module 131c is registered as a Web API to the C module 131c (S417). The C module 131c makes a response to the activation instruction in step S410 to the module platform 132a (S418). The module platform 132a returns a response to the activation request for the C module 131c in step S409 to the extension module 131e (S419).

  The extension module 131e returns a response to the request for adding the C module 131c in step S402 to the Web API module 131w (S420). The WebAPI module 131w returns a response including the root URL of the C module 131c to the widget 11a via the widget runtime 12 (S421). Thereafter, the widget 11a can delete the C module 131c or call a function of the C module 131c based on the route URL.

  Next, a modified example with respect to FIG. 8 will be described. FIG. 9 is a sequence diagram for explaining a second example of a processing procedure executed in response to a program module addition request from a widget. 9, steps that are the same as or correspond to those in FIG. 8 are denoted by the same step numbers as those in FIG. 8 or step numbers given branch numbers with respect to the step numbers in FIG.

  The relationship between FIG. 8 and FIG. 9 is the same as the relationship between FIG. 4 and FIG. That is, in FIG. 9, the exchange between the program modules 131 is mediated by the module platform 132 or the module platform 132a.

  Specifically, regarding the steps S406, S408, S413, and S415, the exchange between the Web API module 131w and the extension module 131e is mediated by the module platform 132.

  Regarding steps S411 and S417, the exchange between the C module 131c and the proxy module 131p is mediated by the module platform 132a.

  The other points are the same as in FIG.

  Next, processing executed when the widget 11a calls the function of the C module 131c will be described.

  FIG. 10 is a sequence diagram for explaining an example of a processing procedure executed in response to a program module execution request in the extended agent.

  In step S501, the widget 11a inputs an execution request for the C module 131c to the widget runtime 12. In the execution request, the URL (“<host>: <port> / platform / exclusive / 001 / functionC”) for the function of the C module 131c is specified.

  In step S421 of FIG. 8 or FIG. 9, only the root URL of the C module 131c is returned to the widget 11a. That is, the URL for the function of the C module 131c is not returned. Nevertheless, the widget 11a can specify the URL for the function of the C module 131c because the widget 11a is implemented from the beginning with the C module 131c planned to be used. That is, the widget 11a knows that the identifier of the function of the C module 131c is “functionC”, and the identifier added to the root URL of the C module 131c is the URL for the function of the C module 131c. Because they know the rules or promises to be. In step S421, a URL for the function of the C module 131c may be returned.

  Subsequently, the widget runtime 12 transmits an HTTP request addressed to the URL (S502). The HTTP request is received by the WebAPI module 131w.

  The WebAPI module 131w requests the extension module 131e related to the address information stored in the memory device 103 in association with the URL to execute the C module 131c (S503). The URL is specified in the execution request. However, not all the URLs need be specified. For example, only “/ 001 / functionC” may be specified.

  Subsequently, the extension module 131e transmits (transfers) an execution request for the C module 131c including the designated URL to the proxy module 131p (S504). Subsequently, the proxy module 131p calls the C module 131c based on the address information associated with the URL and stored in the memory device 103 (S505). In response to the call, the C module 131c executes a process for realizing a function implemented in the C module 131c (S506). Subsequently, the C module 131c returns the function execution result (product) to the proxy module 131p (S507).

  The proxy module 131p returns a response including the execution result to the functional module (S508). The functional module returns a response including the execution result to the WebAPI module 131w (S509). The WebAPI module 131w returns an HTTP response including the execution result to the widget runtime 12 (S510). The widget runtime 12 returns a response including the execution result to the widget 11a (S511).

  Next, deletion of the C module 131c will be described. The deletion command for the C module 131c is expressed, for example, by designating a predetermined character string (for example, “DELETE” or the like) indicating the deletion command for the root URL of the C module 131c. In the present embodiment, the deletion instruction of the C module 131c is expressed by “<host>: <port> / platform / exclude / 001 / DELETE”.

  When the widget 11a desires to delete the C module 131c, the widget 11a transmits an HTTP request with “<host>: <port> / platform / exclusive / 001 / DELETE” specified as the URL via the widget runtime 12. .

  When the Web API module 131w receives the HTTP request, the Web API module 131w is an instruction to delete the program module 131 that is identified by “/ exmodule / 001” based on “DELETE” included in the URL. Is interpreted. Therefore, the WebAPI module 131w deletes the program module 131 whose registration ID is “001” with respect to the extension module 131e related to the address information stored in the memory device 103 in association with “/ exmodule / 001”. Request. The extension module 131e requests the module platform 132a to delete the program module 131 whose registration ID is “001”. The module platform 132a deletes the C module 131c whose registration ID is “001”. That is, the registration with respect to the module platform 132a is canceled for the C module 131c.

  Other program modules 131 other than the C module 131c and added to the extended agent 13a can be deleted by the same procedure.

  As described above, according to the present embodiment, the agent 13 includes a function expansion interface (an interface to an additional function of the program module 131), and can expand the function in response to the interface call. . Therefore, with regard to the agent 13 that provides a function to the widget 11, the convenience of function expansion can be improved.

  Further, the program module 131 related to function expansion is added to the extended agent 13 a that functions in a process different from that of the agent 13. Therefore, it is unlikely that the agent 13 that is likely to be used simultaneously from the plurality of widgets 11 is affected by the operation improper operation of the program module 131 or the memory consumption. Therefore, regarding the agent 13 that provides the function to the widget 11, the safety of function expansion can be improved.

  The URL for the function of the program module 131 is notified (obtained) from the program module 131. In other words, the URL for the function of the program module 131 is not randomly assigned, but is generated according to a predetermined rule based on the identifier acquired from the program module 131. Therefore, for the widget 11 that uses the program module 131, it is possible to improve the predictability of the URL for the function of the program module 131.

  The WebAPI module 131w may have an interface that provides the widget 11 with a list of URLs stored in the memory device 103. Specifically, a URL for the list providing function may be assigned to the WebAPI module 131w. The Web API module 131w returns a list of URLs stored in the memory device 103 when an HTTP request in which the URL is specified is received. The widget 11 can specify a URL for a desired function from the list by, for example, keyword search. As a result, the relationship between the widget 11 and the function (program module 131) can be sparse or dynamic.

  In the present embodiment, the agent 13 is an example of a first function execution unit. The extended agent 13a is an example of a second function execution unit. The URL for the function of the program module 131 is an example of identification information assigned to each function.

  As mentioned above, although the Example of this invention was explained in full detail, this invention is not limited to such specific embodiment, In the range of the summary of this invention described in the claim, various deformation | transformation・ Change is possible.

DESCRIPTION OF SYMBOLS 10 Information processing apparatus 11 Widget 12 Widget runtime 13 Agent 13a Extended agent 100 Drive apparatus 101 Recording medium 102 Auxiliary storage apparatus 103 Memory apparatus 104 CPU
105 interface device 106 display device 107 input device 131 program module 132 module platform 133 module runtime 131a A module 131b B module 131c C module 131e extension module 131p proxy module 131w WebAPI module B bus

JP 2010-092376 A

Claims (5)

First function execution means for executing a function related to the first identification information in response to reception of a function execution request in which the first identification information that is the function identification information is designated;
It functions in a process different from the first function execution means, and relates to the first identification information specified in the execution request transferred from the first function execution means based on the first identification information. Second function executing means for executing the function,
When the first identification information specified in the received execution request for the function indicates an additional function of the program module, the first function execution means determines the program module specified in the execution request. In addition to the second function execution means, the second identification information related to the second function execution means is held in association with the first identification information related to the program module, and the received function is executed. When the second identification information related to the second function execution means is associated with the first identification information specified in the request, the first identification information specified in the execution request The execution request is transferred to the second function execution means without executing the function according to
The second function execution unit is configured to add the function related to the first identification information specified in the execution request transferred from the first function execution unit to the second function execution unit. An information processing apparatus to be executed by a program module. The second function execution means acquires the first identification information for the function of the program module according to the addition of the program module, and associates the first identification information with the program module and stores the first identification information. The information processing apparatus according to claim 1, wherein the function is executed by the program module associated with the first identification information specified in the execution request transferred from the first function execution unit. . The second function executing unit notifies the first identification information acquired from the program module in accordance with the additional of the program module to the first function executing means,
The first function execution unit stores the first identification information notified from the second function execution unit in a storage unit in association with the second function execution unit, and receives the received function. The information according to claim 2, wherein when the first identification information specified in the execution request is associated with the second function execution unit, the execution request is transferred to the second function execution unit. Processing equipment.   The first function execution means is a case where the first identification information specified in the received function execution request indicates a deletion function of the program module, and the first identification information is the first function information. When the second identification information related to the second function execution unit is associated, the program module deletion request related to the first identification information is transferred to the second function execution unit,
  The second function execution unit registers the program module according to the third identification information included in the first identification information specified in the deletion request transferred from the first function execution unit. And
  The information processing apparatus according to claim 1, wherein the third identification information is included in the first identification information. Computer
First function execution means for executing a function related to the first identification information in response to reception of a function execution request in which the first identification information that is the function identification information is designated;
It functions in a process different from the first function execution means, and relates to the first identification information specified in the execution request transferred from the first function execution means based on the first identification information. Function as a second function execution means for executing functions,
When the first identification information specified in the received execution request for the function indicates an additional function of the program module, the first function execution means determines the program module specified in the execution request. In addition to the second function execution means, the second identification information related to the second function execution means is held in association with the first identification information related to the program module, and the received function is executed. When the second identification information related to the second function execution means is associated with the first identification information specified in the request, the first identification information specified in the execution request The execution request is transferred to the second function execution means without executing the function according to
The second function execution unit is configured to add the function related to the first identification information specified in the execution request transferred from the first function execution unit to the second function execution unit. A program to be executed by a program module.

Images