GB2540773A

GB2540773A - Method, device, and computer program for processing service request in a web runtime environment to access services

Info

Publication number: GB2540773A
Application number: GB1513177.4A
Authority: GB
Inventors: Bellessort Romain; Fablet Youenn; Ruellan Hervé
Original assignee: Canon Inc
Current assignee: Canon Inc
Priority date: 2015-07-27
Filing date: 2015-07-27
Publication date: 2017-02-01
Also published as: GB201513177D0

Abstract

A method for processing a service request by a web runtime environment, WRE, in a processing device, the processing of the service request enabling a service provider to provide a service requested in the service request. Upon receiving the service request, the WRE selects, from a plurality of web driver applications acting each as an intermediary application between a service provider and a requesting web application. The web driver application either implementing the same client interface as the requesting web application, to provide the requesting web application with an intermediary application to a service provider providing the requested service, or providing an indication of a client interface to either the driver application and/or the web application for them to communicate. Then, the two applications may efficiently communicate while the use of web driver applications is no longer limited to a single web driver application per each service provider.

Description

METHOD, DEVICE, AND COMPUTER PROGRAM FOR PROCESSING SERVICE REQUEST IN A WEB RUNTIME ENVIRONMENT TO ACCESS SERVICES

FIELD OF THE INVENTION

The invention generally relates to the field of processing service requests in a web runtime environment. More particularly, the invention concerns a method, a device, and a computer program for improving access to services, in particular access to remote or network services, in a web runtime environment. The invention enables a web runtime environment to rely on intermediary applications referred here to as web driver applications in order to provide requesting web applications with interaction with services.

BACKGROUND OF THE INVENTION A web application, also called a web app, is an application relying on web technologies. Typically, such an application is developed in the HyperText Markup Language (HTML), the Cascading Style Sheets (CSS) language, or the JavaScript language. A web application is generally designated through a Uniform Resource Locator (URL) which indicates a resource, for example an application. Therefore, what is sometimes referred to as a “web page” can also be seen as a web application. A web application can also be a packaged application that may be installed on a device. In such a case, the application is stored persistently on the device.

In the context of the invention, it is considered that a web application is typically executed by a Web Runtime Environment (WRE), for example Mozilla’s Firefox OS or a web browser, enabling web applications loaded and run in the web runtime environment to cooperate.

Figure 1, comprising Figures 1a and 1b, illustrates two examples of web runtime environments.

As illustrated in Figure 1a, a web runtime environment can be a software component 100 relying on an operating system 105 to run web applications 110. A web runtime environment typically consists of one or several software modules, for example generic modules and specific modules, among which a web runtime controller, which may comprise sub-modules. Web browsers like Mozilla Firefox, Google Chrome and Microsoft Internet Explorer, are examples of such a web runtime environment (Google, Chrome, Microsoft, and Internet Explorer are trademarks).

Alternatively, as illustrated in Figure 1b, a web runtime environment 100’ can be integrated into an operating system 105’ to run web applications 110’. In such a case, the whole operating system is based on web technologies. Examples of such a web runtime environment are Google Chrome OS and Mozilla Firefox OS. A network service is a service made accessible through a network. Examples of such services are remote media display services which provide the service of displaying media on a remote screen or network printing services which provide the service of printing a document thanks to a printer connected to a network.

Such services generally implement specific application programming interfaces (API) enabling applications to interact with them. Implemented APIs depend on the type of service provided. For the sake of illustration, the Universal Plug and Play (UPnP) protocol defines a number of different types of services.

Prior to interacting with a network service, a web application has to discover which services can be accessed. This can be done thanks to discovery protocols, such as multicast Domain Name System (mDNS) protocol. A discovery process basically consists in sending a request for services on a network and waiting for responses. Each response typically provides information about a corresponding service by providing, for example, a URL to a configuration file describing the considered service.

Alternatively, each of the services periodically advertises itself to all the devices connected to a considered network, without requiring any discovery request.

It is to be noted that network services are generally implemented by devices which are different from the ones which make use of them. Accordingly, these services are often called remote services. Nevertheless, a web application running on a given device can access a service through a network interface even though that service is hosted in the same device.

Generally, a web application is limited in its interactions with the network by the web runtime environment. Typically, a web application can interact only with the server by which it is hosted. In particular, it generally cannot perform discovery based on existing discovery protocols. Consequently, APIs, in particular JavaScript APIs, exist which provide web applications with interaction capabilities so that those web applications can address requests directed to services that are remote from the web runtime environment (or web browser) in which they are executed. For the sake of illustration, a web application can request the printing of specific data, for example using the known window.printQ function, or can request the displaying on a remote display of the data pointed to by a URL, for example using the Presentation API which is an API currently standardized by the World Wide Web Consortium (W3C).

In such cases, the requesting web application does not request a specific service or type of service and does not know exactly how to interact with the remote service. Interactions between the web application and a specific service are handled by an API which provides high-level control to the web application, enabling the latter to interact with a service of a predetermined type.

Discovering available services of a predetermined type is carried out by the web runtime environment which interacts at a low-level with a selected remote service. Still for the sake of illustration, a web runtime environment can use a page description format, when processing printing requests from requesting web applications, to obtain printable data from provided data, and a communication protocol such as Internet Printing Protocol (IPP) in order to interact with an IPP printer. According to another example, the web runtime environment can use a protocol such as Miracast for remote displaying of data (Miracast is a trademark).

However, since web runtime environments interact with an increasing number of devices and services, more and more technologies have to be integrated in web runtime environments so that they can interact with these devices and services. For instance, printers, displays and sensors can be accessed through various kinds of protocols.

As illustrated by the work on the Network Service Discovery API done by the Device APIs Working Group of the W3C, allowing a web application to have a direct connection to a network service is considered as not being safe. This is because such direct connection would allow the web application to send any kind of data to the network service, possibly interacting with other network services provided by the same device. A solution that intends to overcome this drawback has been proposed that relies on using an intermediary application or component between any requesting web application and a service provider providing the requested service. Such intermediary application is associated with the service, thereby interacting with it. It is also known as a web driver application.

The web driver applications are typically available on the remote servers providing the services. Once such web driver application is retrieved from a remote server, the requesting web application can establish a direct connection with it.

Thus, when requesting a service to the WRE in which it is running, a requesting web application knows that it will obtain in return a connection to or communication session with a web driver application.

