JP2010262453A - Method, device and program for relaying of inter-software communication - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To achieve inter-software communication to be executed in a Web browser while securing security. <P>SOLUTION: Into a Web document to be relayed by a relay server, a code for communicating with the other Web document through the relay server is poured. On the basis of cooperative definition, the mutual Web documents communicate through the relay server with the poured codes. <P>COPYRIGHT: (C)2011,JPO&INPIT

Description

  The disclosed technology relates to a relay technology for communication between a plurality of software executed in a Web browser.

  Recent web browsers have a security mechanism called same origin policy, which ensures that security is controlled by preventing web applications (software) read from different origins (senders) from communicating freely. Is done.

  On the other hand, recently, a technique called mashup has been used, in which a plurality of documents are displayed in the same browser, and Web applications read from different origins communicate with each other.

  However, in order to realize this mashup, the above-described same origin policy mechanism hinders cooperation between applications. Therefore, a technique for avoiding the security mechanism based on the same origin policy is required.

  As a first conventional technique for realizing cooperation between Web applications, a technique called “domain crossing by a relay server” is known. Further, as this technique, a “relay by parameter” technique and a “relay by domain encoding” technique are known.

  First, in the “relay by parameter” technique, when the URI to be read is “http://www.exapmle.net/dir/”, for example, “http://proxy.example.org/?uri=http: The above URI is embedded as a query parameter of a request for the relay domain “proxy.example.org”, such as “//www.exapmle.net/dir/”. This technique is often used in CGI proxies. The origin when the relay server is routed by this method is the origin of the relay server. For this reason, the origins of documents read from different origins via the relay server are equal to each other. FIG. 15 is a diagram illustrating an example of the “relay by parameter” technique. Each document read from different servers A and B via the proxy of domain P is displayed in each frame included in the same browser of the client computer. In this case, the domain of each document is the same domain P. Therefore, the documents can communicate with each other on the browser without being blocked by the same origin policy.

Next, the “relay by domain encoding” technique in the first prior art will be described.
In this technology, when the URI to be read is “http://www.example.net/dir/”, “http://http-www-example-net.proxy.example.org/dir/” etc. In this method, the original URI schema host port is encoded as part of the domain, and the path and query are added. FIG. 16 is a diagram illustrating an example of a “relay by domain encoding” technique. Each document read from different servers A and B via the proxy of this method is displayed on each frame included in the same browser of the client computer. In this case, the domain of each document is a part of the domain P, for example, A.D. P or B. Encoded as P. In this case, the domain of each document is a different domain. This method maintains security according to the same origin policy, is compatible with SSL certificates, has high conversion / inversion processing efficiency, and can be easily deciphered when viewing its URI (human readable) Encoding method.

  As a second conventional technique for realizing cooperation between Web applications, a “inter-document communication in a browser” technique is known. Furthermore, as this technique, an “iframe proxy communication” technique and a “window.postMessage” technique are known.

  The “iframe proxy communication” technique is a method of performing communication between documents using a fragment ID of a src attribute of an iframe element in HTML (HyperText Markup Language).

  On the other hand, the “window.postMessage” technology is a new application programming interface (API) adopted in HTML5. HTML5 is the next HTML specification that is being developed by the World Wide Web Consortium (W3C) and the Web Hypertext Application Technology Working Group (WHATWG). In HTML5, an API “window.postMessage” is defined. By using this API, communication between documents of different origins can be performed.

  The following prior art documents are disclosed as conventional techniques related to the technique disclosed in the present application.

JP 2000-076074 A JP 2005-267605 A

