WO2012063282A1 - マッシュアップ・アプリケーションの動作方法およびシステム - Google Patents

マッシュアップ・アプリケーションの動作方法およびシステム Download PDF

Info

Publication number
WO2012063282A1
WO2012063282A1 PCT/JP2010/006577 JP2010006577W WO2012063282A1 WO 2012063282 A1 WO2012063282 A1 WO 2012063282A1 JP 2010006577 W JP2010006577 W JP 2010006577W WO 2012063282 A1 WO2012063282 A1 WO 2012063282A1
Authority
WO
WIPO (PCT)
Prior art keywords
information
event
name
message
information operation
Prior art date
Application number
PCT/JP2010/006577
Other languages
English (en)
French (fr)
Inventor
洋子 衣川
俊介 秋藤
Original Assignee
株式会社日立製作所
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 株式会社日立製作所 filed Critical 株式会社日立製作所
Priority to PCT/JP2010/006577 priority Critical patent/WO2012063282A1/ja
Publication of WO2012063282A1 publication Critical patent/WO2012063282A1/ja

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/56—Provisioning of proxy services

Definitions

  • API application programming interface
  • libraries there are various API and library formats to be disclosed.
  • map service that is a typical mashup
  • display processing such as map drawing and marker placement, and handling of events that occurred on the drawn map are handled as APIs and libraries in the form of method calls.
  • information search services such as store search, APIs and libraries published by SNS represented by Twitter, acquire information in data formats such as XML (Extensible Markup Language) and JSON (Java Script Object Notification). What is related to such information manipulation is common.
  • An example of a mashup application is a combination of a map service and a search service. Such an application often has a mechanism of re-searching information when an event occurrence is caught on a map. As an example, there is such a thing as “clicking on an arbitrary point on the map searches for information on stores existing within a certain radius centered on that point and creates a list”.
  • the application acquires data necessary for the event from services on a plurality of different servers.
  • These services are described in various languages and specifications such as XML format such as ATOM and RSS, JSON, and method call.
  • Patent Document 1 discloses that a client includes a workflow engine that makes a service call using JSONP (JSON with padding) in order to acquire data in XML format from a plurality of servers.
  • JSONP JSON with padding
  • the client accesses the service providing server according to the number of services required to execute processing corresponding to the event, so the client increases as the number of services increases.
  • the number of connections from the service provider server to the service provider increases, and the browser is heavily loaded.
  • the client application interacts with the service providing server in a data format corresponding to the type of each library. There was a need to do.
  • a system includes a client computer having a browser and a proxy server, and the browser displays a screen display library and an information operation name for an event occurring on the browser.
  • the proxy server includes a data integration framework for requesting an external service providing server that executes the information operation to execute the information operation, and the event / display frame.
  • the operation name and the argument are collected into one first message, the first message is transmitted to the data integration framework, the data integration framework receives the first message, and the plurality of information
  • the name and argument of the corresponding information operation are acquired from the first message and transmitted to the service providing server, the execution result for each of the plurality of information operations is received from the service providing server,
  • the execution results acquired for each of the plurality of information operations are collected into one second message and transmitted to the event / display framework.
  • the event / display framework receives a plurality of execution results from the second message.
  • the plurality of execution results are extracted using the screen display library corresponding to the event. And displaying to The.
  • FIG. 1 is a diagram illustrating an example of a hardware configuration according to one embodiment.
  • Reference numeral 100 is a client computer that executes an application.
  • Reference numeral 300 denotes a service providing server that provides a service.
  • a proxy server 200 is interposed between the client computer 100 and the service providing server 300 and executes a part of application processing.
  • Reference numerals 1010, 2010, and 3010 denote CPUs.
  • Reference numerals 1020, 2020, and 3020 denote memories.
  • Reference numerals 1030, 2030, and 3030 denote storage devices.
  • Reference numerals 1040, 2040, and 3040 denote communication apparatuses.
  • Reference numerals 1050, 2050, and 3050 denote buses for connecting them.
  • 1060 is a keyboard
  • 1070 is a mouse
  • 1080 is an input / output device for controlling these input / output devices.
  • Reference numerals 400 and 410 denote a network connecting the client computer 100 and the proxy server 200 and a network connecting the proxy server 200 and the service providing server 300, respectively.
  • FIG. 2 is a diagram illustrating an example of a software configuration according to one embodiment.
  • a client browser 110 is software that runs on the client computer 100.
  • the client browser 110 is stored in the storage device 1030, loaded into the memory 1020 at the time of activation, and executed by the CPU 1010.
  • An event / display application 120 is an application executed on the client browser 110.
  • the event / display application 120 is stored in a storage device 2030 of a proxy server program 210 (to be described later) during application development, loaded into the memory 2020 and executed by the CPU 1010 when the proxy server program 210 is activated.
  • the event / display application 120 is downloaded onto the client browser 110 when accessed from the client browser 110.
  • a JavaScript engine 130 executes the event / display application 120.
  • the JavaScript engine 120 is a part of the functions implemented by the client browser 110, and is stored in the storage device 1030 like the client browser 110, loaded into the memory 1020 when the client browser 110 is activated, and executed by the CPU 1010.
  • Reference numeral 140 denotes a DOM operation library that operates HTML and XML.
  • the DOM operation library 140 is a library provided by the client browser 110, and is stored in the storage device 1030 like the client browser 110, loaded into the memory 1020 when the client browser 110 is started up, and executed by the CPU 1010.
  • Reference numeral 150 denotes an event / display library for displaying service execution results and handling generated events.
  • the event / display library 150 is stored in the storage device 2030 of the proxy server program 210, which will be described later, during application development.
  • the event / display library 150 is loaded into the memory 2020 and executed by the CPU 1010 when the proxy server program 210 is activated.
  • the event / display library 150 is downloaded onto the client browser 110 when accessed from the client browser 110.
  • Reference numeral 160 denotes an event / display framework that operates on the JavaScript engine 130, and provides functions frequently used by the event / display application 120 as components.
  • a wrapper for the event / display library 150 and the DOM operation library 140 is provided in a form that summarizes a series of frequently used processes.
  • the wrapper includes a data format conversion function and a communication function with the data integration framework 260. Further, this series of processing includes reference to an API of the information operation library 250 described later.
  • the event / display framework 160 is prepared in advance by a mashup service provider (a supplier that provides and provides infrastructure for performing mashup) together with the proxy server program 210, and is provided so that application developers can use it during development. Development and execution framework.
  • a mashup service provider a supplier that provides and provides infrastructure for performing mashup
  • the event / display framework 160 aggregates information necessary for the execution of the information operation library 250 described later, creates normalized data described later, and creates a communication device 1040.
  • the event / display framework 160 also receives normalized data obtained by aggregating the results of the information manipulation library executed on the proxy server 200 side.
  • the event / display framework 160 is stored in the storage device 2030 of the proxy server program 210, which will be described later, during application development, and is loaded into the memory 2020 and executed by the CPU 2020 when the proxy server program 210 is activated.
  • the event / display frame 160 is downloaded onto the client browser 110 when accessed from the client browser 110.
  • 210 is a proxy server program which is software operating on the proxy server 200.
  • the proxy server program 210 is stored in the storage device 2030, loaded into the memory 2020 at the time of activation, and executed by the CPU 2020.
  • Reference numeral 220 denotes a data integration application that is executed on the proxy server program 210 and is a part of the application.
  • the data integration application 220 is stored in the storage device 2030 of the proxy server program 210, loaded into the memory 2020 when the proxy server program 210 is activated, and executed by the CPU 2020.
  • Reference numeral 230 denotes a JavaScript engine that executes the data integration application 220.
  • the JavaScript engine 220 is a part of the functions implemented by the proxy server program 210.
  • the JavaScript engine 220 is stored in the storage device 2030, loaded into the memory 2020 when the proxy server program 210 is activated, and executed by the CPU 2020.
  • Reference numeral 240 denotes a DOM operation library that operates HTML and XML.
  • the DOM operation library 240 is a library provided by the proxy server program 210.
  • the DOM operation library 240 is stored in the storage device 2030, loaded into the memory 2020 when the proxy server program 210 is activated, and executed by the CPU 2020.
  • Reference numeral 250 denotes an information operation library for accessing information provided by the service.
  • the information operation library 250 is stored in the storage device 2030, loaded into the memory 2020 when the proxy server program 210 is activated, and executed by the CPU 2020.
  • Reference numeral 260 denotes a data integration framework that operates on the JavaScript engine 230, and provides functions often used by the data integration application 220 as components. For example, a data format conversion function and a communication function with the event / display framework 160 are included.
  • the data integration framework 160 analyzes the normalized data received from the client computer 100, acquires the API of the information operation library 250 to be executed and necessary arguments, and executes it by connecting to the corresponding service providing servers 300 to 320. Then, normalization data in which the execution results are aggregated is created and returned to the client computer 100.
  • the data integration framework 260 is a development / execution framework that is prepared in advance by a mashup service provider together with the proxy server program 210 and provided for use by an application developer during development.
  • the data integration framework 260 is stored in the storage device 2030 of the proxy server program 210 during application development, loaded into the memory 2020 and executed by the CPU 2020 when the proxy server program 210 is activated.
  • both the client browser 110 and the proxy server program 210 are equipped with the JavaScript engine 130, 230, but an application is developed and executed by another technology such as CGI or another language. If possible, the client browser 110 and the proxy server program 210 may use the technology and language.
  • an application is developed by being divided into an event / display application 120 and a data integration application 220.
  • the event / display application 120 and the data integration application are both deployed on the proxy server program 210 during development.
  • the event / display application 120 is downloaded to the client browser 110 and executed on the client browser 110 when the client browser 110 accesses the proxy server program 210.
  • the data integration application 220 is executed on the proxy server program 210.
  • a direct connection from the client browser 110 to the service providing servers 300, 310, and 320 does not occur, and the application is connected via the proxy server program 210 to the service providing server 300, Communicate with 310, 320.
  • the client browser 110 and the proxy server program 210 communicate with each other by a message according to a specific data format. This message is called normalized data in this embodiment. Examples of normalized data are shown in FIGS.
  • FIG. 3 is an example of normalized data 400 transmitted from the client browser 110 to the proxy server program 210.
  • the normalized data 400 transmitted from the client browser 110 to the proxy server program 210 collects information necessary for executing the information operation library 250 of each service.
  • the normalized data 400 is described in the JSON format, and the name of the information operation library 250 to be executed is the store list acquisition API (getList) of the store search service (Shop) and the weather of the weather forecast service (Weather).
  • the acquisition API (getWeather) is specified, and the values of arguments lat (latitude) and lng (longitude) necessary for the execution are included.
  • FIG. 4 is an example of normalized data 500 transmitted from the proxy server program 210 to the client browser 110.
  • the normalized data 500 transmitted from the proxy server program 210 to the client browser 110 aggregates the execution results of each service.
  • the normalized data 500 is described in the JSON format and includes a plurality of data such as a store name (name), a category (category), an address (address), and a telephone number (tel) as a result of the store search service (Shop).
  • data such as weather (weather) and temperature (temperature) is included as a result of the weather forecast service (Weather).
  • the JSON format is used as an example of normalized data, but a format other than JSON, such as XML, may be used.
  • the event / display application 120 is developed and executed using the event / display framework 160.
  • the event / display framework 160 provides APIs of the event / display library 150 and the DOM operation library 140 as a series of commonly used processes. For example, in the map service (Map), if an API for drawing is used in the event / display library 150 for the map service (Map), the event / display framework 160 uses a series of APIs for drawing. API (draw) can be provided.
  • the event / display framework 160 in the store search service (Shop), assuming that a pattern using an API (showList) for displaying a result following an API (getList) for acquiring a store list is common, the event / display framework 160 Then, it is possible to provide an API (list) that summarizes the series of processes. However, since getList is an API of the information operation library 250 and is actually executed by the proxy server program 210, the event / display framework 160 is not an entity of getList, but the entity is stored on the proxy server program 210. Describe the name getList.
  • the event / display framework 160 An API (weather) that summarizes the series of processes can be provided. However, since getWeather is an API of the information manipulation library 250 and is actually executed by the proxy server program 210, the event / display framework 160 stores the entity on the proxy server program 210, not the entity of getWeather. Describe the name getWeather. The event / display framework 160 also aggregates information necessary for executing the information operation library 250 of each service into the normalized data 400 when the event / display application 120 is executed, and transmits it to the proxy server program 210. The process of receiving the normalized data 500 from 210 is concealed. As described above, the application developer can easily develop the event / display application 120 by using the event / display framework 160.
  • FIG. 5 shows a screen example of the event / display application 120.
  • This is an example of a mashup of a map service, a weather forecast service, and a store search service, and is an application that displays a weather forecast of a map display area and store information marked on the map.
  • a tool for changing the zoom hereinafter referred to as a zoom change bar
  • the zoom of the map can be changed by clicking the mouse.
  • a “zoom” event occurs when an attempt is made to change the zoom of the map by clicking the mouse.
  • FIG. 6 shows an example of a part related to event processing in the source code of the event / display application.
  • an action that is executed on a part on the screen when an event occurs in some service is described in a tag format.
  • three tags are described for a zoom event of the map service (Map). The first is to instruct the map service component (MapWidget) to execute redraw (draw). The second is to instruct execution of an API (list) for acquiring and displaying a store list with respect to a display component (ShopWidget) of the store search service. The third is to instruct the weather forecast service display component (WeatherWidget) to execute an API (weather) that acquires and displays the weather.
  • an action may be provided as, for example, a JavaScript library.
  • zoom zoom change
  • events such as initialization and mouse clicks that occur on the HTML elements of the client browser 110 and the user application 140 defined by the W3C DOM Level 2 Events Specification.
  • events for objects that are generated when the service is used such as events such as zoom changes that occur on map objects in the map service.
  • a mechanism for locally detecting an event that occurs in a remote environment as defined by HTML5 WebSocket, is also included in the types of events handled in this embodiment.
  • the data integration application 220 is developed and executed using the data integration framework 260.
  • the data integration framework 260 conceals the portion related to the data format and communication method of the information manipulation library 250 and absorbs the difference in data format and communication method.
  • the data integration application 220 can access, for example, the store search service (Shop) of XML format data and the weather forecast service (Weather) of JSON format data through the same interface and return. The value can be received in the same format.
  • the store search service (Shop) is described in XML
  • the weather forecast service (Weather) is described in JSON format.
  • the process of receiving the normalized data 400 from the client browser 110 or consolidating the execution results of each service into the normalized data 500 and transmitting it to the client browser 110 is concealed.
  • the developer can easily develop the data integration application 220 by using the data integration framework 260.
  • FIG. 7 is a diagram illustrating an example of processing performed by the event / display framework 160 when the event / display application 120 is executed.
  • FIG. 8 is a diagram illustrating an example of processing performed by the data integration framework 260 when the data integration application 220 is executed.
  • a process performed when the user application is executed will be described with reference to FIGS.
  • the client browser 110 accesses the proxy server program 210, the event / display framework 160, the event / display application 120, and the event / display library 150 are downloaded to the client browser 110, and the event / display application 120 is initialized. A screen is displayed on the client browser 110.
  • the event / display framework 160 enters a standby state for event occurrence (step 7010).
  • the event / display framework 160 detects the occurrence of the event 'zoom (zoom change)' (step 7020).
  • the event / display framework 160 obtains a reference to the API of the information manipulation library 250 hidden inside the action designated for the event (step 7030). For example, in the example of the source code shown in FIG. 6, three actions “draw”, “list”, and “weather” are designated for zoom.
  • the event / display framework 160 obtains a reference to getList and getWeather, which are APIs of the information operation library 250 hidden inside these APIs, from the description inside the event display / framework 160 itself.
  • the event / display framework 160 creates normalized data 400 in which information necessary for executing the API of the information operation library 250 acquired in step 7030 is aggregated.
  • the normalized data 400 is created in the JSON format as described above (step 7040).
  • the normalized data 400 includes the values of lat (latitude) and ng (longitude) as arguments necessary for executing the getList of the store search service (Shop), and the weather forecast service (Weather). It is created as JSON format data including lat (latitude) and lng (longitude) values as arguments necessary for execution of getWeather.
  • the lat (latitude) and ng (longitude) are acquired for an arbitrary position on the map using an API provided by the map service.
  • the logic for obtaining the lat (latitude) and ng (longitude) of the map center using the corresponding API is implemented in the event / display application 120, so that lat (latitude) and ng (longitude) are obtained. To do.
  • the event / display framework 160 transmits the normalized data 400 created in step 7040 to the data integration application 220 via the communication device 1040 (step 7050), and enters a standby state (step 7060).
  • the data integration application 220 is developed by using the function provided by the data integration framework 260.
  • the data integration framework 260 uses the function of the data integration framework 260.
  • the normalized data 400 is analyzed, and the API of the information manipulation library to be executed and necessary arguments are acquired (step 8010).
  • the acquired arguments are the getList of the store search service (Shop), the arguments lat (latitude) and lng (longitude) necessary for the execution, the getWeather of the weather forecast service (Weather), and the execution thereof Are the values of the arguments lat (latitude) and lng (longitude) required for (step 8010).
  • the data integration framework 260 connects to the service providing servers 300 and 320 of the store search service (Shop) and the weather forecast service (Weather) via the communication device 2040, and uses the information acquired in Step 8010 to Request execution of the API of the service and wait for the result (step 8020).
  • the values of lat (latitude) and lng (longitude) are given to getList and getWeather, respectively.
  • the data integration framework 260 requests the service providing server to execute, the data integration framework 260 specifies the service providing server that executes the service and the data format of the request according to the type of service.
  • FIG. 10 shows a conversion table for determining the designation method.
  • the data integration framework 260 refers to the conversion table of FIG.
  • the data integration framework 260 specifies XML as the data format and requests the service providing server 1 to execute getList, while specifying JSON as the data format and requests the service providing server 2 to execute getWeather. .
  • the data integration framework 260 receives API execution results from the service providing servers 300 and 320 of the store search service (Shop) and the weather forecast service (Weather) via the communication device 2040, and temporarily stores them in a buffer or the like. (Step 8030).
  • the execution result of getList is received as XML format data
  • the execution result of getWeather is received as JSON format data.
  • the data integration framework 260 creates the normalized data 500 for returning the results to the client browser 110 when all the execution results are complete (step 8040).
  • the XML format data that is the execution result of getList and the JSON format data that is the execution result of getWeather are collected into one message in the JSON format.
  • the execution result of getWeather which is an API of the weather forecast service (Weather)
  • the API of getWeather which is the API of the store search service (Shop)
  • the execution result needs to be converted to the JSON format. Therefore, the data integration framework 260 converts the getWeather execution result into the JSON format using a conversion library or the like, and merges it with the getWeather execution result.
  • the data integration framework 260 transmits the normalized data 500 created in Step 8040 to the event / display application 120 via the communication device 2040 (Step 8050).
  • the event / display application 120 is developed using a function provided by the event / display framework 160.
  • the event / display application 120 receives the normalized data 500 via the communication device 1040, the event / display framework 120 is displayed.
  • the normalized data 500 is analyzed by the function 160 to obtain an execution result (step 7070).
  • the execution results of getList and getWeather are respectively acquired as JSON format data.
  • the event / display framework 160 executes the API of the event / display library 150 hidden inside the action designated for the event (step 7080). For example, in the example of the source code shown in FIG. 6, three actions 'draw', 'list', and 'weather' are specified for zoom, and the API of the event / display library 150 is set inside 'list'. In getList, getWeather is specified inside 'weather'. The event / display framework 160 redraws the map and re-displays the execution result acquired in Step 7070 using getList and getWeather (Step 7080).
  • FIG. 9 is a sequence diagram showing processing executed between the client computer and the proxy server.
  • the client computer 100 creates normalized data and transmits it to the proxy server 200.
  • the proxy server analyzes the normalized data, issues a service execution request to the plurality of service providing servers 300 to 320, and waits for the result.
  • the proxy server 200 waits for the result, creates normalized data in which all the results are aggregated, and transmits it to the client computer 100.
  • the client computer 100 displays the execution result using the display library.
  • the connection is limited to one connection between the client browser 110 and the proxy server program 210.
  • the entity of the event / display library 150 is downloaded to the local environment and completely separated from each service providing server 300, 310, 320.
  • the client browser 110 uses the downloaded event / display library 150 for event and display processing, and does not connect to the service providing servers 300, 310, and 320.
  • the client browser need only have one connection with the proxy server program, and the load on the browser increases extremely. You can avoid that.
  • the downloaded library is used for event detection and data display, connection to each service provider does not occur, and the load on the browser can be reduced.
  • the proxy server program when the proxy server program first connects from the client browser, the result of executing the information operation library of each service may be returned to the client browser and stored in the cache. If there is a connection from another client browser within a certain period of time after that, the normalization message is analyzed, the information operation library and arguments described in the message are investigated, and the same user application is used. If it is determined that it is, the stored cache is returned without executing the information operation library of each service.
  • the information operation library of each service can be executed only when connecting from the first client browser, and the cache can be used during subsequent connections. As a result, the load on the proxy server itself can be reduced, and the time required for a response to another client browser can be shortened.
  • DESCRIPTION OF SYMBOLS 110 ... Client browser, 120 ... Event / display application, 130 ... JavaScript engine, 140 ... DOM operation library, 150 ... Event / display library, 160 ... Event / display framework, 210 ... Proxy server program, 220 ... Data integration application, 230 ... JavaScript engine, 240 ... DOM operation library, 250 ... Information operation library, 260 ... Data integration framework, 300, 31, 320 ... Service providing server

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Information Transfer Between Computers (AREA)