An interface in the meaning of the present document may be an API, meaning that it provides a set of functions implemented by a given component (here the web driver application) and that can be called by another component. For instance, the requesting web application may call some functions of such an interface implemented by the web driver application. In some cases, the interface may also define events that can be triggered by the other component and caught by the given component. The catching of such an event enables the given component to determine a process to be performed. For instance, the requesting web application may trigger a “start” event of a driver application so that the driver application starts the processing of a task.

An interface may also provide a communication channel on which only a message exchange function is provided, i.e. through which messages can be exchanged between two components. In such a case, it may be considered that the kind or format of the messages that are exchanged is part of the interface. A specific kind or format of message enables the first component (resp. the second component) to request the second component (resp. the first component) to perform a corresponding processing. If both components do not agree on the meaning of messages (i.e. type or format), no communication is possible. In a specific implementation, messages may be obtained through an event system (as described with regard to the first type of interface). In this second case, the means associated with the communication channel do not depend on the type of the interface (such means are generic and can be used for any type of interface, contrary to the set of messages which are specific and makes the interface distinct from other interfaces).

As one may understand, one advantage of using web driver applications as intermediary applications between the requesting web applications and the service providers is that the requesting web applications are not directly connected to the remote services. Instead, only the web driver applications communicate with the remote services, thereby protecting the remote services since the data transmitted to/from them are fully controlled by the web driver applications. In addition to protecting a requested service, using a web driver application may help protecting the other services provided by the same device.

However, one drawback of this approach is that the web driver applications are only available for services newly developed and to web applications newly developed, i.e. new services or web applications that are defined with the knowledge of the web driver applications and their interfaces and protocols.

Legacy services, which are already deployed on current networks, do not provide such drivers. Thus they cannot offer the protection as obtained through the use of such web driver applications.

One could contemplate defining specific standard drivers for the legacy services that would rely on the specific interface provided by each legacy service. However, this task would require a significant amount of time and require an amount of memory in the WRE which would implement the standard drivers for a number of legacy services.

All of the above shows that the use of web driver applications is not fully satisfactory. In particular, it lacks flexibility regarding legacy services and/or new services.

Another issue arises when there is a need to modify the interface through which the requesting web application can interact with a web driver application. The known techniques require that a new service and its associated web driver application be defined. This is not an appropriate solution since the communication interface between the new service and its associated web driver application will remain the same as before.

SUMMARY OF THE INVENTION

Facing this situation, the inventors provide a method, a device and a computer program for improving access to services, in particular access to remote services, in a web runtime environment.

It is a broad object of the invention to remedy the shortcomings of the prior art as described above.

According to a first aspect of the invention there is provided a method for processing a service request in a processing device, the method comprising the following steps carried out in a web runtime environment running in the processing device: receiving, from a requesting web application, a service request for accessing a service, the requesting web application implementing a client interface to interact with other applications; and selecting, from a plurality of web driver applications acting each as an intermediary application between a service provider and a requesting web application, a web driver application implementing the same client interface as the requesting web application, to provide the requesting web application with an intermediary application to a service provider providing the requested service.

As a result of this approach according to the invention, the requesting web application and the web driver application can directly communicate, without any specific processing (e.g. translation) by the WRE.

This is achieved through the selection of a web driver application based on the client interface implemented by the requesting web application.

Therefore, there is no need to define a standard web driver application for each type of service. Furthermore, different interfaces may now be defined or added for a type of service, i.e. there is no longer the need to define a new service if a new interface is required by a requesting web application.

As far as the legacy services are concerned, the invention thus makes it possible for any party to define its own interface to communicate with a web driver application. That is there is no longer the need to have a standard driver application with a single interface agreed to by each party.

Correlatively, the first aspect of the invention provides a device for processing a service request comprising at least one microprocessor configured for carrying out, in a web runtime environment running in the device, the steps of: receiving, from a requesting web application, a service request for accessing a service, the requesting web application implementing a client interface to interact with other applications; and selecting, from a plurality of web driver applications acting each as an intermediary application between a service provider and a requesting web application, a web driver application implementing the same client interface as the requesting web application, to provide the requesting web application with an intermediary application to a service provider providing the requested service.

The device provides the same advantages as the method defined above.

Optional features of embodiments of the invention are defined in the appended claims. Some of these features are explained here below with reference to a method, and can be transposed into system features dedicated to any device according to embodiments of the invention.

In embodiments, selecting the web driver application includes the following steps: performing a discovery procedure to discover a plurality of service providers, each providing the requested service and being associated with at least one web driver application implementing the same client interface as the requesting web application; and selecting one from the plurality of service providers, thereby additionally selecting its associated web driver application.

In a particular embodiment, selecting one from the plurality of service providers is user driven. For instance, it means that the list of discovered service providers is displayed to the user who in turns may select one of them. Implicitly, the associated web driver application is selected to offer access to the requested service to the requesting web application.

In particular embodiments, the method further comprises the following steps: determining one or more client interfaces implemented by the requesting web application; and determining, for each of the discovered service provider, one or more web driver applications implementing one of the determined one or more client interfaces.

This makes it possible to obtain all the possible combinations of client interface-web driver application-service provider.

In a particular embodiment, the method further comprises reducing the number of web driver applications and client interfaces to a single pair of web driver application and client interface per each discovered service provider. This approach limits the number of possibilities to be examined for selection, for instance by a user. In addition, by obtaining a bijection between each service provider and a single pair {driver, client interface}, it makes it possible to only propose a list of service providers to the user for a simple choice.

In a particular embodiment, the reducing includes selecting a single client interface per each determined web driver application based on a ranking of the determined client interfaces, and selecting a single web driver application per each discovered service provider based on a ranking of the determined web driver applications. Various criteria for ranking either the client interfaces and/or the web driver applications may be used to provide more or less relevant associations: for instance a location or level of accessibility of the web driver applications, their origin, a level of security associated with them, statistics on web driver application usage, user preferences, etc.

In particular embodiments, the received service request specifies a plurality of service types, and the selecting of one service provider is made from a merged list of discovered service providers for the plurality of service types. Thanks to this approach, a user may be presented a single list of possible service providers, although various alternative services are initially requested. This makes the handling of service requests simpler and more efficient.

In other particular embodiments, the web driver application implements a plurality of client interfaces, and the discovery procedure is performed to discover service providers associated with web driver applications implementing any of the plurality of client interfaces. A higher number of web driver applications may then serve the requesting web application to access the requested service.

In embodiments, the received service request indicates at least one service type based on which a discovery procedure to discover service providers providing the requested service is performed.

In embodiments, the received service request indicates at least one client interface implemented by the web driver application. This highly simplifies the processing by the WRE since the knowledge of the client interface to be used is explicit.