However, each of the above-described conventional techniques has the following problems.
First, with the “relay by parameter” technology in the first prior art described above, documents that originally had different origins become the same origin by passing through the relay server, so the security mechanism based on the same origin policy operates. do not do. For this reason, although free communication can be performed between documents, any communication is allowed, and thus there is a problem that information leakage or falsification may occur.

  In the “relay by domain encoding” technique in the first prior art described above, if the origin of the original URI is different, the origin is also different in the URI after encoding. Work. As a result, although communication is not possible between documents, it is safe, but the application cannot be linked, and it is difficult to achieve mashup or the like.

  In the “iframe proxy communication” technique in the second prior art described above, communication is based on a character string having a severe length restriction, which is a URI fragment ID. In addition, the “iframe proxy communication” technology has a problem in that secure communication cannot be realized unless communicating documents are mutually recognized as communication partners.

  Regarding the “window.postMessage” technology in the second prior art described above, the HTML5 specification is in the process of being formulated, and the widespread use of Web browsers according to this specification is still unfinished. . Also, with the “window.postMessage” technology, it is necessary for documents to recognize each other as communication partners in order to communicate securely between documents.

  A problem to be solved by the disclosed technology is to enable communication between a plurality of software programs executed in a Web browser while ensuring security.

  In order to solve the above-described problem, an example of an aspect is as follows: cooperation source software executed in a client browser based on a first Web document acquired from a first target server via a relay server; Based on the second Web document acquired from the two target servers via the relay server, it is realized as a relay method for relaying the communication with the cooperation destination software executed in the browser at the relay server. The relay server executes the following steps.

  In the first injection step, a first Web document includes an identifier of a cooperation source software, an identifier of a first function executed in the cooperation source software, and an argument given to the first function. A first command for sending the event notification to the relay server by the cooperation source software is injected.

  In the second injection step, based on the second event notification from the relay server including the identifier and argument of the second function in the second Web document, the cooperation destination software sends the second function to the argument by the argument. Inject a second instruction to execute.

In the first transmission step, the first Web document in which the first instruction is injected and the second Web document in which the second instruction is injected are transmitted to the client.
When the determination step receives the first event notification from the cooperation source software, the determination step is associated with the combination of the identifier of the cooperation source software and the identifier of the first function executed by the cooperation source software. The linkage included in the first event notification is referred to by referring to the linkage definition table that holds the combination of the identifier of the linkage destination software that communicates with the software and the identifier of the second function executed by the linkage destination software. The combination of the identifier of the link destination software and the identifier of the second function executed by the link destination software corresponding to the combination of the identifier of the source software and the identifier of the first function executed by the link source software is determined. .

  In the second transmission step, the second event included in the determined combination is notified to the cooperation destination software specified based on the identifier of the cooperation destination software included in the determined combination as a second event notification. Send function identifier and arguments.

  According to the disclosed technology, it is possible to perform secure communication between software by performing communication based on the permission of the user or the system via the relay server.

  According to the disclosed technology, since the user and the system define whether or not communication between software is possible, it is possible to eliminate the necessity of making each software aware of the software of the communication partner.

  According to the disclosed technology, the client side does not require a plug-in or the like and can be operated only by a normal browser.

It is a basic lineblock diagram of a 1st embodiment of a communication system between Web documents. It is an operation | movement flowchart of 1st Embodiment. It is a data block diagram of the metadata of a widget. It is explanatory drawing of the script injection | pouring with respect to an issue function. It is explanatory drawing of HTML code injection | pouring with respect to a reception function. It is operation | movement explanatory drawing of a cooperation definition. It is a basic lineblock diagram of a 2nd embodiment of a communication system between Web documents. It is an operation | movement sequence diagram which shows the reading sequence in 2nd Embodiment. It is an operation | movement sequence diagram which shows the cooperation definition sequence in 2nd Embodiment. It is an operation | movement sequence diagram which shows the cooperation sequence in 2nd Embodiment. It is a figure which shows the database schema of the cooperation definition table in 2nd Embodiment. It is an operation | movement flowchart which shows the request reception process in 2nd Embodiment. It is a figure which shows the example of mashup. It is a figure which shows an example of the hardware constitutions of the computer which can implement | achieve the relay server 101. It is explanatory drawing of a 1st prior art. It is explanatory drawing of a 2nd prior art.

