WO2006040991A1 - Dispositif de terminal, dispositif de serveur et systeme de mise a disposition de service web - Google Patents

Dispositif de terminal, dispositif de serveur et systeme de mise a disposition de service web Download PDF

Info

Publication number
WO2006040991A1
WO2006040991A1 PCT/JP2005/018512 JP2005018512W WO2006040991A1 WO 2006040991 A1 WO2006040991 A1 WO 2006040991A1 JP 2005018512 W JP2005018512 W JP 2005018512W WO 2006040991 A1 WO2006040991 A1 WO 2006040991A1
Authority
WO
WIPO (PCT)
Prior art keywords
description file
service
server device
api call
terminal device
Prior art date
Application number
PCT/JP2005/018512
Other languages
English (en)
Japanese (ja)
Inventor
Tetsuya Matsuyama
Soichi Nitta
Masafumi Hirata
Original Assignee
Sharp Kabushiki Kaisha
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 Sharp Kabushiki Kaisha filed Critical Sharp Kabushiki Kaisha
Priority to JP2006540900A priority Critical patent/JPWO2006040991A1/ja
Publication of WO2006040991A1 publication Critical patent/WO2006040991A1/fr

Links

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/50—Network services
    • H04L67/51—Discovery or management thereof, e.g. service location protocol [SLP] or web services