In variants, the method further comprises determining the client interface implemented by the requesting web application using a lookup table mapping requesting web applications and requested services to client interfaces. Such table may be filled in when processing previous service requests (for which other mechanisms for determining the client interface are used). This approach is also simple to implement, but requires memory in the WRE for storing the lookup table.

In other variants, the method further comprises determining the client interface implemented by the requesting web application by analyzing the requesting web application when loading it. This approach makes it possible for the WRE to precisely determine the required client interface, and thus the corresponding web driver application.

In a particular embodiment, said analyzing includes reading, in the code of the requesting web application, at least one field identifying the client interface the requesting web application implements. It may be an HTML or equivalent tag identifying the client interface. In variants, one may inspect the web application code itself to infer the client interface implemented therein.

In some embodiments, the method further comprises determining the client interface implemented by the requesting web application based on a service type specified in the service request received from the requesting web application.

In embodiments, the method further comprises, upon selecting the web driver application implementing the same client interface as the requesting web application, sending a computer object (usually an object-oriented language object) to the requesting web application and to the web driver application to define a communication session between them relying on the common client interface. Indeed, the session object defines, through its properties, the interface for communicating.

Such session object thus acknowledges the processing of the service request, while providing the information necessary for both the requesting web application and the web driver application to efficiently and directly communicate.

In a particular embodiment, the computer object includes an identifier of the common client interface to be used for the communication session.

According to a second aspect of the invention there is provided a method for processing a service request in a processing device, the method comprising the following steps carried out in a web runtime environment running in the processing device: receiving, from a requesting web application, a service request for accessing a service; selecting, from a plurality of web driver applications acting each as an intermediary application between a service provider and a requesting web application, a web driver application, to provide the requesting web application with an intermediary application to a service provider providing the requested service; and once the web driver application has been selected, indicating a client interface to the requesting web application and/or the selected web driver application for them to communicate one with the other to access the requested service.

This approach also provides flexibility for support of services since the interface implemented by the web driver applications is no longer a constraint. This is achieved by allowing the client interface (to be used) to be indicated to the requesting web application and/or to the web driver application after the latter has been selected.

Of course, the client interface to be used should ultimately be implemented by both applications. However, thanks to the invention, a web driver application may for instance implement a plurality of client interfaces.

Correlatively, the second aspect of the invention also provides a device for processing a service request comprising at least one microprocessor configured for carrying out, in a web runtime environment running in the device, the steps of: receiving, from a requesting web application, a service request for accessing a service; selecting, from a plurality of web driver applications acting each as an intermediary application between a service provider and a requesting web application, a web driver application, to provide the requesting web application with an intermediary application to a service provider providing the requested service; and once the web driver application has been selected, indicating a client interface to the requesting web application and/or the selected web driver application for them to communicate one with the other to access the requested service.

The device provides the same advantages as the method defined above. Optional features of embodiments of the invention are defined in the appended claims. Some of these features are explained here below with reference to a method, and can be transposed into system features dedicated to any device according to embodiments of the invention.

In embodiments, indicating a client interface includes sending a computer object (e.g. an object-oriented language object) to the requesting web application and/or to the web driver application to define a communication session between them.

In particular embodiments, the computer object includes an identifier of the common client interface to be used for the communication session. In such a way, the WRE has decided which client interface should be used.

In other particular embodiments, indicating a client interface includes jointly defining the client interface by both the requesting web application and the web driver application, using a function provided by the object defining the communication session. In other words, once the communication session has been established thanks to the session object, a dedicated function or functions of this object may be used for the two applications to negotiate or agree on a common and acceptable client interface.

For instance, the dedicated function (or functions) belongs to a fixed part of the session object known by all the applications. This is another part of the session object, namely a variable part, that has to be negotiated to jointly define, e.g. through a handshake mechanism, the client interface to be used.

In other particular embodiments, indicating a client interface includes providing an identifier of the client interface in at least one message exchanged between the requesting web application and the web driver application, using a message exchange function provided by the object defining the communication session. This approach lets the applications to decide which client interface to use, without slowing down the access to the service. Indeed, the indication of the client interface is made within the messages accessing the service.

For instance, the indication is made through a variable or parameter that belongs to a fixed part of the message (i.e. header) and that is known by all the applications. This is the format of another part of the message (variable part, e.g. a data portion) that is intrinsically defined by the client interface specified in this parameter.

Preferably, the indication is made as soon as the first message exchanged.

In a particular embodiment, the identifier of the client interface is specified in each message exchanged between the requesting web application and the web driver application. This makes it possible to possibly modify the client interface used during the session.

In embodiments, the method further comprises determining one client interface from a plurality of client interfaces common to the requesting web application and the selected web driver application.

The various features discussed above with reference to the first aspect of the invention may also be provided to the second aspect of the invention, except the specific features relating to the client interface that necessarily occur prior to the selection of the web driver application.

Another aspect of the invention relates to a non-transitory computer-readable medium storing a program which, when executed by a microprocessor or computer system in a device, causes the device to perform any method as defined above.

The non-transitory computer-readable medium may have features and advantages that are analogous to those set out above and below in relation to the methods and node devices.

Another aspect of the invention relates to a method for processing a service request in a processing device, substantially as herein described with reference to, and as shown in, Figures 3a, 4 and 5, or Figure 3b and 5 of the accompanying drawings.

At least parts of the methods according to the invention may be computer implemented. Accordingly, the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment (including firmware, resident software, micro-code, etc.) or an embodiment combining software and hardware aspects that may all generally be referred to herein as a "circuit", "module" or "system". Furthermore, the present invention may take the form of a computer program product embodied in any tangible medium of expression having computer usable program code embodied in the medium.

Since the present invention can be implemented in software, the present invention can be embodied as computer readable code for provision to a programmable apparatus on any suitable carrier medium. A tangible carrier medium may comprise a storage medium such as a floppy disk, a CD-ROM, a hard disk drive, a magnetic tape device or a solid state memory device and the like. A transient carrier medium may include a signal such as an electrical signal, an electronic signal, an optical signal, an acoustic signal, a magnetic signal or an electromagnetic signal, e.g. a microwave or RF signal.

BRIEF DESCRIPTION OF THE DRAWINGS

Further advantages of the present invention will become apparent to those skilled in the art upon examination of the drawings and detailed description. It is intended that any additional advantages be incorporated herein.

Embodiments of the invention will now be described, by way of example only, and with reference to the following drawings in which:

Figure 1, comprising Figures 1a and 1b, illustrates two examples of web runtime environments;