Hereinafter, embodiments will be described in detail.
FIG. 1 is a basic configuration diagram of a first embodiment of a communication system between Web documents.
As described above, due to the existence of a security mechanism based on the same origin policy, communication between Web applications (software) can be performed, but it is not safe because it permits all communication, or communication cannot be performed in the first place. It was.

  On the other hand, in the present embodiment, each document from different servers 102 (#m) and 102 (#n) is read into each frame in the browser 103 via the relay server 101 with different origins. At that time, the relay server 101 injects a code into each document so that each document and the relay server 101 can communicate with each other. When a request for inter-document communication is received from the document to the relay server 101, the relay server 101 determines whether or not to permit the communication. To distribute communication contents.

  Since each document has a different origin by way of the relay server 101, it is not possible to communicate with each other within the browser 103 according to the same origin policy. In this embodiment, when it is desired to perform communication between documents in the browser 103, communication is executed via the relay server 101 by a code injected into each document by the relay server 101. At this time, since the relay server 101 can determine whether or not to allow communication between documents, secure cooperation between Web applications becomes possible.

FIG. 2 is an operation flowchart showing the operation of the first embodiment. Hereinafter, the operation of each step of this operation flowchart will be described.

Step S201 :
First, a user who uses the browser 103 passes a URI (Uniform Resource Identifier) of metadata to the relay server 101, and the relay server 101 determines a widget (in the browser, independent of the browser) based on the metadata. Is displayed on the browser 103. In this example, the browser 103 reads an address book and a map widget.

Step S202 :
When each widget is read from the server 102 via the relay server 101, the relay server 101 performs URI replacement, code (script) injection to the issuance function, and code injection to the reception function for each widget.

Step S203 :
The user designates the linkage definition for the relay server 101 by designating a combination of the issue widget, issue function, reception widget, and reception function. In this example, the following relationship is defined as “a search is executed in the map widget when an address is selected in the address book widget”. This description represents a cooperative relationship in which when the function “AddressSelected” for selecting an address is executed in the widget w1, the function “SearchMapA” for searching a map is executed in the widget w2.

w1: AddressSelected-> w2: SearchMapA

  The above-described cooperation definition is executed by a user who uses the browser 103, for example, by calling a homepage for cooperation definition provided from the relay server 101. For example, when the user specifies the issue widget name and the receive widget name, the relay server 101 accesses the server 102 and refers to the metadata (FIG. 3) corresponding to these widgets, and lists the issue function and the receive function. To the user. The user designates a desired combination of issue function and reception function from the presented functions.

Step S204 :
The relay server 101 registers the cooperation definition designated by the user in step S203 in the internal cooperation definition table. Alternatively, this linkage definition may be preset in the relay server 101, for example.

Step S205 :
When an address is selected in the address book widget, an event is issued to the relay server 101 by the script injected into the issue function in step S202.

Step S206 :
The relay server 101 determines a delivery destination with reference to the cooperation definition table defined in step S204. In this example, the map widget map search is the distribution destination.

Step S207 :
The relay server 101 transmits an event to the client using the iframe injected into the reception function in step S202. As a result, a map search is executed in the map widget.

  Through the series of operations from step S201 to step S207, cooperation between the widgets displayed on the browser 103 via the relay server 101 is realized.

  The widget issued from the server 102 in FIG. 1 based on the above-described step S201 is generally attached with metadata as exemplified by 301 or 302 in FIG. In the metadata 301 or 302, the URI of the Web application is written as the src attribute of the content element shown as 303 or 304. In addition, in the publisher element shown as 305 and the subscriber element shown as 306, the function names of the issuing function and the receiving function are written. Based on this metadata, a widget reading process described later is executed.

  In the execution of step S202 described above, when the resource is read via the relay server 101 (FIG. 1), if the resource is a text format resource such as HTML or JavaScript, URI replacement is performed. By this replacement process, the original URI is replaced with the URI via the relay server 101.

  In URI replacement, a unique instance ID is embedded in the domain name for each widget. For example, if the original URI is “http://address.example.net/Address.html” and the widget instance ID is “cn0306”, the replaced URI is “http: // cn0306-http-address-exapmle-net”. .hub.example.org / Address.html ".

  There are two main reasons for embedding a unique widget instance ID in a domain name. One is to enable the relay server 101 to specify a widget based on the widget instance ID. The other is that even if the origin of the original Web application is the same, it becomes a different origin via the relay server 101, and the direct communication between widgets is made impossible and security is improved. is there.

  When it is described that there is an issue function in the metadata (for example, 301 in FIG. 3), the relay server 101 issues the issue function in the widget read from the server 102 in the execution of step S202 described above. Inject script (code) into For example, assume that the original HTML document is as shown in 401 of FIG. 4 and the issue function is defined as a global function as indicated by 403. A script exemplified as 402 is injected at the end of the body element of such an HTML document.

  In this script, the original issued function is stored in a local variable, as indicated by 404, and the new function is assigned to a global variable, as indicated by 405. In the new function, the original issue function is called, as shown as 406. Also, as indicated by 407, a code for notifying the relay server that an event has occurred using XMLHttpRequest is described. Further, as indicated by 408, a code for designating the cooperation path of the relay server 101 at the time of notification is described. Further, as indicated by 409, a code for transmitting an event name and an argument as a request body of a POST request at the time of notification is described. Note that the cooperation path indicated as 408 is a special path predetermined by the relay server 101.

  By injecting the script in this way in the relay server 101 and transmitting it to the browser, a function for notifying the relay server 101 of an event can be added without destroying the logic of the original application.

  If the metadata describes that there is a reception function (for example, 302 in FIG. 3), the relay server 101 moves to the reception function in the widget read from the server 102 in the execution of step S202 described above. Inject HTML code and send to browser. Assume that the original HTML document is, for example, 501 in FIG. 5 and the reception function is defined as a global function as indicated by 504. An iframe exemplified as 502 is injected at the end of the body element of such an HTML document. The script element which is the content of HTML read by the iframe is a code such as 503, for example.

  Based on the event notification from the script injected into the issuing function in the address book widget, the relay server 101 converts the script element 503 into an iframe in the map widget displayed on the browser 103 in step S207 described above. Notify as. At the time of distribution of this event, the script element 503 is written using iframe streaming which is a kind of server push type communication method Comet, and the written script element is immediately executed on the browser side by flushing the network stream. . In the script element 503 executed by the browser 103, a global function defined as 504 in the original document 501 is called by the description of the window.parent reference indicated by 505. As a result, in response to the address selection in the address book widget, a map search is executed for the server 102 (FIG. 1) of the issuer in the map widget, and the search result is displayed in the map widget.

  In the above example, the event notification from the relay server 101 to the receiving widget based on the event notification from the issuing widget is realized by injection of iframe code and iframe streaming. In addition, it is possible to employ a method of performing polling using XHR (XMLHttpRequest) or general Comet, or JSONP (JSON with Padding) based on addition of a script element by a timer or the like.

  When the linkage definition is designated by the user or the system preset in step S203 described above, the relay server 101 registers the linkage definition in the linkage definition table in step S204. When an event is notified from the issuing widget to the relay server 101 in step S205, the relay server 101 refers to the linkage definition table in step S206 to determine which reception function of which reception widget to notify the event. Determine and execute the event notification determined as a result. That is, the relay server 101 performs event notification to the reception widget only when the cooperation definition is registered in the cooperation definition table. By using the linkage definition in this way, safe linkage between widgets can be realized.

  FIG. 6 is a diagram illustrating an example of a cooperation definition table. In the entry on the first line in this example, w1 corresponding to the address book widget is specified as the issue widget name, and the function AddressSelected issued when the address item is selected (clicked or pointed) is specified as the issue function name. Yes. Correspondingly, w2 corresponding to the map widget is specified as the reception widget name, and the function SearchMapA for searching the map A is specified as the reception function name. In the entry on the second line, w1 corresponding to the address book widget is designated as the issue widget name, and the function MailSelected issued when the mail address item is selected as the issue function name. Correspondingly, w3 corresponding to the mailer widget is specified as the reception widget name, and the function SetTo for setting the address to the To address is specified as the reception function name.

  Since the relay server 101 does not execute inter-widget cooperation other than the above-described cooperation definition, it prevents unpredictable cooperation such as an e-mail address in the address book leaking to the map widget or the contents of the address book being rewritten by another widget be able to.

  FIG. 7 is a basic configuration diagram of the second embodiment of the communication system between Web documents. The second embodiment embodies the configuration of the relay server 101 in the inter-Web document communication system including the relay server 101, the server (target server) 102, and the browser 103 in the first embodiment of FIG. is there.

The operation centering on the relay server 101 having the configuration of FIG. 7 will be described below.
FIG. 8 is an operation flowchart showing a reading sequence in the second embodiment. This operation flowchart details the processes of steps S201 and S202 of the operation flowchart of the first embodiment shown in FIG.

The user passes the URI of the metadata of the widget to be added from the parent frame of the browser 103 to the addition / deletion unit 701 in the relay server 101 (step S801 in FIG. 8).
The addition / deletion unit 701 refers to the user table 702 and checks whether or not the requesting user is a regular user (step S802 in FIG. 8).

When the user confirmation is completed, the addition / deletion unit 701 acquires metadata requested by the user from the target server 102 (step S803 in FIG. 8).
Then, the addition / deletion unit 701 analyzes the metadata (step S804 in FIG. 8), assigns a unique widget instance ID to the metadata, and registers the registration information of the metadata in the instance database 703 (FIG. 8). 8 step S805).

  The addition / deletion unit 701 returns the widget instance ID (instance ID in the figure) and the replaced URI for reading content via the relay server 101 to the parent frame of the browser 103 (step S806 in FIG. 8). When the parent frame of the browser 103 receives this information from the relay server 101, it creates a child frame and sets its address to the replaced URI.

