WO2013013379A1

WO2013013379A1 - An enhanced method and apparatus for service description, matching and ranking

Info

Publication number: WO2013013379A1
Application number: PCT/CN2011/077560
Authority: WO
Inventors: Yanfeng Zhang; Zhigang Zhang; Xiaojun Ma
Original assignee: Technicolor (China) Technology Co., Ltd.
Priority date: 2011-07-25
Filing date: 2011-07-25
Publication date: 2013-01-31

Abstract

A method and apparatus are described including performing functional web service matching of web services and providers and performing non-functional web service matching and ranking of the web services and providers resulting from the functional matching.

Description

AN ENHANCED METHOD AND APPARATUS FOR SERVICE DESCRIPTION,

MATCHING AND RANKING

FIELD OF THE INVENTION

The present invention relates to advanced home networks, especially to in-home multimedia distribution and home gateway applications.

BACKGROUND OF THE INVENTION

A number of middleware methods have been proposed to implement home network. UPnP (Universal Plug and Play) eases interoperability among devices. HAVi (Home Audio and Video interoperability) aids interoperability between video and audio devices. Jini addresses interoperability for Java applications. OSGI (Open Services Gateway Initiative) is directed to a middleware framework between networked services. These recent home network middleware methods are used to connect, integrate, and manage services provided by devices that are in a restricted area. Likewise, there exist needs for seamless interconnection and integration with the external Internet services, i.e. to access home network services from a client or to reach out to access external Internet services from a home network. As the standard technology, the web service becomes the basis to integrate home and Internet services, due to its platform-independent and programming language-independent characteristics. As defined in Wikipedia, "A Web service is a method of communication between two electronic devices over a network". For web services, there are two main service discovery architectures: decentralized and centralized. Within a decentralized architecture, as shown in Fig. 1, there is no main component, or components, tasked with maintaining a list of services. A discovery request for a specific service is broadcast to the entire home network. Components which offer the desired service respond directly to the querying component. UPNP, HAVi, and P2P operate with such decentralized approach. In a centralized network, as shown in Fig. 2, there is a main point of contact for all components joining the network. The central component may be responsible for a number of operations, such as a service registry or network security. Other network components can query the central component for service discovery. The service provided by above network components can be home multimedia- related services, such as, transcoding, compressing, decompressing, storage, searching, DRM management, etc., or other services, such as authentication, security, accounting, etc.

In conventional web services discovery, service requesters search out their needed services from multiple available services by executing a service matching between their requested service and service descriptions. An ideal service description language should be able to describe the functional characteristics, the performance characteristics and the semantic characteristic of a web service. An ideal service matching process also should be able match not only based on function, but also on semantics and performance characteristics.

OWL-S (Web Ontology Language-Service) is an OWL-based Web service ontology, which supplies a core set of markup language and constructs for describing the properties and capabilities of web services in unambiguous, computer-interpretable form. The overall ontology includes three main components: the service profile for advertising and discovering services; the process model, which gives a detailed description of a service's operation; and the grounding, which provides details on how to interoperate with a service, via messages. Specifically, OWL-S specifies the signature of a service including the inputs required by the service and the outputs generated by the service. Furthermore, since a service may require certain external conditions to be satisfied, and the service has the effect of changing such conditions, the service profile describes the preconditions (external) required by the service and expected effects that result from the execution of the service. With OWL-S, the functional and semantic characteristics of web services are present in the service profile, but the performance characteristics are absent from the service profile. Therefore, the current OWL-S service matching algorithms rarely consider service performance. The OWL-S service matching algorithms attempt to resolve the question of whether a special service requirement can be correctly executed by a web service, but do not decide or try to decide whether the selected service can provide the best performance. SUMMARY OF THE INVENTION

The present invention enhances the service description of OWL-S with non- functional characteristics, and also provides a service matching algorithm, which not only can execute functional service matching, but also can perform selection of the optimal service based on performance and, thus provide the best quality of service. The functional description of a web service means the intrinsic interface information in the Service Profile, such as IOPE (Input, Output, Precondition, and Effect) parameters. The nonfunctional description mainly focuses on the performance and context characteristics of a special Web Service, such as response time, use fee, reliability, CPU capability, memory size, etc. Correspondingly, service matching based on a functional description can decide whether a service can meet a special service requirement, while optimal service selection based on a non-functional description can select the best one in the available services, which meet the functional requirements.

In the present invention, OWL-S description ontology is expanded with performance and context information, so that enhanced OWL-S can be used to fully present the functional, performance and semantic characteristics of a certain Web Service.