Definitions

  • Terminal device server device, and Web service providing system
  • the present invention relates to a terminal device such as a mobile phone, and more particularly to a technique for using the terminal device as a Web service service client.
  • FIG. 19 shows a general Web service invocation method.
  • the Web service server publishes an interface 1901 as shown in the example in the figure, and it is assumed that a Web service call 1902 as shown in the figure is made from such a Web service client to the Web service server.
  • Figure 20 shows a description example of a WSDL file for calling a Web service.
  • API Application Programming Interface
  • FIG. 22 shows a case where a stub 'class is used for invoking a Web service.
  • the Web service client 2200 has an application 2201, a stub class 2202, and a library 2203 that implements JSR172.
  • the application 2201 calls the library 2203 through the stub 'class 2202 and sends a SOAP message 2204 to the Web service server 2205.
  • Figure 23 shows an example of a 'stub' class. As shown in Fig. 23, the stub 'class hides the API calls necessary for calling the web service internally, so the developer of application 2201 handles the normal classes as shown in Fig. 24. If the stub 'class is handled as in the case, the Web service can be called without being aware of the detailed contents of the SOAP message 2204.
  • Patent Document 1 discloses a technique for providing a proxy server between a server and a terminal and using a Web service from a terminal having only a normal Web browser function without a necessary implementation as a Web service client. ing.
  • a predetermined keyword is input on the Web page from the terminal
  • a specific Web service that matches the user's wishes is extracted, and related information is sent to the proxy server device.
  • the proxy server device creates a dedicated API based on the protocol described in the WSDL document, and then sends it to the server device that provides the Web service.
  • a service request is sent on behalf of the terminal device.
  • the service is reported by e-mail to the proxy server device terminal.
  • Patent Document 1 Japanese Patent Laid-Open No. 2004-30360
  • Non-Patent Document 1 JAVA WORLD March 2004, page 166
  • MIDP Mobile Information Device Profile
  • MIDlet Mobile Information Device Profile
  • a terminal that supports MIDP can download and install the MIDlet via the network and run it on the terminal.
  • MIDP it is necessary to support functions such as user-defined class loader reflection, so classes cannot be added dynamically.
  • a new MIDlet containing the added class must be installed. Therefore, even when creating an application that calls various Web services, it is not possible to dynamically add stub classes corresponding to each Web service. It is necessary to newly install the MIDlet including the stub class corresponding to the Web service.
  • An object of the present invention is to enable dynamic connection to a plurality of Web services on a terminal with few resources such as a mobile phone even in an environment where a class cannot be dynamically added like MIDP.
  • the terminal device when a terminal device calls a web service from a web service server, the terminal device calls the web service rather than downloading and installing a stub 'class corresponding to the web service. Download the API call procedure description file that enumerates the series of API call procedures required for this. Based on the API call procedure description file, the terminal device can use the Web service by simply calling the API in order. Therefore, the terminal does not need to analyze the WSDL file in the same way as when using the stub 'class, and it is not necessary to add the class to the MIDlet. Therefore, the class can be added dynamically like MIDP. Even in the environment, it is possible to dynamically connect to multiple Web services with few resources. [0013] According to the present invention, even in an environment where a class cannot be added dynamically, such as MIDP, it is possible to dynamically connect to a plurality of Web services on a terminal with few resources such as a mobile phone.
  • FIG. 1 is a schematic diagram of a Web service system according to the present invention.
  • FIG. 2 is a configuration diagram of a first example of a terminal device and a server device according to the present invention.
  • FIG. 3 is a diagram illustrating a terminal device according to the present invention in comparison with the prior art.
  • FIG. 4 is a diagram showing a flow of processing in the terminal device according to the present invention.
  • FIG. 5 is a diagram showing a flow of processing in the server device according to the present invention.
  • FIG. 6 shows an example of an API call procedure description file.
  • FIG. 7 is a diagram for explaining a qname element in an API call procedure description file.
  • FIG. 8 is a diagram for explaining an element element in an API call procedure description file.
  • FIG. 9 is a diagram for explaining a complextype element in an API call procedure description file.
  • FIG. 10 is a diagram for explaining an operation element in an API call procedure description file.
  • FIG. 11 is a diagram for explaining the setproperty element in the API call procedure description file.
  • FIG. 12 is a diagram showing an example of storing objects in a hash table.
  • FIG. 13 is a diagram showing an example of input parameters.
  • FIG. 14 is a diagram showing a second example of input parameters (parameters are two-dimensional).
  • FIG. 15 is a diagram showing an example of a service identifier correspondence table storage unit.
  • FIG. 16 is a diagram showing a second example of a service identifier correspondence table storage unit.
  • FIG. 17 is a configuration diagram of a second example of a terminal device and a server device according to the present invention.
  • FIG. 18 is a diagram showing an example of input parameters in the second example of the terminal device and the server device according to the present invention.
  • FIG. 19 is a diagram for explaining an example of calling a conventional general Web service.
  • FIG. 20 is a diagram showing an example of a WSDL file.
  • FIG. 21 is a diagram showing an example of a terminal-side API call in a conventional general Web service call.
  • FIG. 22 is a configuration diagram using a stub 'class for calling a Web service.
  • FIG. 23 is a diagram showing an example implementation of a stub class.
  • FIG. 24 is a diagram showing an example of invoking a Web service using a stub 'class.
  • FIG. 1 shows an overall view of a Web service system according to the present invention.
  • the web service system 100 of this example generates and provides a terminal device 10 such as a mobile phone serving as a web service client and an API call procedure description file describing an application programming interface (API) call procedure.
  • a server device 20 and a Web service server 30 that stores and provides Web services are connected to each other via a communication network 40 such as the Internet.
  • the terminal device 10 transmits a service identifier that identifies a Web service to be used to the server device 20.
  • the server device 20 generates an API call procedure description file based on the service identifier and transmits it to the terminal device 10.
  • the terminal device 10 calls the API based on the API call procedure description file and calls the Web service on the Web service server 30.
  • the Web service server 30 provides the called Web service to the terminal device 10.
  • the terminal device 10 includes an input / output unit 101, an application 102, an API call procedure description file storage unit 103, an API call procedure description file processing unit 104, a reception unit 105, and a transmission unit 106.
  • the input / output unit 101 performs parameter input / output processing with the application 102 using the Web service.
  • the input parameter 121 input from the application 102 by the input / output unit 101 includes a service identifier 122 that identifies a Web service to be used, a request parameter 123 that is a parameter for sending a request to the Web service, and a record from the Web service. It includes three parameters, response parameter 124, which is a parameter when receiving a response.
  • An example of the input parameter 121 will be described later with reference to FIGS.
  • the API call procedure description file storage unit 103 stores the API call procedure description file 225 received from the server device 20 in association with the service identifier 122. This serves as a cache that prevents the same API call procedure description file 225 from being repeatedly received from the server device 20.
  • the API call procedure description file processing unit 104 uses the request parameter 123 and the response parameter 124 from the API call procedure description file 225 and the application 102 to actually call the Web service on the Web service server 30. . Details of this process will be described later.
  • the reception unit 105 is responsible for receiving the API call procedure description file 225 from the server device 20, and the transmission unit 106 is responsible for transmission of the service identifier 122 to the server device 20.
  • the server device 20 includes a service identifier correspondence table storage unit 201, a service interface description file acquisition unit 202, an API call procedure description file generation unit 203, a method identification unit 204, a reception unit 205, and a transmission unit 206.
  • the service identifier correspondence table storage unit 201 stores a service identifier that identifies a Web service and information associated therewith. Such information includes the service name, bind name, port name, operation name, argument name, and return value name necessary to specify the WSDL file acquisition source and the method to be called.
  • An example of the service identifier correspondence table storage unit 201 will be described later with reference to FIG. 15 and FIG.
  • the service interface description file acquisition unit 202 sends an appropriate WSDL file, that is, the service interface description file via the communication network 40 according to the WSDL file acquisition destination stored in the service identifier correspondence table storage unit 201. get.
  • the service interface description file is a service interface description file.
  • the file acquisition unit 202 itself may be stored in advance.
  • the method identification unit 204 corresponds to a plurality of methods described in the WSDL file based on the service name, node name, port name, operation name, argument name, and return value name associated with the service identifier. Identify the method to perform.
  • the API call procedure description file generation unit 203 generates an API call procedure description file 225 that describes an API procedure necessary to call the specified method. Details of this processing will be described later.
  • the receiving unit 205 is responsible for receiving the terminal device 10 service identifier 122, and the transmitting unit 206 is responsible for transmitting the API call procedure description file 225 to the terminal device 10.
  • the difference between the present invention and the prior art of FIG. 22 will be described.
  • the stub 'class 2202 since the stub 'class 2202 is used to connect to the web service, it was necessary to replace the stub' class 2202 to newly connect to another web service.
  • a function equivalent to the stub class 2202 is realized by the API call procedure description file 225 describing the API call procedure and the API call procedure description file processing unit 104 interpreting it. Therefore, even when newly connecting to another Web service, it is not necessary to replace the class file constituting the API call procedure description file processing unit 104.
  • the API call procedure description file 225 is downloaded from the server device 20 and replaced. It's okay.
  • step S401 the input / output unit 101 receives the input parameter 121 from the application 102 using the Web service.
  • step S402 it is determined whether or not the API call procedure description file 225 associated with the service identifier 122 included in the input parameter 121 is stored in the API call procedure description file storage unit 103. If it is stored, the processing after step S405 is performed based on the API call procedure description file 225. If not stored, a request for the API call procedure description file 225 is made to the server device 20 in step S403. That is, the transmission unit 106 transmits the service identifier 122 included in the input parameter 121 to the server device 20.
  • step S404 the receiving unit 105 receives the API call procedure description file 225 from the server device 20.
  • step S405 the request parameter 123 included in the input parameter 121 input from the application 102 is converted. Details of this process This will be described later.
  • step S406 the API call procedure description file processing unit 104 calls the API based on the API call procedure description file 225, and uses the converted parameters to the Web service server 30 as a Web service. Make a call.
  • step S407 the response parameter 124 is converted. That is, the return value obtained by calling the Web service is converted based on the response parameter 124. Details of step S405 and step S407 will be described later with reference to FIG. 13 and FIG.
  • step S 408 the converted parameter is output from the input / output unit 101 to the application 102.
  • step S501 the receiving unit 205 receives the service identifier 122 from the terminal device 10.
  • step S502 the service interface description file acquisition unit 202 searches the WSDL file acquisition destination associated with the received service identifier 122 using the service identifier correspondence table storage unit 20, and in accordance with the searched WSDL file acquisition destination, That is, the service interface description file is also acquired by the external force.
  • the service interface description file acquisition unit 202 itself may have a service interface description file.
  • step S503 the method specifying unit 204 uses a service name, a bind name, a port name, an operation name, an argument name, and a return value name associated with the service identifier 122 to generate a plurality of items described in the WSDL file. Identify the corresponding method from the methods.
  • step S504 the API call procedure description file generation unit 203 generates an API call procedure description file 225 that describes the API call procedure necessary for calling the specified method.
  • step S505 the transmission unit 206 transmits the generated API call procedure description file 225 to the terminal device 10.
  • the API call procedure description file processing unit 104 reads the API call procedure description file 225 shown in FIG. 6, and actually calls the API based on each child element of the service element. Examples of API calling rules are shown below in Figs. [0036]
  • Figure 7 shows how to write the API call procedure description file 225 when calling an API that generates a QName object that represents a qualified name consisting of a namespace name and a local name. .
  • the name attribute of the qname element generated by the name attribute of the qname element 701, the namespaceURI attribute representing the namespace name are the first argument of the constructor, and the localPart attribute representing the local name is the second argument of the constructor.
  • the API call procedure description file processing unit 104 that has read this qname element 701 calls the API described in 702. (1) (3) (8) (10) in Fig. 6 corresponds to (1) (3) (8) (10) in Fig. 21.
  • FIG. 8 shows a description method of the API call procedure description file 225 when calling an API that generates an Element object that represents an element defined by the type element in WSDL.
  • the defined type is a simple type
  • the qname attribute representing the Qname object to be referenced is the first argument of the constructor
  • the type attribute representing the type is the constructor
  • the minOccurs attribute that represents the minimum number of occurrences is the third argument of the constructor
  • the maxOccurs attribute that represents the maximum number of occurrences is the fourth argument of the constructor
  • the nillable attribute that indicates whether elements can be omitted is the fifth argument of the constructor Become.
  • the API call procedure description file processing unit 104 that has read the element element 801 calls the API described in 802. If the type to be defined is a complex type, which will be described later, a complex xType attribute representing a ComplexType object to be referenced is added instead of the type attribute, and the API call procedure description file processing unit 104 that reads the element element 803 reads The API described in 804 will be called.
  • (2) (4) (9) in Fig. 6 corresponds to (2) (4) (9) in Fig. 21.
  • FIG. 9 shows a description method of the API call procedure description file 225 when calling an API that generates a ComplexType object representing a complex type defined by a type element in WSDL.
  • FIG. 10 shows a description method of the API call procedure description file 225 when calling an API that generates an Operaton object representing an operation element that is a child element of the portType element in WSDL.
  • FIG. 11 shows a description method of the API call procedure description file 225 when a property is added to the Operation object.
  • the API call procedure description file processing unit 104 that has read the setProperty element 1101 calls the API described in 1102.
  • (12) in Fig. 6 corresponds to (12) in Fig. 21.
  • the API call procedure description file processing unit 104 that has read the setProperty element 1103 calls the API described in 1104.
  • (12) in Fig. 6 corresponds to (12) in Fig. 21.
  • variable names cannot be dynamically changed as shown in FIGS. Therefore, the API call procedure description file processing unit 104 that has read the qname element 701 does not actually generate the object named “qnameName”, and the object generated in the hash table or the like as shown in 120 1 of FIG. Store the name in association. At the time of reference, the corresponding object is acquired using the name and the name of the table as shown in 1202 as a key.
  • FIG. 13 shows an example of the input parameter 121 input from the application 102.
  • the input parameter 1301 includes a request parameter associated with an object array subscript, object type, and object value.
  • API call procedure description file The file processing unit 104 stores the objects in the array in order as indicated by 1302 in FIG. 13 according to the request parameters. Similarly, the return value obtained by invoking the Web service is also stored in the Object type array. Therefore, the object array subscript and the object type are associated as response parameters, and the object array subscript power can be obtained. Is converted to the specified object type and output to the application 102.
  • FIG. 14 shows an example when the object array of the input parameter 121 is two-dimensional.
  • the service identifier correspondence table storage unit 201 includes a service identifier 1501, a WSDL file acquisition destination 1502, a service name 1503, a bind name 1504, a port name 1505, an operation name 1506, and an argument name 1507. Return value name 1508 is stored.
  • the WSDL file it is usually possible to publish multiple methods. The method actually executed is specified by the parameters below the service name.
  • the service name 1503 corresponds to the name attribute of the service element in the WSDL
  • the bind name 1504 corresponds to the name attribute of the binding element
  • the port name 1505 corresponds to the name attribute of the portType element
  • the operation name 1506 corresponds to the name attribute of the operation element that is a child element of the portType element
  • argument name 1507 corresponds to the name attribute of the input element that is a child element of the operation element
  • the return value name 1508 is a child element of the operation element. It corresponds to the name attribute of a certain output element, and methods that match all of them are specified.
  • the parameters below the service name are used only to specify the method. If the same purpose is achieved, there is essentially no problem with other information.
  • FIG. 16 shows another example of the service identifier correspondence table storage unit 201.
  • information is stored as to which line in the WSDL file each element exists.
  • API call description file generation processing and API call procedure description file in step S504 Details of the aisle generator 203 will be described. First, a series of API calls ((1) to (13) in FIG. 21) necessary for calling the method specified in step S503 are generated in the same way as normal stub generation. Next, an API call procedure description file (Fig. 6) is generated from the series of API calls obtained by applying the conversion rules shown in Figs. 7 to 11 in the reverse direction.
  • the server device 20 receives the service identifier 122 from the terminal device 10, and acquires information associated with the service identifier 122 in the service identifier correspondence table storage unit 201.
  • the service identifier correspondence table storage unit 201 is omitted.
  • the input parameter 121 input by the input / output unit 101 from the application 102 includes a service interface description file acquisition destination 125 and method specifying information 126 instead of the service identifier 122. Therefore, the input parameter 121 includes five parameters: a service interface description file acquisition destination 125, method identification information 126, a request parameter 123, and a response parameter 124.
  • FIG. 18 shows input parameters 121 input from the application 102 of this example. Since the terminal device 10 transmits the input parameter 121 including the service interface description file acquisition destination 125 and the method specifying information 126 to the server device 20, the server device 20 omits the service identifier correspondence table storage unit 201 in the first example. can do.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Stored Programmes (AREA)