The child frame created by the parent frame of the browser 103 sends a request to the proxy unit 704 of the relay server 101 using the replaced URI (step S807 in FIG. 8).
The URI replacement unit 705 in the proxy unit 704 extracts the widget instance ID and the original URI from the replaced URI by reverse conversion (step S808 in FIG. 8).

The proxy unit 704 sends a request to the content of the target server 102 pointed to by the original URI, and acquires the content (step S809 in FIG. 8).
If the content is text-based content, the URI replacement unit 705 in the proxy unit 704 replaces the URI part of the content passed from the target server 102 (step S810 in FIG. 8). ).

  Further, the code injection unit 706 in the proxy unit 704 injects a script (code) for the issue function and the reception function based on the metadata registered in the instance database 703 (step S811 in FIG. 8). This operation is the same as the operation described above in the first embodiment.

  The proxy unit 704 returns the replaced text content or binary content as a response to the child frame of the browser 103 (step S812 in FIG. 8), and the browser 103 displays the content as a widget (FIG. 8). 8 step S813).

  FIG. 9 is an operation flowchart illustrating a cooperation definition sequence according to the second embodiment. This operation flowchart details the processes of steps S203 and S204 in the operation flowchart of the first embodiment shown in FIG.

  The user sends a combination of the widget instance ID of the issuing widget, the issuing function name, the widget instance ID of the receiving widget, and the receiving function name from the parent frame of the browser 103 to the cooperation definition unit 707 of the relay server 101 (FIG. 9). Step S901).

  The linkage definition unit 707 refers to the user table 702 and checks whether or not the requesting user is a regular user (step S902 in FIG. 9). When the user is confirmed, the linkage definition unit 707 refers to the instance database 703 and confirms that each widget instance ID and each function specified by the user are present and that the owner of each widget is the user. (Step S902 in FIG. 9).

  When the confirmation is completed, the linkage definition unit 707 registers the issued widget instance ID (issued widget name), issued function name, received widget instance ID (received widget name), and received function name in the linked definition table 708 (FIG. 9). Step S903). The configuration of the linkage definition table 708 is the same as the configuration of FIG. 6 described above in the description of the first embodiment.

  FIG. 10 is an operation flowchart illustrating a cooperation sequence according to the second embodiment. This operation flowchart details the processes of steps S205, S206, and S207 of the operation flowchart of the first embodiment shown in FIG.