With the expanded OWL-S ontology, a two-step service matching algorithm is introduced:

• Functional service matching is executed first. In this step, the services whose service descriptions meet the OWL-S IOPE matching are selected. That is to say, for a certain service requirement, only the services which can realize the functional requirement (in IOPE form) are chosen (selected).

• In the second step the selected services of step one are reviewed in order to select the optimal service provider from among those service (provided by service providers) that meet the functional (IOPE) requirements. In this second step, the services chosen by functional service matching are further filtered, so that the optimal service, which can provide the best quality of service, is selected.

BRIEF DESCRIPTION OF THE DRAWINGS The present invention is best understood from the following detailed description when read in conjunction with the accompanying drawings. The drawings include the following figures briefly described below:

Fig. 1 shows a decentralized network architecture for service discovery

Fig. 2 shows a centralized network architecture for service discovery

Fig. 3A shows a conventional OWL-S presentation of a spatial scaling service.

Fig. 3B shows an exemplary enhanced OWL-S presentation of a special scaling service.

Fig. 4 shows the two-step service matching process of the present invention. Fig.5 shows the enhanced semantic presentation of device profile in accordance with the principles of the present invention

DETAILED DESCRIPTION OF THE PREFERRED EMB ODF ENT S

In a context-aware computing environment, services provided by devices (service providers) are not bound tightly with a special application. Instead, devices in the system often publish or advertise their services in service description form into a central repository (such as the Open Service Gateway in OSGI framework) or in a peer-to-peer (P2P) network. To make the service description understandable between different devices (service providers), OWL-S based service descriptions are adopted to present the service provided by a device, such as in Amigo Project

OWL-S is an ontology, within the OWL-based framework of the Semantic Web, for describing Semantic Web Services. It enables users and software agents to automatically discover, invoke, compose, and monitor Web resources offering services, under specified constraints. OWL-S aims to enable the following tasks:

• Automatic Web service discovery

• Automatic Web service invocation

• Automatic Web service composition and interoperation

The OWL-S ontology has three main parts: • Service profile: how the service presents itself to the external world.

• Service model: what the service does, and how the client interacts with it;

• Service grounding: how the service is realized - analogous to Web Services Description Language (WSDL) (which is in Extensible Markup Language (XML) format) binding.

Fig. 3 is an example showing the description of the spatial scaling operation for video based on the IOPE approach.

With OWL-S, in the above example, the functional and semantic characteristics of the offered web service (video spatial scaling) are present, but the performance characteristics are absent. Therefore, the conventional OWL-S service matching algorithms, rarely consider service performance issues. The conventional OWL-S service matching algorithms attempt to resolve the question of whether a special service requirement can be correctly executed by a web service, but do not try to decide whether the selected service can provide the best performance of the possible matching services.

The present invention enhances the service description of OWL-S with nonfunctional characteristics, and also provides a service matching algorithm, which not only can execute functional service matching, but also can perform selection of the optimal service based on performance and, thus provide the best quality of service. The functional description of a web service means the intrinsic interface information in the Service Profile, such as IOPE (Input, Output, Precondition, and Effect) parameters. The nonfunctional description mainly focuses on the performance and context characteristics of a special Web Service, such as response time, use fee, reliability, CPU capability, memory size, etc. Correspondingly, service matching based on a functional description can decide whether a service can meet a special service requirement, while optimal service selection based on a non -functional description can select the best one in the available services, which meet the functional requirements.

A device (providing a service) also has a Device Context Model (DCM), which is used to describe the capabilities the device supports in terms of the hardware, software and networking capabilities that the device has, and other context information accompanying with this device. For example, a DCM may include its power resource, CPU capability, network interfaces, memory capacity, location, owner, authenticated users, current status (on/off, idle/busy), etc.

The service ontology of the present invention and the DCM help the system to semantically match services and select the best device from among a plurality of devices that provide the desired service for the overall best quality of service. For example, a mobile phone and a computer provide the same video rendering service, however, the AC power, CPU capability, screen size, etc. of the computer makes it a better choice for a high-quality movie. This example is between a mobile phone and a computer. There may be other choices that would be better than the computer. In the present invention, the first step would have selected all of the devices (service providers) providing the requested service. The second step would have inspected the enhanced ontology of the present invention to determine any required performance characteristics (OWL-S enhanced with non-functional characteristics). The required performance (non-functional) characteristics are then matched against (compared to) the DCM of the devices providing the required service (results of step one).

With the enhanced OWL-S ontology, an exemplary two-step service matching algorithm is introduced for service selection, according to a special (non-functional, performance) service requirements, as illustrated in Fig. 4.