Figure 2 illustrates an exemplary processing of a service request to access a service;

Figure 3a illustrates, using a flowchart, main steps of a processing of service requests by a web browser or web runtime environment, in first embodiments of the invention;

Figure 3b illustrates, using a flowchart, main steps of a processing of service requests by a web browser or web runtime environment, in second embodiments of the invention;

Figure 4 illustrates, using a flowchart, main steps of determining web driver applications based on the target client interface in the process of Figure 3a;

Figure 5 illustrates, using a flowchart, main steps for providing interaction between the requesting web application and the web driver application, in the process of Figure 3a or 3b; and

Figure 6 represents a block diagram of a computer device in which steps of one or more embodiments may be implemented.

DETAILED DESCRIPTION OF EMBODIMENTS OF THE INVENTION A context of the invention relies on a specific type of web application hereinafter referred to as a web driver application. When discovered based on a requested service type, a service may provide a link to an associated web driver application, for example a URL identifying the web driver application. After a web runtime environment has discovered a service, it loads the associated web driver application to provide a requesting web application with an intermediary application (the web driver application) to a service provider providing the requested service.

Embodiments of the invention provides a decoupling between the requesting web application and the web driver application by introducing, in addition to the service type identified in the service request, the nature or type of interface between them. This means that the WRE further uses the type of interface implemented by the requesting web application when selecting the appropriate web driver application to give access to the requested service,

As mentioned above, an interface may be an API providing a set of functions including specific functions going beyond the mere sending or reception of messages, or be limited to such mere sending and reception of messages (i.e. the definition of a mere message exchange functionality) in which case the format or type of messages so exchanged provides various other (and more specific) functions.

By taking into account the client interface implemented by the requesting web application when selecting the web driver application to be executed, the invention makes it possible for the requesting web application to know how to interact with the requested service through the web driver application. Reciprocally, the web driver application also knows how to process the data received from the requesting web application based on the considered client interface.

In addition, it offers flexibility for new services to be deployed. For instance, different client interfaces may thus be defined for a given type of service, contrary to the known technics. For instance, one client interface may provide a low-level control (perform fine-grained operations) with the service, while another client interface may provide a high-level control (perform basic operations) with the service.

An example of high-level control may be a play/pause function to control a media. The corresponding interface may be a very simple API, convenient for simple use cases.

An example of low-level control may be the ability to indicate at what time the playing of a media should start. The corresponding interface could be a more complex API, needed only for specific use cases.

Figure 2 illustrates an exemplary processing of a service request to access a service. A requesting web application executed by a web browser (i.e. in a WRE) requests an interaction with a service of type ‘urn:abc:xyz’ by sending a service request. This service request 200 is created through a dedicated API provided by the browser, for instance using the API function navigator.startSession().

While the prior art only specifies the service type in the service request, exemplary embodiments of the invention provides that the service request indicates, through a second parameter, the client interface implemented by the web driver application, i.e. the interface to be used for interacting with the requesting web application.

In the example of the Figure, the client interface is ‘ci’.

Based on the service request, the web browser (WRE) performs a discovery procedure 202 to discover available service providers for the requested service type. The web browser also determines possible web driver applications for this service type based on the client interface ‘ci’ indicated in the requested, i.e. determines web driver applications that also support this client interface ‘ci’.

Various ways for the web browser to have knowledge of the web driver applications available for the discovered service providers may be implemented.

For instance, the service provider itself may indicate the supported web driver application or applications in the description information associated with the service provider (such information is retrieved by the web browser during the discovery procedure).

If we consider the service provider to be a legacy service provider that cannot be updated to include web driver application information, such web driver application may be directly implemented by the web browser itself or be an application obtained from another server based on a specific knowledge of the web browser.

Next, the web browser provides the list of discovered service providers for the user to select one of them at step 204. Note that each service provider is associated with a web driver application supporting the client interface ‘ci’, as obtained during the discovery procedure 202.

Preferably, only the list of service providers is displayed to the user, i.e. without any indication on the web driver application and/or on the client interface that are voluntarily hidden by the web browser. This hides complexity to the user since the latter may understand the concept of a service provider, but not the one of a web driver application nor of a client interface.

Once the user has selected one of the service providers (and implicitly the associated web driver application), the associated web driver application is loaded in the WRE at step 206. Such web driver application is for instance written in JavaScript, hence can be executed by the web browser. A “session” object (in the meaning of an object-oriented language) is then sent at step 208 to both the requesting web application and the loaded web driver application. This session object in particular defines a communication session between the two applications, which session relies on the common client interface. In other words, the session object defines the functions allowing sending/receiving messages to/from the two applications. It may for instance include an identifier of the common client interface to be used for the communication session, for instance if one of the two involved applications can implement more than one client interface.

Next, the requesting web application sends a “doThisMsg” message at step 210 using the functions provided by the session object, for instance the function session.postMessage to merely send a message. Such “doThisMsg” message is a request for performing a specific processing labelled “doThisMsg”. “doThisMsg” may be a simple string or a structured message comprising various parameters. In both cases, what matters is that the message is structured according to the common client interface ‘ci’, and that it comprises values authorized by said client interface. This ensures the two applications to understand one each other.

When the web browser receives this message, it forwards it to the driver application, which can process it (step 212). In practice, since the two involved applications are executed by the same web browser, they directly communicate one with the other, the web browser being only the execution environment in which the communication session occurs.