Abstract

Même dans un environnement tel que le MIDP inapte à l'ajout dynamique de classes, des connexions dynamiques à une pluralité de services Web peuvent être faites sur un terminal tel qu'un téléphone mobile doté de peu de ressources. Au cas où les services Web sont appelés à partir d'un serveur de services Web, un dispositif de terminal ne télécharge pas et n'installe pas une classe souche correspondant aux services Web, mais télécharge un fichier décrivant la procédure d'appel d'API énumérant une série de procédures d'appel d'API nécessaires pour appeler les services Web. Le dispositif de terminal est habilité à utiliser le service Web simplement par appel séquentiel de l'API sur la base de ce fichier décrivant la procédure d'appel d'API.
PCT/JP2005/018512 2004-10-08 2005-10-06 Dispositif de terminal, dispositif de serveur et systeme de mise a disposition de service web WO2006040991A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2006540900A JPWO2006040991A1 (ja) 2004-10-08 2005-10-06 端末装置、サーバ装置、及びＷｅｂサービス提供システム

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2004296065 2004-10-08
JP2004-296065 2004-10-08

Publications (1)

Publication Number Publication Date
WO2006040991A1 true WO2006040991A1 (fr) 2006-04-20

Family

ID=36148286

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2005/018512 WO2006040991A1 (fr) 2004-10-08 2005-10-06 Dispositif de terminal, dispositif de serveur et systeme de mise a disposition de service web