When the user performs a mouse operation such as address selection or a cursor operation on a child frame of the browser 103, an address selection event occurs (step S1001 in FIG. 10).
As a result, an issue function corresponding to the address selection is called (step S1002 in FIG. 10), and a request is sent from the child frame to the issue reception unit 709 of the relay server 101 by the script injected into the issue function. The issue acceptance unit 709 passes the issue widget instance ID, the issue function name, and the function argument to the distribution allocation unit 710 (step S1003 in FIG. 10).

  The distribution allocating unit 710 refers to the cooperation definition table 708 and searches for a combination of the reception widget instance ID and the reception function corresponding to the combination of the issue widget instance ID and the issue function name (step S1004 in FIG. 10). When one or more pairs are found, the distribution allocator 710 passes the found pair and function argument to the distributor 711 (step S1005 in FIG. 10).

  An iframe streaming Comet request comes in advance from the child frame of the browser 103 to the relay server 101 (step S1000 in FIG. 10). Therefore, the distribution unit 711 transmits a script element including a reception function name and a function argument as a Comeno response to the child frame corresponding to the reception widget instance ID (step S1006 in FIG. 10).

The child frame of the browser 103 calls and executes the reception function corresponding to the reception function name in the received script element with a function argument (step S1007 in FIG. 10).
FIG. 11 is a diagram showing a database schema in the relay server 101.

  In FIG. 11, the user table 702 and the linkage definition table 708 are the same as those shown in FIG. Further, the widget instance table 703-1, the issue function table 703-2, and the reception function 703-3 correspond to the instance database (denoted as “instance / function” in FIG. 7) 703.

  The user table 702 has a hash of a user name and a password, and a unique session ID is randomly created when the user logs in with a correct password, and is stored in this table. While the user is logged in, the session ID is used to identify the user. When the user logs out, the logout process is performed by deleting the session ID from the table.

  In the widget instance table 703-1, each time a user adds or deletes a widget, data is added or deleted. When a widget is added, the issuing function and the receiving function given to the metadata of the added widget are added to the issuing function table 703-2 and the receiving function table 703-3. When the widget is deleted, the corresponding row is deleted from the widget instance table 703-1, and the corresponding function row is also deleted from the issue function table 703-2 and the reception function table 703-3.

  In the linkage definition table 708, the relationship between the issue function and the reception function is defined. This is as described above with reference to FIG. When the issue function is called for the combination of the issue function and the receive function defined in this table, the corresponding receive function is called.