Functional service matching is executed first as it would be in conventional service provider matching. In this step, the devices (service providers) whose service descriptions match the IOPE are selected. That is to say, for a certain service requirement, only the services which can support the functional service requirements (in IOPE form) can be chosen.

Functional service matching computes the degree of semantic matching for a given service requirement and available service descriptions by applying five different filters:

EQUAL, PLUGIN, SUBSUME, SUBSUMED BY, and FAILURE.

The corresponding semantic matching degree SMD is set to special integer value according to the filter result according to the following formula: VIN_S3IN_R IN,≡IN_R A VOUT_R30UT_S OUT_R≡ OUT_S EQUAL

VIN_S3IN_R IN_S≥IN_R A \/OUT_R30UT_S OUT_R≤ OUT_S PLUGIN

SMD{R, S) = VIN_S3IN_R IN_S≥IN_R A \/OUT_R30UT_S OUT_R≥ OUT_S SUBSUME

VIN3IN_B IN_S≤IN_R A \/OUT_R30UT_S OUT_R≥ OUT_S SUBSUMED BY

1 fails to meet above FAILURE

≡: Semantic equivalence; < : Semantic consumed-by; > : Semantic consume

The second step is the selection of the optimal device (service provider) of the requested service. In this step, the services chosen by functional service matching (step 5 one above) are further filtered, so that the optimal service provider can be selected. The

second step is based on the performance and context parameters. To separate the matching result of the first step, the matching value of the optimal selection is normalized in the interval [0, 1].

In the enhanced OWL-S service requirement, a group of weight values0 [ λ_ι , λ₂, ..., λ_η ] is defined, in which a weight value corresponds to a special performance

and context parameters. These weight values meet the following condition:

4 + λ₂ + ... + λ_η = 1

Each weight value is determined by the significance of its context. The more important a context parameter is, the greater its weight value is set. For example, when the cost is5

considered to be more important than other context, the weight value of cost can be set much larger than other weight value.

Also in the enhanced OWL-S service requirements, upper bounds or lower bounds for requirements for special context and parameters are set. Upper bounds specify the highest or maximum value that the service requirement prefers. The lower bounds0 specify the lowest or minimum value that the service requirement requires. For example,

for a service requirement, the upper bounds can be set for response time or use fee and the lower bounds can be set for CPU capability or memory size. Within the specified upper and lower bounds, a SSP (service satisfying parameter) is calculated to indicate (represent) the service satisfying parameter with the following three functions. Function 1 is used when only the upper bound T" is set for a special context /^' (e.g. response time, cost, etc). With the context value t_i , the SSP can be calculated as:

Function 2 is used when only the lower bound ⁱ is set for a special context

(e.g. CPU capacity, memory size, etc). With the concrete context value ^ , the SSP can be calculated as:

Function 3 is used when both the lower bound T ^iL and the upper bound Ί a special context ¹ . With the context value ^t , the SSP can be calculated as:

A total optimal parameter is calculated to represent whether the service is optimal or not, according to the following function.

SSP_TOTAL = ^SSP^SSP, + ... A_NSSP_N

With the result of the two step matching, a total ranking value for a special service can be determined by calculating the sum. Its integer portion represents the function matching result, and its decimal portion presents the optimal service selection step. The service with the greatest (largest, biggest, highest) ranking value is selected. This is the service provider which can best provide the requested service meeting the functional and non-functional (e.g., performance) requirements.

Figs. 1 and 2 show a decentralized and a centralized directory service respectively. The present invention uses the known architectures but adds a non-functional (e.g., performance) component. That is the present invention may be implemented in and executed by the service registry shown in Fig. 2 or the individual network components shown in Fig. 1. In the case of service registry implementation and execution, the service device (apparatus) can be any processing device having sufficient memory and processing power to perform the web service directory matching in accordance with the principles of the present invention. Similarly, for the network components of Fig. 1, the service device (apparatus) can be any processing device having sufficient memory and processing power to perform the web service directory matching in accordance with the principles of the present invention. Devices having such processing power and memory may include laptops, iPad/iPod type devices, personal digital assistants (PDAs), dual mode smart phones, mobile terminals, etc

Referring to Fig. 3 A which shows conventional OWL-S presentation of a spatial scaling service. Fig.3B is its expanded OWL-s presentation with context and performance characteristics.

