This is an ontology designed for the QoS-Aware service discovery and measurement. We design the OWL-QoS ontology together with its QoS-Aware services discovery framework. This new ontology is designed as a complement for OWL-S ontology to provide QoS-Aware service discovery and measurement service. In our model, three concept layers (profile layer, property layer and metrics layer), the profile individual and the metrics individuals help to separate the design duties for partners. The matchmaking algorithm for QoS property constraints with multiple matching degrees is presented. Well-defined Metrics can be further utilized by measurement organizations to check whether the service provider conforms to the agreement. For different usage phases of the OWL-QoS ontology, we design the QoS matchmaking framework, the measurement framework and the measurement code handler. Based on the ontology level, semantics in the specification helps to achieve better interoperability, automation and extensibility. To prove the applicable of the system in real e-business world, we test the prototype framework and find its potential usage in real Web service environment.
The ontology's overview diagram is shown in figure 1. SLA ontology defines the schema for a normal service level agreement. Its individual defines the instance of an agreement individual. QoS profile ontology defines the constraints of a service's QoS properties. It describes certain service level objectives and it can be used for service discovery purpose. Its individual is defined by measurement partner for monitoring purpose. Metrics ontology defines a library of common QoS metrics.
| Figure 1 | |
The metrics' architecture and its measurement correspondence is shown in figure 2. Step 1 (The service discovery phase): only Metrics ontology is required, which defines a reusable metrics library. Step 2 (The SLA definition phase): the metrics individuals are defined by the measurement partner after the signing of the SLA; Step 3 (The runtime measurement phase): the measurement stubs will be generated and deployed by the measurement partner.
| Figure 2 |  |
Figure 3 shows an living example of QoS profile. The left side of the figure defines the QoS profile, which represents a service level objective, and some used Metrics. The right top side is the definition of QoS profile's individual by the measurement partner. The right bottom side of the figure is the definition of the metrics' individuals by the measurement partner, which will be used to generate the measurement handlers and collectors.
| Figure 3 |  |
Figure 4 shows a sample architecture of the measurement framework for Web services.
| Figure 4 |  |
The core ontology definition files are (to be updated...):
| Filename | Description |
|---|---|
| ServiceQoS.owl | provides defines a list of basic classes for the profile definition. |
| QoSMetrics.owl | defines the properties definition, sample metrics library definition and sample function definitions. User can easily extend the metrics library, or define their own functions according to the sample. |
The files SLOProfile.owl, SLOProfileIndiv.owl,and SLOProfileMonitor.owl are examples of using OWL-QoS ontology. Here is the short description for each of these files.
| Filename | Description |
|---|---|
| SLOProfile.owl | Define the QoS property constrains for the service discovery. The service provider defines these constraints. |
| SLOProfileIndiv.owl | Define the agreement for the discovered profile between provider and requester. It answers the "which, when" question of measurement. |
| SLOProfileMonitor.owl | Define the measurement details for the service. It answers "where, how" kind of questions for the measurement. |
The matchmaking algorithm for the service profile (from best to worst):
| Matching Level | Description |
|---|---|
| Subsume | If request R is super-concept of advertisement A |
| Exact | If advertisement R and request A are equivalent concepts |
| PlugIn | If request R is sub-concept of advertisement A |
| Intersection | If the intersection of advertisement A and request R is satisfiable |
| Disjoint | Otherwise it is disjoint |