FIG. 12 is an operation flowchart illustrating a request reception process executed by the relay server 101.
The relay server 101 distributes the request to the following four types of processing.

Requests to the relay server 101 itself The content of the relay server 101 is returned as a response, the server-side program on the relay server 101 is executed, and the result is returned.

The request relay server 101 for operating as the relay server 101 reverse-converts the requested URI into the original URI, sends a request to the original URI, converts the response at the relay server 101, Return as.

A request is issued to the relay server 101 when a request relay server 101 for informing the relay server 101 that the issue function has been called is called.

Since the relay server 101 embeds an iframe for iframe streaming in a widget having an asynchronous request reception function for receiving the event to the reception function, the request 101 from the iframe is sent to the relay server. It occurs against. When the event distribution occurs, the relay server 101 uses this stream to distribute the event.

The operation flowchart for executing the above four request distribution processing is shown in FIG. 12. The relay server 101 looks at the domain name written in the Host header of the HTTP (Hypertext Transfer Protocol) request, and converts it for the relay conversion. It is determined whether the domain is a completed domain (step S1202 in FIG. 12).

  If it is not the converted domain, the relay server 101 determines that the request is for itself, and returns the content of the relay server 101 or executes the server side program (steps S1201 to S1208 in FIG. 12).

If the domain name is the converted domain name, the relay server 101 next checks the HTTP request path (steps S1201 to S1202 in FIG. 12).
If the path is not a special reserved path for Comet, it is determined that the request is a relay request to the relay server 101. The relay server 101 reversely converts the requested URI into the original URI (step S1206 in FIG. 12). Then, the relay server 101 relays the request to the original URI, converts the response from the target server 102, and returns it as a response of the relay server 101 (step S1207 in FIG. 12). This operation is executed by the proxy unit 704 as described above.

If the path is a special reserved path for Comet, the relay server 101 determines an HTTP request method (step S1203 in FIG. 12).
If the method is POST, the relay server 101 determines that the event notification is from the issue function, and executes the event issue processing from step S1004 to S1006 in FIG. 10 described above (step S1203 in FIG. 12 → S1204).

  When the method is GET, the relay server 101 determines that the iframe streaming is performed by the iframe injected into the widget including the reception function, and the asynchronous communication stream for delivering the event is kept open ( Steps S1203 → S1205 in FIG. 12). When a request for event distribution occurs from the distribution allocation unit 710, the distribution unit 711 writes the reception function name and argument to the stream so that the reception function is called on the client side.