Fig. 4 is a flowchart of the two step matching process of the present invention. At 405, conventional functional web service matching occurs (is executed). The results of this step include a listing of the located web services and a ranking of the various services and providers using a plurality of filters (e.g., five filters including EQUAL, PLUGIN, SUBSUME, SUBSUMED BY AND FAILURE). Once this step is performed, at 410, the non-functional (e.g., performance, cost, etc.) ranking and matching occurs (is executed, is performed). Included within this step is the inspection of the non-functional (e.g., performance etc.) parameters. The results of the optimal web service selection process of step two of the present invention may be a normalized value in the interval [0,1]. The various non-functional parameters are weighted such that the total value of the weights is 1. The user or process seeking the web service supplies the weights and applies the weights to the non-functional parameters supplied in the OWL-S enhanced ontology of the present invention. A service satisfying parameter (SSP) is calculated based on upper and/or lower bounds specified by the device seeking the web service. The SSP may be used to bound a range of performance characteristics acceptable to the device or process seeking the web service. Step two then selects the highest ranking web service.

Fig. 5 illustrates the enhanced OWL-S semantic representation. The present invention is directed to matching and ranking sought web services using the context (model) non-functional parameters illustrated at the right of Fig. 5.

The present invention may be applicable to other fields, which use web service to advertise, discover, and compose services that may be invoked (executed) by users.

It is to be understood that the present invention may be implemented in various forms of hardware, software, firmware, special purpose processors, or a combination thereof. Preferably, the present invention is implemented as a combination of hardware and software. Moreover, the software is preferably implemented as an application program tangibly embodied on a program storage device. The application program may be uploaded to, and executed by, a machine comprising any suitable architecture. Preferably, the machine is implemented on a computer platform having hardware such as one or more central processing units (CPU), a random access memory (RAM), and input/output (I/O) interface(s). The computer platform also includes an operating system and microinstruction code. The various processes and functions described herein may either be part of the microinstruction code or part of the application program (or a combination thereof), which is executed via the operating system. In addition, various other peripheral devices may be connected to the computer platform such as an additional data storage device and a printing device.

It is to be further understood that, because some of the constituent system components and method steps depicted in the accompanying figures are preferably implemented in software, the actual connections between the system components (or the process steps) may differ depending upon the manner in which the present invention is programmed. Given the teachings herein, one of ordinary skill in the related art will be able to contemplate these and similar implementations or configurations of the present invention.

Claims

1. A method, said method comprising: performing functional web service matching of web services and providers; and performing non-functional web service matching and ranking of the web services and providers resulting from said first performing step.

2. The method according to claim I, wherein said second performing step further comprises: inspecting non-functional parameters;

accepting weights for said non -functional parameters;

accepting at least one bound for said non-functional parameters; calculating a service satisfying parameter for each non-functional parameter responsive to said bound;

applying said weights for said non-functional parameters to each calculated service satisfying parameter;

calculating a total service satisfying parameter; and

selecting a highest ranking web service responsive to said total service satisfying parameter.

3. The method according to claim 2, wherein a total value of said weights of said non-functional parameters is 1.

4. The method according to claim 2, wherein if an upper bound is accepted then said service satisfying parameter for said non-functional parameter is calculated as Fl .

5. The method according to claim 2, wherein if a lower bound is accepted then said service satisfying parameter for said non-functional parameter is calculated as F2.

6. The method according to claim 2, wherein if both an upper bound and a lower bound are accepted then said service satisfying parameter for said non-functional parameter is calculated as F3.

7. An apparatus comprising: means for performing functional web service matching of web services and providers; and means for performing non-functional web service matching and ranking of the web services and providers resulting from said first performing step.

8. The apparatus according to claim 7, wherein said second performing step further comprises: means for inspecting non -functional parameters;

means for accepting weights for said non-functional parameters; means for accepting at least one bound for said non -functional parameters; means for calculating a service satisfying parameter for each nonfunctional parameter responsive to said bound;

means for applying said weights for said non-functional parameters to each calculated service satisfying parameter;

means for selecting a highest ranking web service responsive to said total service satisfying parameter.

9. The apparatus according to claim 8, wherein a total value of said weights of said non-functional parameters is 1.

10. The apparatus according to claim 8, wherein if an upper bound is accepted then said service satisfying parameter for said non-functional parameter is calculated as Fl .

11. The apparatus according to claim 8, wherein if a lower bound is accepted then said service satisfying parameter for said non-functional parameter is calculated as F2.

12. The apparatus according to claim 8, wherein if both an upper bound and a lower bound are accepted then said service satisfying parameter for said non-functional parameter is calculated as F3.

13. The apparatus according to claim 7, wherein said apparatus is a network component in a decentralized network architecture.

14. The apparatus according to claim 7, wherein said apparatus is a service registry component in a centralized network architecture.