In the example of the Figure, the execution of the “doThisMsg” message implies two interactions (214) between the web driver application and the selected service provider. These two interactions are performed (Requests #1 and #2, each associated with a response).

Based on the responses, the web driver application returns a main response to the requesting web application at step 216. This response may for instance indicate that “doThisMsg” was successfully processed, or that an error occurred. This response is also a message which is built based on ‘ci’ client interface rules.

If needed, other interactions may occur through the exchange of additional messages.

Figure 3a illustrates, using a flowchart, main steps of a processing of service requests by a web browser or web runtime environment, in first embodiments of the invention.

First, at step 300, a service request for accessing a service is received from a requesting web application. The requesting web application is typically a web application executed by the WRE. But in variants, it may also be the WRE itself or an application executed outside of the WRE but using web functions of the WRE.

The service request is created by the requesting web application using a dedicated API implemented by the WRE, referred to below as the target client interface.

The request for a service comprises a type indicating the type of service the requesting web application would like to interact with, i.e. the service type based on which a discovery procedure to discover service providers providing the requested service will be performed.

In some embodiments, the requesting web application may indicate more than one service type in the service request, for instance if the API provided by the WRE to create a service request allows requesting different service types at the same time. This may be especially useful as different types of service may in fact be mostly similar.

For instance, the requesting web application may want to interact with a remote media player service, but it does not matter whether this service is of type A or B. In such a case, the requesting web application may want to request such a service by creating a service request for both service provider of type A and service provider of type B.

In some embodiments further described below, the service request may also indicate (through an identifier) the target API or client interface or interfaces implemented by the requesting web application.

To signal the target client interface or interfaces in the service request, a basic solution consists in having two parameters in the request defined for the interface: one for the service type and one for the client interface or interfaces.

Each of them is typically a string identifying a given service type and a given client interface. To enable specifying more than one service type and/or more than one client interface, the string parameter may be replace by a list of strings.

In a variant, another solution to provide both a service type and a client interface may involve a single parameter that comprises two pieces of information.

For instance, a character (or sequence of characters) that cannot appear in the service type and in the client interface may be chosen as a separator between both strings. As an example, and provided this character may not appear in the identifier strings, a slash character 7” or plus character “+” may be used. The single parameter may then be of the form “serviceType/clientlnterface” or “serviceType+clientlnterface”.

An advantage of this solution is that the API remains similar to prior art APIs which relies on a single parameter indicating a service type while still allowing to provide a client interface if needed.

As above, if more than one service type or client interface is to be provided, this string parameter may be replaced by a list of strings.

The reception of the service request substantially corresponds to exemplary step 200 of Figure 2.

Next, at step 305, the WRE determines a list of service providers corresponding to the type of service indicated in the service request. This may be done by performing a discovery procedure to discover a plurality of service providers, each providing the requested service and being associated with at least one web driver application implementing the same (target) client interface as the requesting web application.

The WRE can discover service providers on a network, for instance a local network. This discovery process involves discovery means, such as mDNS or SSDP.

Note that the type of service sometimes inherently determines the discovery means to be used. For instance, the UPnP service requires that SSDP be used, while a Zeroconf service requires that mDNS be used.

In addition, the WRE may also rely on services accessible through a gateway or a remote server, possibly using proprietary means.

Next, at step 310, a list of web driver applications executable by the WRE and adapted to act as an intermediary application between the requesting web application and the service provider using the target client interface is determined.

Figure 4 illustrates, using a flowchart, main steps of determining web driver applications based on the target client interface, and thus illustrates step 310.

The process starts at step 400 during which a list of one or more client interfaces implemented by the requesting web application (i.e. of target client interfaces supported by the requesting web application) is determined. This is to know all the client interfaces than could be used by the web driver application to be determined for selection.

One approach for such determining step 400 may rely on an indication of supported client interfaces in the service request itself. In other words, the service request indicates the one or more client interfaces implemented and supported by the requesting web driver application.

If a specific API or interface is used by the requesting web application to create the service request, this API or interface may support a corresponding parameter used to indicate the identifier of the client interface, or a list of identifiers of client interfaces, as mentioned above.

Another approach for such determining step 400 consists for the WRE in determining by itself one or more supported client interfaces based on the considered requesting web application.

For instance, the WRE may determine the one or more client interfaces implemented by the requesting web application using a lookup table mapping requesting web applications and requested services to client interfaces.

Such a lookup table may be embedded in the WRE or hosted in a remote server.

Alternatively, the WRE may determine the one or more client interfaces implemented by the requesting web application by analyzing the requesting web application when loading it. For instance, it may read, in the code of the requesting web application, at least one field identifying the one or more client interfaces the requesting web application implements. This can be done by the WRE when parsing and loading the requesting web application.

As an example, the supported client interface or interfaces may be described through HTML tags and attributes, or through JavaScript instructions enabling the requesting web application to declare supported client interfaces.

In a slight variant to the explicit declaration through HTML tags or equivalent, the supported client interfaces may also be inferred by the WRE through code inspection (even if no HTML tags or JavaScript instructions are defined). For instance, the WRE can recognize or detect some code portions that are specific to some client interfaces.

Another approach for determining step 400 may consist for the WRE in determining the client interface or interfaces implemented by the requesting web application based on the service type (or types) specified in the service request received from the requesting web application.

This may be done especially if it is known that, for a given service type, one client interface is mandatory, or at least largely dominant. Indeed, in such a case, it is highly likely that the requesting web application supports this client interface.

However, this third approach should preferably be used as a fallback procedure if none of the two first approaches makes it possible to determine the one or more supported client interfaces.

For instance, this would make it possible for the WRE to be able to handle a service request even if the requesting web application forgets or voluntarily omits to specify the client interface or interfaces directly in the service request. In such case, the WRE may decide to use the third approach to infer a client interface from the service type specified in the request.

It is for instance proposed that in such a case, at least one client interface associated with said service type may be determined from a table associating client interfaces with service types.

Alternatively, it may be decided that the string designating the service type may also be used to designate the client interface. This provides an easy way to integrate prior art proposals into this new model where a client interface has to be provided (on the other hand, only a service type is provided by the prior art proposals).

In this case, the WRE may consider that a web driver application from the prior art associated with the considered service type supports the inferred client interface.

Next to step 400, step 405 consists for the WRE in determining, for each of the discovered service provider, one or more web driver applications implementing one of the determined one or more client interfaces. This may be done in various ways.

One approach relies on the fact that that web driver applications may be described in the discovery information of a given service provider. Typically, when the WRE discovers a service provider for the requested service, a service description is also provided, accessible through an URL. This description, or “discovery information”, may comprise an URL (local or remote) associated with a web driver application for the service. As a consequence, the WRE may identify an associated web driver application, and obtain a corresponding URL to retrieve it if necessary.

Another approach may rely on a web driver application repository. For instance, the web driver application repository may have entries associating both a service type and a client interface with a reference (e.g. an identifier or an URL) to one or more web driver applications. In such case, the WRE may query the repository for web driver applications by providing, as inputs, the service type specified in the request and the client interface or interfaces determined at step 400. In response, it will receive one or more references to corresponding web driver applications.

Preferably such a repository may be directly embedded in the WRE. For instance, the WRE may comprise (include) some web driver applications for frequently used services (e.g. remote media playing, printing, sensors). A web driver application directly embedded in the WRE may either be present as a part of the WRE, or as an extension (plug-in) to the WRE.

As such an embedded repository cannot be used for all services since it would substantially increase the size of the WRE, it may be limited to frequently used services (for instance legacy services deployed on devices that cannot be updated and therefore cannot provide their associated web driver application in their description file), while the other services provide their associated web driver applications through their description file.

Next to steps 400 and 405, the WRE has knowledge of which client interfaces are supported and of which web driver applications and service providers are available for these client interfaces.

In some cases, this may lead to a huge number of potential combinations.

However, since the user does not necessarily understand the concepts of client interfaces and of web driver applications but should understand the concept of service provider (in particular if it can be associated with a device, such as a TV in a living room that can be used to display video, or a sensor in a room that enables obtaining temperature), next steps 410 and 415 propose to reduce the number of web driver applications and client interfaces to a single pair of web driver application and client interface per each discovered service provider. In other words, it reduces the number of combinations.

First step 410 consists in selecting a single client interface per each determined web driver application, for instance based on a ranking of the determined client interfaces, i.e. in associating each web driver application with a single client interface.

Next, step 415 consists in selecting a single web driver application per each discovered service provider, for instance based on a ranking of the determined web driver applications, i.e. in associating each service provider with a single web driver application.

These steps are not mandatory, but they allow building a mere list made of triples (service provider, web driver application, client interface), which in turns allows providing users with a short list of service providers as explained further below.

Various criteria may be used to associate each service provider with a web driver application. For instance, the WRE may rank the web driver applications according to ranking criteria/parameters, and select, for each service provider, the top-ranking web driver application.

Ranking parameters may include all or part of: - the location of the web driver application. For instance, a web driver application that is embedded within the WRE is necessarily available, whereas a web driver application accessed through a URL may not be reachable, especially if the URL does not correspond to a local network. Thus the ranking may give priority to embedded web driver applications and then to local web driver applications and, last, to remote web driver applications; - the origin of the web driver application. Some URLs of web driver applications might be more trusted than others. In particular, if the URL refers to the device hosting the service provider, it is likely that the corresponding web driver application has been developed with this service provider in mind. Hence it is liable to provide a good user experience. On the other hand, a URL referring to an unknown server provides fewer guarantees and should be given less priority (ranking); the security associated with the web driver application. For instance, a web driver application associated with a URL served over HTTPS should be given more priority (better ranking) than a web driver application associated with a URL served over (non-secure) HTTP; statistics or history regarding the usage of a given web driver application. For instance whether problematic issues occurred while previously using this web driver application should be taken into account to adjust a ranking value. Such statistics may be collected by the WRE, but also shared between different WREs in order to obtain more significant statistics; user preferences. For instance, a user may define a default web driver application for a given service type, or define a black-list and/or a white-list of web driver applications. Ranking for web driver applications should thus be adjusted accordingly; - the client interface or interfaces the web driver application support. Indeed, if the requesting web application provides a list of client interfaces (in the service request for instance), the order of the provided client interfaces may reflect a preference order, in which case the ranking is made accordingly. In another example, the WRE may determine that some client interfaces are more often associated with problematic issues and thus should avoid selecting a web driver application which supports only such interfaces (thus bad ranking is given to them).

Similar criteria or parameters may be used to associate each web driver application with a client interface. For instance, the requesting web application may indicate a preferred order of client interfaces in the service request, to be taken into account when selecting the client interface for the web driver application considered. Also, the WRE may determine whether problematic issues are likely to occur with a given client interface in order to give it bad ranking.

After step 415, the process ends at step 420.

Back to Figure 3a, all of the process of steps 305 and 310 correspond to exemplary step 202 of Figure 2.

Note that the above steps 305 and 310 have been described for a service request specifying one service type. However, embodiments provide that two or more service types are defined in the service request. In such a case, the service request may be processed as if several different requests have been made by the requesting web application. However, the results of the several requests can be merged to obtain a single list of service providers. The advantage of doing so compared to doing several different requests successively is that the user is presented with a single list of possible choices as described below.

Once the list of web driver applications has been determined at step 310, next step is step 315 during which the WRE enables the user to select a service provider and an associated web driver application and a client interface, from among the list obtained at step 310. This corresponds to exemplary step 204 of Figure 2.

Preferably, the WRE presents a reduced list of options to the user. Typically, only a list of the service providers identified at step 310 is displayed, i.e. no information regarding the web driver applications and the client interfaces is displayed.

This is why steps 410 and 415 reduce the number of possible combinations to a single triplet for each discovered service provider.

By abstracting the web driver applications and the client interfaces, the user faces a simple choice (i.e. only selecting a service provider).

Alternatively, advanced user may be enabled to select a specific combination of service provider, web driver application and client interface. However this implies more user inputs, which is more complex.

In a variant to the user-driven selection of the service provider, selection step 315 may be performed directly by the WRE. This may in particular be the case if the user has defined some settings indicating that, in specific circumstances (e.g. in a given location, on a given network, for a given requesting web application, etc.), a specific service provider (and possibly a corresponding web driver application and client interface) should be selected.

Next, at step 320, the selected web driver application is executed. This corresponds to exemplary step 206 of Figure 2.

The process may involve retrieving the web driver application code from a remote or local storage location (using an associated URL) and loading it in order to execute it.

Alternatively, the web driver application may be implemented as a part of the WRE, or as an extension (plug-in) of the WRE. In such a case, if the selected web driver application is already being executed when reaching step 320, there may be no need to execute another instance of the web driver application depending on the driver application model. A first model may consist in using one instance of a web driver application for each requesting web application: in this case, executing a new instance at step 320 is necessary. A second model may consist in using a single instance of a web driver application for multiple requesting web applications: in this case, if an instance is already being executed, it may be reused for the considered requesting web application. The second model may be more efficient as a single instance is executed, but it is also more complex as a single driver instance has to be able to handle multiple communications at the same time.

Next, at step 325, the WRE allows interaction between the requesting web application and the web driver application thus executed, after which the process ends at step 330.

This interaction is performed through the client interface that is common to both the requesting web application and the web driver application.

Figure 5 illustrates, using a flowchart, main steps for providing interaction between the requesting web application and the web driver application, and thus illustrates step 310.

The process of the Figure starts at step 500 by providing the requesting web application with an object allowing interaction with the web driver application, i.e. the intermediary application.

This object may be a JavaScript object that is created specifically for the purpose of interacting with the selected service provider through an appropriate web driver application, using the selected client interface.

Such an object may for instance be designated as a “session” object as it corresponds to a session with the service provider. The session allows interacting with the web driver application through the selected client interface that allows sending messages to the web driver application.

Alternatively, the object may be not specific to the considered session, but a generic object that allows interacting with the web driver application. As an example, the “window” JavaScript object or the “navigator” JavaScript object may implement such an API allowing a requesting web application to interact with a web driver application.

Similarly, an equivalent object is delivered to the web driver application at step 505.

Since both the requesting web application and the web driver application rely on JavaScript, the same kind of object can be used in both cases, even though objects may slightly differ depending on whether they are intended to the requesting web application or to the web driver application.

The sending of the two objects corresponds to exemplary step 208 of

Figure 2.

Preferably, the objects may provide information for the requesting web application and/or the web driver application to determine the selected client interface. This may be useful if the requesting web application or the web driver application can implement several client interfaces, to specify which client interface to use to ensure both applications understand one each other.

Indication of the selected client interface may be performed by adding a dedicated attribute to the JavaScript object used to enable interaction. For instance, an attribute “object.clientlnterface” may be associated with the string (or an identifier) designating the selected client interface.

Such indication of the client interface is thus made once the web driver application has been selected.

Next, at step 510, an input is obtained either from the requesting web application or from the web driver application.

Such input may for instance be a message to be transmitted to the remote party (i.e. either the requesting web application or the web driver application), or an instruction regarding the session, for instance an instruction to end the session.

This may corresponds to exemplary step 210 of Figure 2 where the “doThisMsg” is received or to exemplary step 216 of Figure 2 where the corresponding response is received. While Figure 2 only considers these two cases, other inputs may be obtained: for instance, a specific instruction may allow a requesting web application to request the status of the connection with the service provider, or to obtain an error. This depends on the generic API associated with the considered JavaScript object.

It may be noted that as soon as a messaging API is made available (i.e. means to send/receive messages), all other instructions can be performed through messages. However, it may be more convenient to define other functions in the API if they are commonly used, which is the case of the “end()” function that allows indicating the end of the session.

At step 515, it is checked whether the input obtained corresponds to the end of the interaction. If not, as previously explained, it is considered in the context of this Figure that the input is a message obtained from one party. Therefore, the message is transmitted to the other party at step 520, and the process returns to step 510.

Alternatively, if other specific inputs associated with specific functions are defined, additional tests similar to step 515 and associated with those specific functions are performed in case of positive evaluation (e.g. to check connection status or to obtain an error).

If the input obtained is the end of the interaction as determined at step 515, the remote party is notified and interaction ends at step 525. Ending the interaction may involve several steps, for instance notifying the web driver application, obtaining a confirmation that the session with the service provider has ended, and finally notifying the requesting web application that the session has successfully ended.

Then, the process ends at step 530.

Figure 3b illustrates, using a flowchart, main steps of a processing of service requests by a web browser or web runtime environment, in second embodiments of the invention. This process mainly differs from the process of Figure 3a in the fact that it does not require that the client interface to be used for interactions between the requesting web application and the web driver application is known prior to performing the selection of the web driver application.

Theoretically, there is thus a risk that no common client interface supported by both the requesting web application and the selected web driver application can be found. That is why the second embodiments should preferably be applied only in circumstances that guarantee, or at least maximize the likeliness, that such a commonly supported client interface can be determined.

This is for instance the case when a limited number of client interfaces is defined and that all of them have to be implemented by a web driver application.

In another example, this may also be the case when at least one client interface is defined as being mandatory for a web driver application.

As a last example, it may happen that a given client interface, even though not being the single one nor being mandatory, is largely dominant and generally implemented by the majority of requesting web applications and web driver applications. In such a case, it may also be considered that said client interface is highly likely to be supported by both the actual requesting web application and the selected web driver application.

The process of Figure 3b starts by steps 350 and 355 which are similar to steps 300 and 305 of Figure 3a, to receive a service request and discover the service providers providing the service type specified in the service request.

Next to step 355, the WRE enables at step 360 the user to select a service provider, from among the list obtained at step 355.

Still at step 355, a web driver application associated with the selected service provider is implicitly selected (in case a single web driver application is associated with each service provider) and then retrieved (URL specified in the discovery information, etc.).

However, if several web driver applications are associated with the selected service provider, the user may be requested to select one of them.

This web driver application is still selected in order to act as an intermediary application between the requesting web application and the selected service provider.

Of course, the selection of step 360 may be performed by the WRE itself, instead of being user driven.

Next to step 360, step 365, similar to step 320 of Figure 3a, consists in executing the selected web driver application, and is followed by step 370 quite similar to step 325 and already described above with reference to Figure 5.

As for step 325, step 370 includes indicating a client interface to the requesting web application and/or the selected web driver application for them to communicate one with the other to access the requested service, once the web driver application has already been selected.

The client interface to be used may be selected or determined by the WRE in which case the latter may indicate it within the session objects sent at steps 500 and 505.

In variants, the communication of such client interface may occur after the interaction has been enabled between the requesting web application and the web driver application, i.e. after the session objects have been sent at steps 500 and 505.

In one embodiment of these variants, the requesting web application and the web driver application may jointly define the client interface through a negotiation or handshake mechanism between them. This negotiation may involve using a function provided by the (e.g. JavaScript) object defining the communication session, i.e. the two applications may use this function to exchange indication with a view of jointly defining the client interface to be used.

For example, one of the two applications (e.g. the requesting web application) may call a specific function of the JavaScript object to provide the other with the list of one or more client interfaces it implements, in response to which the other application provides the selected one from among the implemented client interfaces. In a slight variant, the first application may use the specific function of the JavaScript object to define one selected client interface, in response to which the other application may indicate whether or not it accepts this choice.

In another embodiment of these variants, the requesting web application and/or the web driver application may provide an identifier of the client interface used, in the messages exchanged between them. Note that the sending of these messages may rely on using a message exchange function provided by the (JavaScript) object defining the communication session.

Preferably, the client interface selected and thus used is indicated in the very first message to be exchanged once the communication session has been established. The next message (i.e. a response to the very first message) may validate implicitly or explicitly the choice of the client interface. Indeed, if no response is received to the very first message, it may mean that the client interface used is not compatible to the addressee application, in which case the sending application may resend the very first message using another client interface it implements.

In a specific embodiment, the client interface used is indicated in each message exchanged. This allows changing the client interface used during the communication session.

Note that since the client interface is not known prior the indication in the very first message or each message, such indication is made in a fixed part of the message (e.g. a header) in order for the addressee application to know the client interface before interpreting the remainder of the message (the format of which depending on the client interface used).

Next to step 370, the process ends at step 375.

Figure 6 represents a block diagram of a computer device 600 in which steps of one or more embodiments may be implemented.

Preferably, the device 600 comprises a communication bus 602, a central processing unit (CPU) 604 capable of executing instructions from program ROM 606 on powering up of the device, and instructions relating to a software application from main memory 608 after the powering up. The main memory 608 is for example of Random Access Memory (RAM) type which functions as a working area of CPU 604 via the communication bus 602, and the memory capacity thereof can be expanded by an optional RAM connected to an expansion port (not illustrated). Instructions relating to the software application may be loaded to the main memory 608 from a hard-disk (HD) 610 or the program ROM 606 for example. Such software application, when executed by the CPU 604, causes the steps described with reference to Figures 2 to 5 to be performed in the computer device.

Reference numeral 612 is a network interface that allows the connection of the device 600 to the communication network 614. The software application when executed by the CPU 604 is adapted to react to requests received through the network interface and to provide data and requests via the network to other devices.

Reference numeral 616 represents user interfaces to display information to, and/or receive inputs from, a user.

It should be pointed out here that, as a variant, the device 600 for processing data can consist of one or more dedicated integrated circuits (ASICs) that are capable of implementing the method as described with reference to Figures 3 to 7.

Naturally, in order to satisfy local and specific requirements, a person skilled in the art may apply to the solution described above many modifications and alterations all of which, however, are included within the scope of protection of the invention as defined by the following claims.

Claims

1. A method for processing a service request in a processing device, the method comprising the following steps carried out in a web runtime environment running in the processing device: receiving, from a requesting web application, a service request for accessing a service, the requesting web application implementing a client interface to interact with other applications; and selecting, from a plurality of web driver applications acting each as an intermediary application between a service provider and a requesting web application, a web driver application implementing the same client interface as the requesting web application, to provide the requesting web application with an intermediary application to a service provider providing the requested service.

2. The method of Claim 1, wherein selecting the web driver application includes the following steps: performing a discovery procedure to discover a plurality of service providers, each providing the requested service and being associated with at least one web driver application implementing the same client interface as the requesting web application; and selecting one from the plurality of service providers, thereby additionally selecting its associated web driver application.

3. The method of Claim 2, wherein selecting one from the plurality of service providers is user driven.

4. The method of Claim 2, further comprising the following steps: determining one or more client interfaces implemented by the requesting web application; and determining, for each of the discovered service provider, one or more web driver applications implementing one of the determined one or more client interfaces.

5. The method of Claim 4, further comprising reducing the number of web driver applications and client interfaces to a single pair of web driver application and client interface per each discovered service provider.

6. The method of Claim 5, wherein the reducing includes selecting a single client interface per each determined web driver application based on a ranking of the determined client interfaces, and selecting a single web driver application per each discovered service provider based on a ranking of the determined web driver applications.

7. The method of Claim 2, wherein the received service request specifies a plurality of service types, and the selecting of one service provider is made from a merged list of discovered service providers for the plurality of service types.

8. The method of Claim 2, wherein the web driver application implements a plurality of client interfaces, and the discovery procedure is performed to discover service providers associated with web driver applications implementing any of the plurality of client interfaces.

9. The method of Claim 1, wherein the received service request indicates at least one service type based on which a discovery procedure to discover service providers providing the requested service is performed.

10. The method of Claim 1, wherein the received service request indicates at least one client interface implemented by the web driver application.

11. The method of Claim 1, further comprising determining the client interface implemented by the requesting web application using a lookup table mapping requesting web applications and requested services to client interfaces.

12. The method of Claim 1, further comprising determining the client interface implemented by the requesting web application by analyzing the requesting web application when loading it.

13. The method of Claim 12, wherein said analyzing includes reading, in the code of the requesting web application, at least one field identifying the client interface the requesting web application implements.

14. The method of Claim 1, further comprising determining the client interface implemented by the requesting web application based on a service type specified in the service request received from the requesting web application.

15. The method of Claim 1, further comprising, upon selecting the web driver application implementing the same client interface as the requesting web application, sending a computer object to the requesting web application and to the web driver application to define a communication session between them relying on the common client interface.

16. The method of Claim 15, wherein the computer object includes an identifier of the common client interface to be used for the communication session.

17. A method for processing a service request in a processing device, the method comprising the following steps carried out in a web runtime environment running in the processing device: receiving, from a requesting web application, a service request for accessing a service; selecting, from a plurality of web driver applications acting each as an intermediary application between a service provider and a requesting web application, a web driver application, to provide the requesting web application with an intermediary application to a service provider providing the requested service; and once the web driver application has been selected, indicating a client interface to the requesting web application and/or the selected web driver application for them to communicate one with the other to access the requested service.

18. The method of Claim 17, wherein indicating a client interface includes sending a computer object to the requesting web application and/or to the web driver application to define a communication session between them.

19. The method of Claim 18, wherein the computer object specifies the common client interface to be used for the communication session.

20. The method of Claim 17, wherein indicating a client interface includes jointly defining the client interface by both the requesting web application and the web driver application, using a function provided by the object defining the communication session.

21. The method of Claim 17, wherein indicating a client interface includes providing an identifier of the client interface in at least one message exchanged between the requesting web application and the web driver application, using a message exchange function provided by the object defining the communication session.

22. The method of Claim 21, wherein the identifier of the client interface is specified in each message exchanged between the requesting web application and the web driver application.

23. The method of Claim 17, further comprising determining one client interface from a plurality of client interfaces common to the requesting web application and the selected web driver application.

24. A device for processing a service request comprising at least one microprocessor configured for carrying out, in a web runtime environment running in the device, the steps of: receiving, from a requesting web application, a service request for accessing a service, the requesting web application implementing a client interface to interact with other applications; and selecting, from a plurality of web driver applications acting each as an intermediary application between a service provider and a requesting web application, a web driver application implementing the same client interface as the requesting web application, to provide the requesting web application with an intermediary application to a service provider providing the requested service.

25. A device for processing a service request comprising at least one microprocessor configured for carrying out, in a web runtime environment running in the device, the steps of: receiving, from a requesting web application, a service request for accessing a service; selecting, from a plurality of web driver applications acting each as an intermediary application between a service provider and a requesting web application, a web driver application, to provide the requesting web application with an intermediary application to a service provider providing the requested service; and once the web driver application has been selected, indicating a client interface to the requesting web application and/or the selected web driver application for them to communicate one with the other to access the requested service.

26. A non-transitory computer-readable medium storing a program which, when executed by a microprocessor or computer system in a device, causes the device to perform the method of Claim 1 or 17.

27. A method for processing a service request in a processing device, substantially as herein described with reference to, and as shown in, Figures 3a, 4 and 5, or Figure 3b and 5 of the accompanying drawings.