FIG. 13 is a diagram illustrating an example of mashup using the first or second embodiment.
FIG. 13 shows an example in which an in-house address book, a mailer, and an outside map application cooperate with each other. The address book contains your name, email address, and address. I want to link this address book, mailer, and map, but I want to send an email address to the in-house mailer, only the address to the outside map, and not to send other data. .

  By defining the linkage as shown in the linkage definition table of FIG. 5, it is set so that only the address is passed to the map and no other data is passed, so that the application can be linked while maintaining security. It becomes possible.

In addition, it is possible to link mailer, personnel change book, employee address book, internal application of schedule and external application of map.
FIG. 14 is a diagram illustrating an example of a hardware configuration of a computer that can implement the relay server 101 according to the first or second embodiment.

  The computer shown in FIG. 14 includes a CPU 1401, a memory 1402, an input device 1403, an output device 1404, an external storage device 1405, a portable recording medium driving device 1406 into which a portable recording medium 1409 is inserted, and a network connection device 1407. These are connected to each other by a bus 1408. The configuration shown in the figure is an example of a computer that can implement the above system, and such a computer is not limited to this configuration.

  The CPU 1401 controls the entire computer. The memory 1402 is a memory such as a RAM that temporarily stores a program or data stored in the external storage device 1405 (or the portable recording medium 1409) when executing a program, updating data, or the like. The CUP 1401 performs overall control by reading the program into the memory 1402 and executing it.

  The input device 1403 includes, for example, a keyboard, a mouse, etc. and their interface control devices. The input device 1403 detects an input operation by the user using a keyboard, a mouse, or the like, and notifies the CPU 1401 of the detection result.

  The output device 1404 includes a display device, a printing device, etc. and their interface control devices. The output device 1404 outputs data sent under the control of the CPU 1401 to a display device or a printing device.

The external storage device 1405 is, for example, a hard disk storage device. Mainly used for storing various data and programs.
The portable recording medium driving device 1406 accommodates a portable recording medium 1409 such as an optical disk, SDRAM, compact flash (registered trademark), DVD (Digital Versatile Disc), CD-ROM (Compact Disc Read Only Memory), etc. It has an auxiliary role for the external storage device 1405.

The network connection device 1407 is a device for connecting, for example, a LAN (local area network) or WAN (wide area network) communication line.
The functions of the relay server 101 according to the first or second embodiment are realized by the CPU 1401 executing a program describing the processing content necessary for it. The program may be distributed by being recorded in, for example, the external storage device 1405 or the portable recording medium 1409, or may be acquired from another computer via the network by the network connection device 1407.

  The disclosed technology can be used for a portal site that provides a plurality of Web applications.

101 relay server 102 server, target server 103 browser 701 addition / deletion unit 702 user table 703 instance database 703-1 widget instance table 703-2 issue function table 703-3 reception function table 704 proxy unit 705 URI replacement unit 706 code injection unit 707 Cooperation Definition Unit 708 Cooperation Definition Table 709 Issuance Accepting Unit 710 Distribution Allocation Unit 711 Distribution Unit 1401 CPU
1402 Memory 1403 Input device 1404 Output device 1405 External storage device 1406 Portable recording medium driving device 1407 Network connection device 1408 Bus 1409 Portable recording medium

Claims (6)