Country Status (2)

Country Link
JP (1) JPWO2006040991A1 (fr)
WO (1) WO2006040991A1 (fr)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2015045332A1 (fr) * 2013-09-24 2015-04-02 Ｎｅｃプラットフォームズ株式会社 Dispositif de liaison, système de liaison, procédé de liaison de service, et support d'informations de programme
US11343320B2 (en) 2019-08-05 2022-05-24 Fujitsu Limited Information processing apparatus, access control system, and non-transitory computer-readable storage medium for storing access control program

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH1083308A (ja) * 1996-04-23 1998-03-31 Sun Microsyst Inc スタブ検索及びローディング・サブシステム、スタブ検索及びローディング方法並びにスタブ検索及びローディング用記録媒体
JP2002505463A (ja) * 1998-02-26 2002-02-19 サン・マイクロシステムズ・インコーポレーテッド 分散システム内の遠隔処理呼出に関連する処理をおこなうためのダウンロード可能なスマートプロキシ
JP2002132739A (ja) * 2000-10-23 2002-05-10 Nec Corp スタブ検索ローディングシステム及び方法、サーバ装置、クライアント装置並びにコンピュータ可読記録媒体

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR2807254B1 (fr) * 2000-03-31 2004-08-27 Schneider Automation Systeme d'acces a un ensemble d'automatisme programmable sur une architecture wap
JP2004030360A (ja) * 2002-06-27 2004-01-29 Japan Telecom Co Ltd Ｗｅｂサービスの提供システムおよび提供支援システム
JP2004280398A (ja) * 2003-03-14 2004-10-07 Toshiba Corp サービス提供側プログラム、利用側プログラム及び方法

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH1083308A (ja) * 1996-04-23 1998-03-31 Sun Microsyst Inc スタブ検索及びローディング・サブシステム、スタブ検索及びローディング方法並びにスタブ検索及びローディング用記録媒体
JP2002505463A (ja) * 1998-02-26 2002-02-19 サン・マイクロシステムズ・インコーポレーテッド 分散システム内の遠隔処理呼出に関連する処理をおこなうためのダウンロード可能なスマートプロキシ
JP2002132739A (ja) * 2000-10-23 2002-05-10 Nec Corp スタブ検索ローディングシステム及び方法、サーバ装置、クライアント装置並びにコンピュータ可読記録媒体

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
MATSUURA ET AL.: "Web Service Application ni Chosen", JAVA DEVELOPER, 1 August 2003 (2003-08-01), SOFTBANK PUBLISHING INC, pages 106 - 111, XP002998985 *

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2015045332A1 (fr) * 2013-09-24 2015-04-02 Ｎｅｃプラットフォームズ株式会社 Dispositif de liaison, système de liaison, procédé de liaison de service, et support d'informations de programme
JP2015064682A (ja) * 2013-09-24 2015-04-09 Ｎｅｃプラットフォームズ株式会社 外部サービス連携システム、外部サービス連携装置、外部サービス連携方法、および、コンピュータ・プログラム
US11343320B2 (en) 2019-08-05 2022-05-24 Fujitsu Limited Information processing apparatus, access control system, and non-transitory computer-readable storage medium for storing access control program