Abstract

　クライアント・アプリケーションにてイベントが発生した際に、必要な情報をサービス提供サーバから取得する場合において、ブラウザの負荷が極端に増加することを回避すること。　クライアントブラウザとサービス提供サーバとの間にプロキシサーバプログラムを設け、従来クライアントブラウザ上で実行していたイベント・表示ライブラリと情報操作ライブラリのうち、情報操作ライブラリをプロキシサーバプログラム上で実行する。具体的には、アプリケーションは、情報操作ライブラリを直接利用するのではなく、情報操作ライブラリの実行に必要となる情報を１つのメッセージに集約し、プロキシサーバプログラムに送信する。プロキシサーバプログラムは、メッセージを解析し、各サービスにアクセスする情報操作ライブラリを実行し、各サービスから取得した情報を、１つのメッセージに集約してブラウザに返す。

Description

マッシュアップ・アプリケーションの動作方法およびシステム
　インターネット上で公開される複数のサービスを組み合わせて新規にアプリケーションを作成するマッシュアップ技術に関する。
　インターネット上では様々なサービスが利用可能である。近年、ＡＰＩ（ａｐｐｌｉｃａｔｉｏｎ　ｐｒｏｇｒａｍｍｉｎｇ　ｉｎｔｅｒｆａｃｅ）やライブラリを公開するサービスの増加に伴い、ユーザがＡＰＩやライブラリを駆使して新規にアプリケーションを作成する、マッシュアップと呼ばれる開発手法がある。公開されるＡＰＩやライブラリの形式は様々である。例えば、マッシュアップの代表格である地図サービスの場合、地図の描画やマーカーの配置といった表示系の処理や、描画した地図上で発生したイベントのハンドリングといった処理が、メソッド呼び出し形式のＡＰＩやライブラリとして備えられていることが一般的である。一方、店舗検索のような情報検索サービスや、Ｔｗｉｔｔｅｒに代表されるＳＮＳで公開されているＡＰＩやライブラリは、ＸＭＬ（Ｅｘｔｅｎｓｉｂｌｅ　Ｍａｒｋｕｐ　Ｌａｎｇｕａｇｅ）やＪＳＯＮ（ＪａｖａＳｃｒｉｐｔ　Ｏｂｊｅｃｔ　Ｎｏｔａｔｉｏｎ）等のデータ形式で情報を取得するような情報操作に関わるものが一般的である。
　マッシュアップは既存のサービスを利用するため、ユーザはマッシュアップを用いて容易に独自のアプリケーションを作成することができる。
　マッシュアップ・アプリケーションの例として、地図サービスと検索系のサービスとを組み合わせたものがある。このようなアプリケーションは、地図上でイベント発生をキャッチすると情報を検索し直すといった仕組みを具備することが多い。一例として、「地図上の任意の地点をクリックすると、その地点を中心とした一定半径内に存在する店舗の情報を検索して一覧を作成する」というようなものがある。
　マッシュアップ・アプリケーションにおいて或るイベントが発生すると、当該アプリケーションがそのイベントに対して必要なデータを複数の異なるサーバ上のサービスから取得する。これらのサービスは、ＡＴＯＭ、ＲＳＳのようなＸＭＬ形式、ＪＳＯＮ、メソッド呼出しのように様々な言語、仕様により記述されている。
　特許文献１では、複数のサーバからＸＭＬ形式でデータを取得するためにＪＳＯＮＰ（ＪＳＯＮ　ｗｉｔｈ　ｐａｄｄｉｎｇ）によるサービス呼び出しを行うワークフローエンジンをクライアントが具備することが開示されている。
米国特許出願第２０１０－０１２５６２３号
　しかしながら、上記の従来技術には、クライアント側に多大な負荷がかかるという課題がある。
　例えば、クライアント側でイベントが発生するたびに、そのイベントに対応する処理を実行するために必要なサービスの数に応じてクライアントがサービス提供サーバにアクセスするため、サービスの数が増加するに伴いクライアントからサービス提供サーバへの接続数も増加し、ブラウザに多大な負荷がかかる。
　また、例えば、さまざまな言語で記述された表示、イベント、および情報操作に係わるライブラリがアプリケーション内に混在するため、クライアント・アプリケーションが、それぞれのライブラリの種別に応じたデータ形式でサービス提供サーバとやりとりする必要があった。
　上記課題を解決するため、本発明にかかるシステムは、ブラウザを有するクライアント・コンピュータとプロキシ・サーバとを有し、上記ブラウザは、上記ブラウザ上で発生するイベントに対する、画面表示ライブラリと情報操作の名前とを記述したイベント・表示フレームワークを備え、上記プロキシ・サーバは、上記情報操作を実行する外部のサービス提供サーバに上記情報操作の実行を要求するデータ統合フレームワークを備え、上記イベント・表示フレームワークは、上記ブラウザを介したユーザからの入力により発生したイベントを検出すると、上記イベントに対応する複数の情報操作を実行するために、上記複数の情報操作の各々について必要な情報操作の名前と引数を取得し、上記複数の情報操作の各々について取得した情報操作の名前と引数を１つの第１のメッセージに纏め、上記第１のメッセージを上記データ統合フレームワークに送信し、上記データ統合フレームワークは、上記第１のメッセージを受信し、上記複数の情報操作の各々について、対応する情報操作の名前と引数を上記第１のメッセージから取得して上記サービス提供サーバに送信し、上記サービス提供サーバから上記複数の情報操作各々についての実行結果を受け取り、上記複数の情報操作の各々について取得した実行結果を１つの第２のメッセージに纏めて上記イベント・表示フレームワークに送信し、上記イベント・表示フレームワークは、上記第２のメッセージから複数の実行結果を取り出し、上記イベントに対応する上記画面表示ライブラリを用いて上記複数の実行結果を上記ブラウザに表示することを特徴とする。
　上記構成によれば、イベントが発生した際にクライアント・アプリケーションがサービス提供サーバに対してデータを送受信する際の負荷を軽減することができる。
ハードウェア構成の例を示す図である。 ソフトウェア構成の例を示す図である。 クライアントブラウザからプロキシサーバプログラムに送信される正規化データの例である。 プロキシサーバプログラムからクライアントブラウザに送信される正規化データの例である。 イベント・表示アプリケーションの画面例である。 イベント・表示アプリケーションのソースコードのうち、イベント処理に係わる部分の例である。 アプリケーション実行時の、イベント・表示フレームワークの実施手順の例を説明する図である。 アプリケーション実行時の、データ統合フレームワークの実施手順の例を説明する図である。 クライアント・コンピュータとプロキシサーバ間で実行される処理を示すシーケンス図である。 各サービスを実行するサービス提供サーバと、サービス提供サーバおよびクライアントとデータをやり取りする際のデータ形式を決めるための変換表を示す図である。
　以下、本発明の実施の形態を説明する。
　図１は、１実施形態に従うハードウェア構成の例を示す図である。
　１００は、アプリケーションを実行するクライアントコンピュータである。３００は、サービスを提供するサービス提供サーバである。２００は、クライアントコンピュータ１００とサービス提供サーバ３００との間に介在し、アプリケーションの処理の一部を実行するプロキシサーバである。１０１０、２０１０、３０１０はＣＰＵである。１０２０、２０２０、３０２０はメモリである。１０３０、２０３０、３０３０は記憶装置である。１０４０、２０４０、３０４０は通信装置である。１０５０、２０５０、３０５０はそれらを接続するバスである。１０６０はキーボード、１０７０はマウスであり、１０８０はそれら入出力デバイスを制御する入出力装置である。４００、４１０は、それぞれ、クライアントコンピュータ１００とプロキシサーバ２００とを接続するネットワーク、および、プロキシサーバ２００とサービス提供サーバ３００とを接続するネットワークである。
　図２は、１実施形態に従うソフトウェア構成の例を示す図である。１１０は、クライアントコンピュータ１００上で動作するソフトウェアであるクライアントブラウザである。クライアントブラウザ１１０は記憶装置１０３０に格納され、起動時にメモリ１０２０にロードされてＣＰＵ１０１０によって実行される。１２０は、クライアントブラウザ１１０上で実行されるアプリケーションである、イベント・表示アプリケーションである。イベント・表示アプリケーション１２０は、アプリケーション開発時には後述するプロキシサーバプログラム２１０の記憶装置２０３０に格納され、プロキシサーバプログラム２１０の起動時にメモリ２０２０にロードされてＣＰＵ１０１０によって実行される。イベント・表示アプリケーション１２０は、クライアントブラウザ１１０からのアクセス時に、クライアントブラウザ１１０上にダウンロードされる。１３０は、イベント・表示アプリケーション１２０を実行するＪａｖａＳｃｒｉｐｔエンジンである。ＪａｖａＳｃｒｉｐｔエンジン１２０は、クライアントブラウザ１１０が実装する機能の一部であり、クライアントブラウザ１１０同様、記憶装置１０３０に格納され、クライアントブラウザ１１０の起動時にメモリ１０２０にロードされてＣＰＵ１０１０によって実行される。１４０は、ＨＴＭＬやＸＭＬを操作するＤＯＭ操作ライブラリである。ＤＯＭ操作ライブラリ１４０は、クライアントブラウザ１１０が提供するライブラリであり、クライアントブラウザ１１０同様、記憶装置１０３０に格納され、クライアントブラウザ１１０の起動時にメモリ１０２０にロードされてＣＰＵ１０１０によって実行される。１５０は、サービスの実行結果を表示したり、発生したイベントをハンドリングするためのイベント・表示ライブラリである。イベント・表示ライブラリ１５０は、アプリケーション開発時には後述するプロキシサーバプログラム２１０の記憶装置２０３０に格納され、プロキシサーバプログラム２１０の起動時にメモリ２０２０にロードされてＣＰＵ１０１０によって実行される。イベント・表示ライブラリ１５０は、クライアントブラウザ１１０からのアクセス時に、クライアントブラウザ１１０上にダウンロードされる。１６０は、ＪａｖａＳｃｒｉｐｔエンジン１３０上で動作するイベント・表示フレームワークであり、イベント・表示アプリケーション１２０がよく利用する機能をコンポーネント化して提供する。具体的には、イベント・表示ライブラリ１５０やＤＯＭ操作ライブラリ１４０のラッパーを、よく利用される一連の処理を纏めた形で提供する。例えば、当該ラッパーは、データ形式変換機能や、データ統合フレームワーク２６０との通信機能を含む。また、この一連の処理には、後述する情報操作ライブラリ２５０のＡＰＩへの参照も含まれる。イベント・表示フレームワーク１６０は、プロキシサーバプログラム２１０とともにマッシュアップ・サービス・プロバイダ（マッシュアップを行うためのインフラを整備し提供する業者）があらかじめ用意し、アプリケーション開発者が開発時に利用できるよう提供した開発・実行フレームワークである。イベント・表示フレームワーク１６０は、イベント・表示アプリケーション１２０上で発生したイベントを検知すると、後述する情報操作ライブラリ２５０の実行に必要な情報を集約し、後述する正規化データを作成し、通信装置１０４０を通じてプロキシサーバ２００に送信する。イベント・表示フレームワーク１６０はまた、プロキシサーバ２００側で実行された情報操作ライブラリの結果を集約した正規化データを受信する。イベント・表示フレームワーク１６０は、アプリケーション開発時には後述するプロキシサーバプログラム２１０の記憶装置２０３０に格納され、プロキシサーバプログラム２１０の起動時にメモリ２０２０にロードされてＣＰＵ２０２０によって実行される。イベント・表示フレームー枠１６０は、クライアントブラウザ１１０からのアクセス時に、クライアントブラウザ１１０上にダウンロードされる。
　２１０は、プロキシサーバ２００上で動作するソフトウェアであるプロキシサーバプログラムである。プロキシサーバプログラム２１０は記憶装置２０３０に格納され、起動時にメモリ２０２０にロードされてＣＰＵ２０２０によって実行される。２２０は、プロキシサーバプログラム２１０上で実行される、アプリケーションの一部であるデータ統合アプリケーションである。データ統合アプリケーション２２０は、プロキシサーバプログラム２１０の記憶装置２０３０に格納され、プロキシサーバプログラム２１０の起動時にメモリ２０２０にロードされてＣＰＵ２０２０によって実行される。２３０は、データ統合アプリケーション２２０を実行するＪａｖａＳｃｒｉｐｔエンジンである。ＪａｖａＳｃｒｉｐｔエンジン２２０は、プロキシサーバプログラム２１０が実装する機能の一部であり、プロキシサーバプログラム２１０同様、記憶装置２０３０に格納され、プロキシサーバプログラム２１０の起動時にメモリ２０２０にロードされてＣＰＵ２０２０によって実行される。２４０は、ＨＴＭＬやＸＭＬを操作するＤＯＭ操作ライブラリである。ＤＯＭ操作ライブラリ２４０は、プロキシサーバプログラム２１０が提供するライブラリであり、プロキシサーバプログラム２１０同様、記憶装置２０３０に格納され、プロキシサーバプログラム２１０の起動時にメモリ２０２０にロードされてＣＰＵ２０２０によって実行される。２５０は、サービスが提供する情報にアクセスするための情報操作ライブラリである。情報操作ライブラリ２５０は、記憶装置２０３０に格納され、プロキシサーバプログラム２１０の起動時にメモリ２０２０にロードされてＣＰＵ２０２０によって実行される。２６０は、ＪａｖａＳｃｒｉｐｔエンジン２３０上で動作するデータ統合フレームワークであり、データ統合アプリケーション２２０がよく利用する機能をコンポーネント化して提供する。例えば、データ形式変換機能や、イベント・表示フレームワーク１６０との通信機能を含む。データ統合フレームワーク１６０は、クライアントコンピュータ１００から受信した正規化データを解析し、実行すべき情報操作ライブラリ２５０のＡＰＩと必要な引数を取得し、該当するサービス提供サーバ３００～３２０に接続して実行し、実行結果を集約した正規化データを作成し、クライアントコンピュータ１００に返す。データ統合フレームワーク２６０は、プロキシサーバプログラム２１０とともにマッシュアップ・サービス・プロバイダがあらかじめ用意し、アプリケーション開発者が開発時に利用できるよう提供した開発・実行フレームワームである。データ統合フレームワーク２６０は、アプリケーション開発時にはプロキシサーバプログラム２１０の記憶装置２０３０に格納され、プロキシサーバプログラム２１０の起動時にメモリ２０２０にロードされてＣＰＵ２０２０によって実行される。
　なお、ここでは、実施形態の一例としてクライアントブラウザ１１０、プロキシサーバプログラム２１０がともにＪａｖａＳｃｒｉｐｔエンジン１３０、２３０を搭載することを前提としているが、ＣＧＩ等の別技術、別言語によりアプリケーションを開発し実行することが可能であれば、クライアントブラウザ１１０およびプロキシサーバプログラム２１０は当該技術、言語を利用しても良い。
　以下、各図を用いて、本発明の実施の形態を詳細に説明する。
　まず、１実施形態におけるアプリケーション開発の特徴を説明する。
　第１の特徴として、アプリケーションは、イベント・表示アプリケーション１２０とデータ統合アプリケーション２２０に分けて開発される。イベント・表示アプリケーション１２０とデータ統合アプリケーションは、いずれも、開発時にはプロキシサーバプログラム２１０上に配備されている。イベント・表示アプリケーション１２０は、クライアントブラウザ１１０がプロキシサーバプログラム２１０へアクセスする時に、クライアントブラウザ１１０にダウンロードされ、クライアントブラウザ１１０上で実行される。一方、データ統合アプリケーション２２０は、プロキシサーバプログラム２１０上で実行される。
　第２の特徴として、アプリケーションが実行される際に、クライアントブラウザ１１０からサービス提供サーバ３００、３１０、３２０への直接の接続は発生せず、アプリケーションはプロキシサーバプログラム２１０を介してサービス提供サーバ３００、３１０、３２０と通信する。また、クライアントブラウザ１１０とプロキシサーバプログラム２１０は、特定のデータ形式に従ったメッセージにより通信を行う。このメッセージを本実施形態では正規化データと呼ぶ。正規化データの例を図３、図４に示す。
　図３は、クライアントブラウザ１１０からプロキシサーバプログラム２１０に送信される正規化データ４００の例である。クライアントブラウザ１１０からプロキシサーバプログラム２１０に送信される正規化データ４００は、各サービスの情報操作ライブラリ２５０の実行に必要な情報を集約する。ここでは、正規化データ４００は、ＪＳＯＮ形式で記述され、実行すべき情報操作ライブラリ２５０の名称として、店舗検索サービス（Ｓｈｏｐ）の店舗一覧取得ＡＰＩ（ｇｅｔＬｉｓｔ）と、天気予報サービス（Ｗｅａｔｈｅｒ）の天気取得ＡＰＩ（ｇｅｔＷｅａｔｈｅｒ）を指定するとともに、それらの実行に必要な引数ｌａｔ（緯度）、ｌｎｇ（経度）の値を含む。
　次に、図４は、プロキシサーバプログラム２１０からクライアントブラウザ１１０に送信される正規化データ５００の例である。プロキシサーバプログラム２１０からクライアントブラウザ１１０に送信される正規化データ５００は、各サービスの実行結果を集約するものである。ここでは、正規化データ５００は、ＪＳＯＮ形式で記述され、店舗検索サービス（Ｓｈｏｐ）の結果として店舗名（ｎａｍｅ）、カテゴリ（ｃａｔｅｇｏｒｙ）、住所（ａｄｄｒｅｓｓ）、電話番号（ｔｅｌ）といったデータを複数含むとともに、天気予報サービス（Ｗｅａｔｈｅｒ）の結果としてｗｅａｔｈｅｒ（天気）、ｔｅｍｐｅｒａｔｕｒｅ（気温）といったデータを含む。なお、ここでは、正規化データの例としてＪＳＯＮ形式を用いたが、ＸＭＬ等、ＪＳＯＮ以外の形式を用いても良い。
　第３の特徴として、イベント・表示アプリケーション１２０はイベント・表示フレームワーク１６０を用いて開発・実行される。イベント・表示フレームワーク１６０は、イベント・表示ライブラリ１５０やＤＯＭ操作ライブラリ１４０のＡＰＩを纏めてよく利用される一連の処理として提供する。例えば、地図サービス（Ｍａｐ）では、地図サービス（Ｍａｐ）用のイベント・表示ライブラリ１５０のうち、描画を行うＡＰＩが使われるとすると、イベント・表示フレームワーク１６０では、描画を行うための一連のＡＰＩを纏めたＡＰＩ（ｄｒａｗ）を提供することができる。同様に、店舗検索サービス（Ｓｈｏｐ）では、店舗一覧を取得するＡＰＩ（ｇｅｔＬｉｓｔ）に続いて、結果を表示するＡＰＩ（ｓｈｏｗＬｉｓｔ）を利用するパターンが一般的であるとすると、イベント・表示フレームワーク１６０では、これら一連の処理を纏めたＡＰＩ（ｌｉｓｔ）を提供することができる。ただし、ｇｅｔＬｉｓｔは情報操作ライブラリ２５０のＡＰＩであり、実際にはプロキシサーバプログラム２１０で実行されるため、イベント・表示フレームワーク１６０は、ｇｅｔＬｉｓｔの実体ではなく、実体がプロキシサーバプログラム２１０上に格納されたｇｅｔＬｉｓｔという名前を記述する。同様に、天気予報サービス（Ｗｅａｔｈｅｒ）では、天気を取得するＡＰＩ（ｇｅｔＷｅａｔｈｅｒ）に続いて、結果を表示するＡＰＩ（ｓｈｏｗＷｅａｔｈｅｒ）を利用するパターンが一般的であるとすると、イベント・表示フレームワーク１６０では、これら一連の処理を纏めたＡＰＩ（ｗｅａｔｈｅｒ）を提供することができる。ただし、ｇｅｔＷｅａｔｈｅｒは情報操作ライブラリ２５０のＡＰＩであり、実際にはプロキシサーバプログラム２１０で実行されるため、イベント・表示フレームワーク１６０は、ｇｅｔＷｅａｔｈｅｒの実体ではなく、実体がプロキシサーバプログラム２１０上に格納されたｇｅｔＷｅａｔｈｅｒという名前を記述する。イベント・表示フレームワーク１６０はまた、イベント・表示アプリケーション１２０実行時に、各サービスの情報操作ライブラリ２５０の実行に必要な情報を正規化データ４００に集約しプロキシサーバプログラム２１０に送信したり、プロキシサーバプログラム２１０から正規化データ５００を受信する処理を隠蔽する。以上により、アプリケーション開発者は、イベント・表示フレームワーク１６０を用いることで、容易にイベント・表示アプリケーション１２０を開発することができる。
　図５に、イベント・表示アプリケーション１２０の画面例を示す。これは、地図サービスと天気予報サービス、店舗検索サービスのマッシュアップの例であり、地図の表示地帯の天気予報と、地図上にマーキングされた店舗の情報を表示するアプリケーションである。また、地図上の左上部には、ズーム変更のためのツール（以下、ズーム変更バー）が設置されており、これをマウスクリックすることで、地図のズームを変更することができる。本実施形態では、マウスクリックにより地図のズームを変更しようとすると、「ｚｏｏｍ」イベントが発生する。
　図６に、このイベント・表示アプリケーションのソースコードのうち、イベント処理に係わる部分の例を示す。図６に示す例では、何らかのサービスにおいて何らかのイベント（ｅｖｅｎｔ）が発生した場合に、画面上の部品（ｔａｒｇｅｔ）に対して実行されるアクション（ａｃｔｉｏｎ）がタグ形式で記述されている。ここでは、地図サービス（Ｍａｐ）のｚｏｏｍ（ズーム変更）イベントに対して、３つのタグを記述している。１つ目は、地図サービスの部品（ＭａｐＷｉｄｇｅｔ）に対し、再描画（ｄｒａｗ）の実行を指示するものである。２つ目は、店舗検索サービスの表示部品（ＳｈｏｐＷｉｄｇｅｔ）に対し、店舗一覧を取得し表示するＡＰＩ（ｌｉｓｔ）の実行を指示するものである。３つ目は、天気予報サービスの表示部品（ＷｅａｔｈｅｒＷｉｄｇｅｔ）に対し、天気を取得し表示するＡＰＩ（ｗｅａｔｈｅｒ）の実行を指示するものである。ここでは、イベント・表示フレームワーク１６０に関して、アクションをタグ形式で提供する例を示したが、アクションを例えばＪａｖａＳｃｒｉｐｔライブラリとして提供するなどしてもよい。
　なお、ここでは、イベントの種類として、ｚｏｏｍ（ズーム変更）の例を挙げた。本実施形態で扱うイベントの種類としては、第１に、Ｗ３Ｃ　ＤＯＭ　Ｌｅｖｅｌ２　Ｅｖｅｎｔｓ　Ｓｐｅｃｉｆｉｃａｔｉｏｎが規定する、クライアントブラウザ１１０やユーザアプリケーション１４０のＨＴＭＬ要素上に発生する初期化やマウスクリック等のイベントがある。また、地図サービスにおいて地図オブジェクト上で発生するズーム変更等のイベントといった、サービス利用時に生成される、オブジェクトに対するイベントがある。さらに、ＨＴＭＬ５　ＷｅｂＳｏｃｋｅｔが規定する、リモート環境で発生したイベントをローカルで検知するような仕組みも、本実施形態で扱うイベントの種類に含まれる。
　同様に、データ統合アプリケーション２２０は、データ統合フレームワーク２６０を用いて開発・実行される。データ統合フレームワーク２６０は、情報操作ライブラリ２５０のデータ形式や通信方式に係わる部分を隠蔽し、データ形式や通信方式の差異を吸収する。データ統合アプリケーション２２０は、データ統合フレームワーク２５０を用いることで、例えば、ＸＭＬ形式データの店舗検索サービス（Ｓｈｏｐ）と、ＪＳＯＮ形式データの天気予報サービス（Ｗｅａｔｈｅｒ）に、同じインタフェースでアクセスできるとともに、戻り値を同一の形式で受信できる。本実施形態では、店舗検索サービス（Ｓｈｏｐ）がＸＭＬで記述され、天気予報サービス（Ｗｅａｔｈｅｒ）がＪＳＯＮ形式で記述されているとする。また、クライアントブラウザ１１０から正規化データ４００を受信したり、各サービスの実行結果を正規化データ５００に集約しクライアントブラウザ１１０に送信する処理を隠蔽する。以上により、開発者は、データ統合フレームワーク２６０を用いることで、容易にデータ統合アプリケーション２２０を開発できる。
　図７は、イベント・表示アプリケーション１２０実行時に、イベント・表示フレームワーク１６０が実施する処理の例を説明する図である。図８は、データ統合アプリケーション２２０実行時に、データ統合フレームワーク２６０が実施する処理の例を説明する図である。以下、図７～図８を用いて、ユーザアプリケーション実行時に実施される処理を説明する。
　まず、クライアントブラウザ１１０がプロキシサーバプログラム２１０にアクセスすると、イベント・表示フレームワーク１６０とイベント・表示アプリケーション１２０とイベント・表示ライブラリ１５０の実体が、クライアントブラウザ１１０にダウンロードされ、イベント・表示アプリケーション１２０の初期画面がクライアントブラウザ１１０に表示される。
　次いで、イベント・表示フレームワーク１６０は、イベント発生の待機状態となる（ステップ７０１０）。
　アプリケーションのユーザが、地図上のズーム変更バーをクリックすると、イベント・表示フレームワーク１６０により、イベント‘ｚｏｏｍ（ズーム変更）’の発生が検知される（ステップ７０２０）。イベント・表示フレームワーク１６０は、イベントに対して指定されたアクションの内部に隠蔽された情報操作ライブラリ２５０のＡＰＩへの参照を取得する（ステップ７０３０）。例えば、図６に示すソースコードの例では、ｚｏｏｍに対して３つのアクション‘ｄｒａｗ’、‘ｌｉｓｔ’、‘ｗｅａｔｈｅｒ’が指定されている。イベント・表示フレームワーク１６０は、これらＡＰＩ内部に隠蔽された情報操作ライブラリ２５０のＡＰＩであるｇｅｔＬｉｓｔとｇｅｔＷｅａｔｈｅｒへの参照を、イベント表示・フレームワーク１６０自身の内部の記述から取得する。
　イベント・表示フレームワーク１６０は、ステップ７０３０で取得した情報操作ライブラリ２５０のＡＰＩの実行に必要な情報を集約した正規化データ４００を作成する。本実施形態では、正規化データ４００は上述のようにＪＳＯＮ形式で作成する（ステップ７０４０）。例えば、図３に示す例では、正規化データ４００は、店舗検索サービス（Ｓｈｏｐ）のｇｅｔＬｉｓｔの実行に必要な引数としてｌａｔ（緯度）、ｌｎｇ（経度）の値を、天気予報サービス（Ｗｅａｔｈｅｒ）のｇｅｔＷｅａｔｈｅｒの実行に必要な引数としてｌａｔ（緯度）、ｌｎｇ（経度）の値を含むＪＳＯＮ形式データとして作成されている。ｌａｔ（緯度）、ｌｎｇ（経度）は、地図サービスの提供するＡＰＩを用いて、地図上の任意の位置に対して取得される。ここでは、該当ＡＰＩを用いて地図の中心のｌａｔ（緯度）、ｌｎｇ（経度）を取得するロジックをイベント・表示アプリケーション１２０で実装しておくことで、ｌａｔ（緯度）、ｌｎｇ（経度）を取得する。
　イベント・表示フレームワーク１６０は、通信装置１０４０を介して、ステップ７０４０で作成した正規化データ４００をデータ統合アプリケーション２２０に送信し（ステップ７０５０）、待機状態となる（ステップ７０６０）。
　データ統合アプリケーション２２０はデータ統合フレームワーク２６０が提供する機能を利用して開発されており、データ統合アプリケーション２２０が通信装置２０４０を介して正規化データ４００を受信すると、データ統合フレームワーク２６０の機能により、正規化データ４００を解析し、実行すべき情報操作ライブラリのＡＰＩと必要な引数とを取得する（ステップ８０１０）。ここでは、取得される引数は、店舗検索サービス（Ｓｈｏｐ）のｇｅｔＬｉｓｔと、その実行に必要な引数ｌａｔ（緯度）、ｌｎｇ（経度）の値を、天気予報サービス（Ｗｅａｔｈｅｒ）のｇｅｔＷｅａｔｈｅｒと、その実行に必要な引数ｌａｔ（緯度）、ｌｎｇ（経度）の値である（ステップ８０１０）。
　データ統合フレームワーク２６０は、通信装置２０４０を介して、店舗検索サービス（Ｓｈｏｐ）と天気予報サービス（Ｗｅａｔｈｅｒ）のサービス提供サーバ３００、３２０に接続し、ステップ８０１０で取得した情報を用いて、それぞれのサービスのＡＰＩの実行を要求し、結果を待ち合わせる（ステップ８０２０）。ここでは、ｇｅｔＬｉｓｔとｇｅｔＷｅａｔｈｅｒにそれぞれｌａｔ（緯度）、ｌｎｇ（経度）の値を与えて実行する。また、データ統合フレームワーク２６０は、サービス提供サーバに対して実行を要求するときに、サービスの種類に応じて、当該サービスを実行するサービス提供サーバと、その要求のデータ形式を指定する。図１０に、その指定方法を定める変換表を示す。データ統合フレームワーク２６０は、図１０の変換表を参照して、店舗検索サービス（Ｓｈｏｐ）を利用する場合はデータ形式としてＸＭＬ形式を指定してサービス提供サーバ１に、天気予報サービス（Ｗｅａｔｈｅｒ）を利用する場合はデータ形式としてＪＳＯＮ形式を指定してサービス提供サーバ２にデータ送信すればよいことが分かる。従って、データ統合フレームワーク２６０は、データ形式にＸＭＬを指定してサービス提供サーバ１にｇｅｔＬｉｓｔの実行を要求する一方で、データ形式にＪＳＯＮを指定してサービス提供サーバ２にｇｅｔＷｅａｔｈｅｒの実行を要求する。
　データ統合フレームワーク２６０は、通信装置２０４０を介して、店舗検索サービス（Ｓｈｏｐ）と天気予報サービス（Ｗｅａｔｈｅｒ）のサービス提供サーバ３００、３２０から、ＡＰＩの実行結果を受信し、バッファ等に一時記憶する（ステップ８０３０）。ここでは、ステップ８０２０で指定したように、ｇｅｔＬｉｓｔの実行結果をＸＭＬ形式データで、ｇｅｔＷｅａｔｈｅｒの実行結果をＪＳＯＮ形式データで受信する。
　データ統合フレームワーク２６０は、上記実行結果が全て揃った段階で、クライアントブラウザ１１０に結果を返すための正規化データ５００を作成する（ステップ８０４０）。ここでは、ｇｅｔＬｉｓｔの実行結果であるＸＭＬ形式データと、ｇｅｔＷｅａｔｈｅｒの実行結果であるＪＳＯＮ形式データとをＪＳＯＮ形式の１つのメッセージに集約する。その際、正規化データ５００をＪＳＯＮ形式で記述する必要があるため、天気予報サービス（Ｗｅａｔｈｅｒ）のＡＰＩであるｇｅｔＷｅａｔｈｅｒの実行結果の変換は不要だが、店舗検索サービス（Ｓｈｏｐ）のＡＰＩであるｇｅｔＷｅａｔｈｅｒの実行結果はＪＳＯＮ形式への変換が必要である。従って、データ統合フレームワーク２６０は、ｇｅｔＷｅａｔｈｅｒの実行結果を変換ライブラリなどを利用してＪＳＯＮ形式に変換し、ｇｅｔＷｅａｔｈｅｒの実行結果にマージする。
　データ統合フレームワーク２６０は、通信装置２０４０を介して、ステップ８０４０で作成した正規化データ５００をイベント・表示アプリケーション１２０に送信する（ステップ８０５０）。
　イベント・表示アプリケーション１２０はイベント・表示フレームワーク１６０が提供する機能を利用して開発されており、イベント・表示アプリケーション１２０が通信装置１０４０を介して正規化データ５００を受信すると、イベント・表示フレームワーク１６０の機能により、正規化データ５００を解析して実行結果を取得する（ステップ７０７０）。ここでは、ｇｅｔＬｉｓｔとｇｅｔＷｅａｔｈｅｒの実行結果をそれぞれＪＳＯＮ形式データで取得する。
　イベント・表示フレームワーク１６０は、イベントに対して指定されたアクションの内部に隠蔽されたイベント・表示ライブラリ１５０のＡＰＩを実行する（ステップ７０８０）。例えば、図６に示すソースコードの例では、ｚｏｏｍに対して３つのアクション‘ｄｒａｗ’、‘ｌｉｓｔ’、‘ｗｅａｔｈｅｒ’が指定されており、イベント・表示ライブラリ１５０のＡＰＩとして、‘ｌｉｓｔ’内部でｇｅｔＬｉｓｔが、‘ｗｅａｔｈｅｒ’内部でｇｅｔＷｅａｔｈｅｒが指定されている。イベント・表示フレームワーク１６０は、地図を再描画するとともに、ステップ７０７０で取得した実行結果を、ｇｅｔＬｉｓｔとｇｅｔＷｅａｔｈｅｒを用いて再表示する（ステップ７０８０）。
　図９は、クライアント・コンピュータとプロキシサーバ間で実行される処理を示すシーケンス図である。クライアントコンピュータ１００上は、イベントが発生すると、正規化データを作成しプロキシサーバ２００に送信する。プロキシサーバは正規化データを解析し、複数のサービス提供サーバ３００～３２０に対してサービスの実行要求を発行し、結果を待ち合わせる。プロキシサーバ２００は結果を待ち合わせ、全ての結果を集約した正規化データを作成し、クライアントコンピュータ１００に送信する。クライアントコンピュータ１００は、表示ライブラリを用いて、実行結果の表示を行う。本実施形態では、プロキシサーバプログラム２１０を設け、情報操作ライブラリ２５０をプロキシサーバプログラム２１０上で実行することで、接続がクライアントブラウザ１１０とプロキシサーバプログラム２１０の間の１つの接続に限定される。また、実施に先駆けてイベント・表示ライブラリ１５０の実体がローカル環境にダウンロードされ、各サービス提供サーバ３００、３１０、３２０から完全に分離される。クライアントブラウザ１１０は、イベントや表示の処理に関しては、ダウンロードしたイベント・表示ライブラリ１５０を利用し、各サービス提供サーバ３００、３１０、３２０へは接続しない。
　本実施形態によれば、情報取得に関して、マッシュアップ対象のサービス数が増加しても、クライアントブラウザはプロキシサーバプログラムとの間に１つの接続を有するだけでよく、ブラウザの負荷が極端に増加することを回避することができる。また、イベントの検出およびデータの表示に関して、ダウンロードしたライブラリを利用するため、各サービス提供プロバイダへの接続が発生せず、ブラウザの負荷を低減することができる。
　また、本実施形態によれば、イベント・表示フレームワークとデータ統合フレームワークを利用することで、煩雑なＤＯＭ操作、データ形式および通信方式の差異が隠蔽され、それらを意識しない開発が可能になるとともに、イベント・表示に係わるアプリケーション開発と情報操作に係わるアプリケーション開発を分離できる。これにより、容易なアプリケーション開発が可能となる。
　他の実施形態として、プロキシサーバプログラムが、最初にクライアントブラウザから接続があった際に、各サービスの情報操作ライブラリを実行した結果をクライアントブラウザに返すとともに、キャッシュに保存してもよい。それ以降の一定時間内に他のクライアントブラウザから接続があった場合は、その正規化メッセージを解析し、メッセージに記述される情報操作ライブラリや引数等を調査し、同一のユーザアプリケーションが利用されていると判断すれば、各サービスの情報操作ライブラリを実行せずに、保存したキャッシュを返す。これにより、不特定多数のユーザが利用するユーザアプリケーションの場合でも、最初のクライアントブラウザからの接続時のみ各サービスの情報操作ライブラリを実行し、それ以降の接続時にはキャッシュを利用することができる。これにより、プロキシサーバ自体の負荷を低減できるとともに、他のクライアントブラウザへの応答に要する時間を短縮することが可能となる。
１１０…クライアントブラウザ、１２０…イベント・表示アプリケーション、１３０…ＪａｖａＳｃｒｉｐｔエンジン、１４０…ＤＯＭ操作ライブラリ、１５０…イベント・表示ライブラリ、１６０…イベント・表示フレームワーク、２１０…プロキシサーバプログラム、２２０…データ統合アプリケーション、２３０…ＪａｖａＳｃｒｉｐｔエンジン、２４０…ＤＯＭ操作ライブラリ、２５０…情報操作ライブラリ、２６０…データ統合フレームワーク、３００，３１、３２０…サービス提供サーバ

Claims (12)

  1. 　ブラウザを有するクライアント・コンピュータとプロキシ・サーバとからなるシステムであって、
    　前記ブラウザは、前記ブラウザ上で発生するイベントに対する、画面表示ライブラリと情報操作の名前とを記述したイベント・表示フレームワークを備え、
    　前記プロキシ・サーバは、前記情報操作を実行する外部のサービス提供サーバに前記情報操作の実行を要求するデータ統合フレームワークを備え、
    　前記イベント・表示フレームワークは、前記ブラウザを介したユーザからの入力により発生したイベントを検出すると、前記イベントに対応する複数の情報操作を実行するために、前記複数の情報操作の各々について必要な情報操作の名前と引数を取得し、前記複数の情報操作の各々について取得した情報操作の名前と引数を１つの第１のメッセージに纏め、前記第１のメッセージを前記データ統合フレームワークに送信し、
    　前記データ統合フレームワークは、
    　　前記第１のメッセージを受信し、
    　　前記複数の情報操作の各々について、
    　　　対応する情報操作の名前と引数を前記第１のメッセージから取得して前記サービス提供サーバに送信し、
    　　　前記サービス提供サーバから前記複数の情報操作各々についての実行結果を受け取り、
    　　前記複数の情報操作の各々について取得した実行結果を１つの第２のメッセージに纏めて前記イベント・表示フレームワークに送信し、
    　前記イベント・表示フレームワークは、前記第２のメッセージから複数の実行結果を取り出し、前記イベントに対応する前記画面表示ライブラリを用いて前記複数の実行結果を前記ブラウザに表示する
    　ことを特徴とするシステム。
  2. 　請求項１に記載のシステムにおいて、
    　前記データ統合フレームワークは、
    　　情報操作の名前と、前記情報操作を実行する前記サービス提供サーバに前記情報操作の名前および引数を送信する際のデータ形式とを対応付ける第１の変換表を備え、
    　　前記複数の情報操作の各々について、
    　　　前記第１の変換表から前記情報操作の名前に対応したデータ形式を取得し、
    　　　前記情報操作の名前と引数を前記データ形式で前記サービス提供サーバに送信すること
    　を特徴とするシステム。
  3. 　請求項２に記載のシステムにおいて、
    　サービス提供サーバが複数存在し、
    　前記第１の変換表はさらに、前記情報操作の名前ごとに、前記情報操作を実行するサービス提供サーバの名前を備え、
    　前記データ統合フレームワークは、
    　　前記複数の情報操作の各々について、
    　　　前記第１の変換表から前記情報操作の名前に対応したデータ形式と前記情報操作を実行するサービス提供サーバの名前とを取得し、
    　　　前記情報操作の名前と引数を、前記サービス提供サーバの名前に対応する前記サービス提供サーバに前記データ形式で送信すること
    　を特徴とするシステム。
  4. 　前記第１のメッセージおよび第２のメッセージは、前記イベントに対する情報操作および引数を一纏めにしたＡＰＩを列挙する形で正規化されたメッセージであることを特徴とする請求項１乃至３に記載のシステム。
  5. 　前記第１のメッセージおよび第２のメッセージはＪＳＯＮ形式であることを特徴とする請求項１乃至４に記載のシステム。
  6. 　前記第１のメッセージおよび第２のメッセージはＸＭＬ形式であることを特徴とする請求項１乃至４に記載のシステム。
  7. 　ブラウザを有するクライアント・コンピュータとプロキシ・サーバとからなるシステムの動作方法であって、
    　前記ブラウザは、前記ブラウザ上で発生するイベントに対する、画面表示ライブラリと情報操作の名前とを記述したイベント・表示フレームワークを備え、
    　前記プロキシ・サーバは、前記情報操作を実行する外部のサービス提供サーバに前記情報操作の実行を要求するデータ統合フレームワークを備え、
    　前記方法は、
    　前記イベント・表示フレームワークが、前記ブラウザを介したユーザからの入力により発生したイベントを検出すると、前記イベントに対応する複数の情報操作を実行するために、前記複数の情報操作の各々について必要な情報操作の名前と引数を取得し、前記複数の情報操作の各々について取得した情報操作の名前と引数を１つの第１のメッセージに纏め、前記第１のメッセージを前記データ統合フレームワークに送信するステップと、
    　前記データ統合フレームワークが、
    　　前記第１のメッセージを受信し、
    　　前記複数の情報操作の各々について、
    　　　対応する情報操作の名前と引数を前記第１のメッセージから取得して前記サービス提供サーバに送信し、
    　　　前記サービス提供サーバから前記複数の情報操作各々についての実行結果を受け取り、
    　　前記複数の情報操作の各々について取得した実行結果を１つの第２のメッセージに纏めて前記イベント・表示フレームワークに送信するステップと、
    　前記イベント・表示フレームワークが、前記第２のメッセージから複数の実行結果を取り出し、前記イベントに対応する前記画面表示ライブラリを用いて前記複数の実行結果を前記ブラウザに表示するステップと、
    　を含むことを特徴とする方法。
  8. 　請求項７に記載の方法において、
    　前記データ統合フレームワークが、
    　　情報操作の名前と、前記情報操作を実行する前記サービス提供サーバに前記情報操作の名前および引数を送信する際のデータ形式とを対応付ける第１の変換表を備え、
    　　前記複数の情報操作の各々について、
    　　　前記第１の変換表から前記情報操作の名前に対応したデータ形式を取得し、
    　　　前記情報操作の名前と引数を前記データ形式で前記サービス提供サーバに送信するステップ
    　をさらに含むこと特徴とする方法。
  9. 　請求項８に記載の方法において、
    　サービス提供サーバが複数存在し、
    　前記第１の変換表はさらに、前記情報操作の名前ごとに、前記情報操作を実行するサービス提供サーバの名前を備え、
    　前記データ統合フレームワークが、
    　　前記複数の情報操作の各々について、
    　　　前記第１の変換表から前記情報操作の名前に対応したデータ形式と前記情報操作を実行するサービス提供サーバの名前とを取得し、
    　　　前記情報操作の名前と引数を、前記サービス提供サーバの名前に対応する前記サービス提供サーバに前記データ形式で送信するステップ
    　をさらに含むことを特徴とする方法。
  10. 　前記第１のメッセージおよび第２のメッセージは、前記イベントに対する情報操作および引数を一纏めにしたＡＰＩを列挙する形で正規化されたメッセージであることを特徴とする請求項７乃至９に記載の方法。
  11. 　前記第１のメッセージおよび第２のメッセージはＪＳＯＮ形式であることを特徴とする請求項７乃至１０に記載の方法。
  12. 　前記第１のメッセージおよび第２のメッセージはＸＭＬ形式であることを特徴とする請求項７乃至１０に記載の方法。
PCT/JP2010/006577 2010-11-10 2010-11-10 マッシュアップ・アプリケーションの動作方法およびシステム WO2012063282A1 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
PCT/JP2010/006577 WO2012063282A1 (ja) 2010-11-10 2010-11-10 マッシュアップ・アプリケーションの動作方法およびシステム

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2010/006577 WO2012063282A1 (ja) 2010-11-10 2010-11-10 マッシュアップ・アプリケーションの動作方法およびシステム

Publications (1)

Publication Number Publication Date
WO2012063282A1 true WO2012063282A1 (ja) 2012-05-18

Family

ID=46050467

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2010/006577 WO2012063282A1 (ja) 2010-11-10 2010-11-10 マッシュアップ・アプリケーションの動作方法およびシステム

Country Status (1)

Country Link
WO (1) WO2012063282A1 (ja)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2014222455A (ja) * 2013-05-14 2014-11-27 日本電気株式会社 通信システム、プロキシサーバ、通信方法およびプログラム
JP2017504092A (ja) * 2013-11-11 2017-02-02 アダロム・インコーポレイテッド クラウド・サービス・セキュリティ・ブローカおよびプロキシ
US10324702B2 (en) 2014-09-12 2019-06-18 Microsoft Israel Research And Development (2002) Ltd. Cloud suffix proxy and a method thereof
CN114979240A (zh) * 2022-07-26 2022-08-30 杭州奇思妙行网络科技有限公司 一种分布式WebSocket接入系统及方法

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2004054804A (ja) * 2002-07-24 2004-02-19 Nec Corp 監視サーバ装置、監視システム及びそれらに用いるイベント通知方法並びにそのプログラム
JP2005508046A (ja) * 2001-10-31 2005-03-24 ヒューレット・パッカード・カンパニー ネットワークページに自動的にアクセスするシステムおよび方法
JP2005107884A (ja) * 2003-09-30 2005-04-21 Hitachi Ltd インタフェース定義記述を生成する方法、およびインタフェース定義記述生成装置

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2005508046A (ja) * 2001-10-31 2005-03-24 ヒューレット・パッカード・カンパニー ネットワークページに自動的にアクセスするシステムおよび方法
JP2004054804A (ja) * 2002-07-24 2004-02-19 Nec Corp 監視サーバ装置、監視システム及びそれらに用いるイベント通知方法並びにそのプログラム
JP2005107884A (ja) * 2003-09-30 2005-04-21 Hitachi Ltd インタフェース定義記述を生成する方法、およびインタフェース定義記述生成装置

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2014222455A (ja) * 2013-05-14 2014-11-27 日本電気株式会社 通信システム、プロキシサーバ、通信方法およびプログラム
JP2017504092A (ja) * 2013-11-11 2017-02-02 アダロム・インコーポレイテッド クラウド・サービス・セキュリティ・ブローカおよびプロキシ
US10324702B2 (en) 2014-09-12 2019-06-18 Microsoft Israel Research And Development (2002) Ltd. Cloud suffix proxy and a method thereof
US10642600B2 (en) 2014-09-12 2020-05-05 Microsoft Technology Licensing, Llc. Cloud suffix proxy and a method thereof
CN114979240A (zh) * 2022-07-26 2022-08-30 杭州奇思妙行网络科技有限公司 一种分布式WebSocket接入系统及方法

Similar Documents

Publication Publication Date Title
US8965864B2 (en) Method and system for efficient execution and rendering of client/server interactive applications
US9442687B2 (en) Method and apparatus for moving web object based on intent
US9130975B2 (en) Generation of macros
US8312450B2 (en) Widgetizing a web-based application
US8001463B2 (en) Web page communications using parameters and events
US8239839B2 (en) Asynchrony debugging using web services interface
US7698256B1 (en) History support for stateless Javascript Web client
US20090271690A1 (en) Handling cross-domain web service calls
US20100161713A1 (en) Method and system for personalizing a desktop widget
EP2339465B1 (en) Location independent execution of user interface operations
US7801996B2 (en) Systems and methods for providing a local client proxy
US20070288508A1 (en) Computer software development methods and systems
EP2369480A2 (en) Mashup infrastructure with learning mechanism
US8621092B2 (en) Remote portlet consumer with enhanced resource URL processing
CA2664161A1 (en) Common component framework
US7685114B2 (en) Systems and methods for mapping text
US20090025011A1 (en) Inter-process communication at a mobile device
US20140026067A1 (en) Method and apparatus for processing movement of web object based on intent
WO2012063282A1 (ja) マッシュアップ・アプリケーションの動作方法およびシステム
US9400588B2 (en) Supporting display of context menus in both cascaded and overlapping styles
JP5151696B2 (ja) ユニフォームリソースロケータ情報を書き換えるプログラム
US7849472B1 (en) System for instrumenting resources utilizing WS-management resource MBean wrappers for JAXB beans
US10142446B2 (en) Dialog server
US20110295966A1 (en) Methods, systems, and computer program products for processing a combined command response based on a markup element
US20130111343A1 (en) Load balancing of user interface script execution

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 10859529

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 10859529

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: JP