Based on the first Web document acquired from the first target server via the relay server, the cooperation source software executed in the browser of the client, and acquired from the second target server via the relay server In the relay method of relaying communication with the cooperation destination software executed in the browser based on the second Web document in the relay server,
The relay server is
The first Web document includes a first event notification including an identifier of the cooperation source software, an identifier of a first function executed in the cooperation source software, and an argument given to the first function, A first injection step of injecting a first command for the cooperation source software to transmit to the relay server;
The cooperation destination software executes the second function with the argument based on the second event notification from the relay server including the identifier of the second function and the argument in the second Web document. A second injection step of injecting a second command of:
A first sending step of sending a first web document infused with the first instruction and a second web document infused with the second instruction to the client;
When the first event notification is received from the cooperation source software, the cooperation source software is associated with the combination of the identifier of the cooperation source software and the identifier of the first function executed by the cooperation source software. The linkage source software included in the first event notification by referring to the linkage definition table that holds a combination of the identifier of the linkage destination software with which the communication is performed and the identifier of the second function executed by the linkage destination software Determining the combination of the identifier of the link destination software and the identifier of the second function executed by the link destination software corresponding to the combination of the identifier of the first function executed by the link source software and the identifier of the first function executed by the link source software; ,
The identifier of the second function included in the determined combination as the second event notification for the collaboration destination software specified based on the identifier of the collaboration destination software included in the determined combination And a second transmission step of transmitting the argument and
A relay method for software-to-software communication, characterized in that: The first instruction includes an identifier of the cooperation source software, an identifier of the first function, and an argument given to the first function when the first function is executed by the cooperation source software. An instruction for transmitting the first event notification to the relay server,
The relay method for software-to-software communication according to claim 1. When the second command is received from the relay server, the second command is based on the second function identifier and the argument included in the second event notification. An instruction to call a function and to give the argument to the second function;
3. The relay method for software-to-software communication according to claim 1 or 2.   The first transmission step is unique to each Web document so that the transmission source address of the first Web document and the transmission source address of the second Web document are determined to be different from each other in the client. 4. The relay method for software-to-software communication according to claim 1, wherein an address is assigned and transmitted to the client. Based on the request from the client, when the first Web document is acquired from the first target server and relayed to the client, the cooperation source software executed in the browser in the client and the request from the client A relay device that relays communication with cooperation destination software executed in the browser when the second Web document is acquired from the second target server based on the second target server and relayed to the client;
The first Web document includes a first event notification including an identifier of the cooperation source software, an identifier of a first function executed in the cooperation source software, and an argument given to the first function, A first injection unit for injecting a first command for transmission from the cooperation source software to the own relay device;
Based on the second event notification from the own relay device including the identifier of the second function and the argument in the second Web document, the cooperation destination software executes the second function with the argument. A second injection part for injecting a second instruction to
A first transmission unit configured to transmit to the client the first Web document in which the first instruction is injected and the second Web document in which the second instruction is injected;
When the first event notification is received from the cooperation source software, the cooperation source software is associated with the combination of the identifier of the cooperation source software and the identifier of the first function executed by the cooperation source software. The linkage source software included in the first event notification by referring to the linkage definition table that holds a combination of the identifier of the linkage destination software with which the communication is performed and the identifier of the second function executed by the linkage destination software A determination unit that determines a combination of an identifier of the cooperation destination software and an identifier of the second function executed by the cooperation destination software corresponding to a combination of the identifier of the first function executed by the cooperation source software When,
The identifier of the second function included in the determined combination as the second event notification for the collaboration destination software specified based on the identifier of the collaboration destination software included in the determined combination And a second transmitter for transmitting the argument and
An inter-software communication relay device comprising: Based on the first Web document acquired from the first target server via the relay server, the cooperation source software executed in the browser of the client, and acquired from the second target server via the relay server A program that relays communication with the cooperation destination software executed in the browser in the relay server based on the second Web document,
To the relay server,
The first Web document includes a first event notification including an identifier of the cooperation source software, an identifier of a first function executed in the cooperation source software, and an argument given to the first function, A first injection step of injecting a first command for the cooperation source software to transmit to the relay server;
The cooperation destination software executes the second function with the argument based on the second event notification from the relay server including the identifier of the second function and the argument in the second Web document. A second injection step of injecting a second command of:
A first sending step of sending a first web document infused with the first instruction and a second web document infused with the second instruction to the client;
When the first event notification is received from the cooperation source software, the cooperation source software is associated with the combination of the identifier of the cooperation source software and the identifier of the first function executed by the cooperation source software. The linkage source software included in the first event notification by referring to the linkage definition table that holds a combination of the identifier of the linkage destination software with which the communication is performed and the identifier of the second function executed by the linkage destination software Determining the combination of the identifier of the link destination software and the identifier of the second function executed by the link destination software corresponding to the combination of the identifier of the first function executed by the link source software and the identifier of the first function executed by the link source software; ,
The identifier of the second function included in the determined combination as the second event notification for the collaboration destination software specified based on the identifier of the collaboration destination software included in the determined combination And a second transmission step of transmitting the argument and
A program for running