Also Published As

Publication number Publication date
JPWO2006040991A1 (ja) 2008-05-15

Similar Documents

Publication Publication Date Title
US8656417B2 (en) Interface for telecommunication services using uniform resource identifiers
US10331422B1 (en) System and method for generating API devlopment code for integrating platforms
JP4909591B2 (ja) コンポーネントベースの無線アプリケーションを作成して同アプリケーションと通信するためのシステム及び方法
US7552265B2 (en) System and method for providing context information
US8521754B2 (en) System and methods for web data transformation sourcing
CA2604899C (fr) Systeme et procede de decouverte d'applications a composants
US7624370B2 (en) System and method for facilitating development of an application and supporting access to a plurality of heterogeneous backend servers
US7526482B2 (en) System and method for enabling components on arbitrary networks to communicate
US20040255005A1 (en) Web server resident on a mobile computing device
US7665096B2 (en) DDS-assisted CORBA discovery
EP1355231A2 (fr) Traitement de fichiers de données utilisant des plug-ins
JP2004519757A (ja) 媒介物に記憶されるデータへのサービスからのアクセス
AU2002351015A1 (en) Method and device for defining objects allowing to establish a device management tree for mobile communication devices
EP2145251A1 (fr) Application xml push et exécution à distance d'une application sans fil
KR100901281B1 (ko) 유비쿼터스 웹서비스 방법
CA2604900C (fr) Systeme et procede destines a decouvrir des applications mobiles sans fil
WO2006110999A1 (fr) Systeme et procede de presentation d'entites d'applications de dispositifs standards dans des dispositifs sans fil
WO2006040991A1 (fr) Dispositif de terminal, dispositif de serveur et systeme de mise a disposition de service web
JP2003076563A (ja) 分散オブジェクトミドルウェア連携方法及びプログラムを記録した記録媒体並びにプログラム
CA2544116C (fr) Systeme et methode permettant de faciliter le developpement d'une application et de prendre en charge l'acces a des serveurs dorsaux heterogenes multiples
EP1715646B1 (fr) Dispositif et procédé de connexion d'applications à des serveurs finaux hétérogènes par l'entremise de serveurs de passerelle
Sward Using ada in a service-Ooriented architecture
JP2007515716A (ja) ウェブ・サービス・インターメディアリ用のポート・タイプ不可知プロキシ・サポート
JP2007066295A (ja) Ｗｅｂサービス接続用開発フレームワーク
JP2007066294A (ja) Ｗｅｂサービス接続装置

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BW BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE EG ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KM KP KR KZ LC LK LR LS LT LU LV LY MA MD MG MK MN MW MX MZ NA NG NI NO NZ OM PG PH PL PT RO RU SC SD SE SG SK SL SM SY TJ TM TN TR TT TZ UA UG US UZ VC VN YU ZA ZM ZW

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): BW GH GM KE LS MW MZ NA SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IS IT LT LU LV MC NL PL PT RO SE SI SK TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
WWE Wipo information: entry into national phase

Ref document number: 2006540900

Country of ref document: JP

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase