Glen Dobson: 2 nd Year PhD Report

Transcription

1 Glen Dobson: 2 nd Year PhD Report Glen Dobson Lancaster University g.dobson@lancs.ac.uk Supervisor: Ian Sommerville Abstract Since my first year PhD report I have been involved in the creation of an ontology for QoS in Service-Centric Systems. This report details the development of this ontology and my plans for future PhD research in this area. 1. Introduction In my first year PhD report [1] I set out my area of research interest as Quality of Service (QoS) in Service Oriented Architectures (SOA). I proposed research into using the Web Ontology Language (OWL) [2] to build an ontology for use by software in the QoS/SOA field. I have now produced the basis for such an ontology. This work was undertaken as part of the Dependable Service-Centric Computing [3] activity of the Dependability Interdisciplinary Research Collaboration (DIRC) [4], with the aid of Russell Lock in particular, as well as the advice of others on the project. In this report I detail what has already been done towards the creation of the ontology (Section 3), and what my plans are for building upon the ontology as part of my PhD (Section 4). Before this, in the following section, some background detail on OWL is given, as this was absent from my first year report and is necessary context for the following sections. 2. OWL An ontology is a machine interpretable description of the terms which exist in some domain and the relationships between them. The aim of an ontology is to give machines some depth of domain understanding beyond the syntactic. The degree to which this is achieved depends upon success in eliciting domain knowledge and representing it in some formal way. Numerous ontology languages have developed to facilitate such formal description, of which OWL is a relatively new example. Its emphasis is on providing a way of distributing and sharing ontologies via the web. To this end, OWL is built upon RDF (the Resource Description Framework) [5]. RDF is an XML (extensible Markup Language) [6] vocabulary for describing resources on the web, and as such has certain commonalities with ontology languages. Statements about resources in RDF are expressed using triples, which consist of: The resource being described (the subject) The specific property (the predicate) The value of that property for that resource (the object) RDF vocabularies can be specified using RDF Schema (RDFS). The chief concepts introduced for this purpose are Classes (i.e. the types of things which can be described) and their Properties. OWL builds upon RDF and RDFS to add a greater level of expressivity and machine interpretability as well as providing formal semantics for the language. It gains from RDF the ability to distribute an ontology across many systems (as resources are identified and accessed by URI). An OWL ontology consists of Classes and their Properties. Instances of OWL Classes are called Individuals. OWL Individuals are very much like resources described using RDF although they may have further OWL-specific facts expressed about them - namely: That the URI indicated and some other URI actually refer to the same Individual (the OWL sameas construct)

2 That the URI indicated and some other URI do not refer to the same Individual (the OWL DifferentFrom construct) That each URI in a specified list refers to a different Individual (the OWL AllDifferent construct) An OWL Class is a specialisation of RDFS Class, which can be specified in new ways beyond simply stating its name. These added means of class description are: Enumeration of all Class members (i.e. OWL Individuals) (using the OWL oneof construct.) As an anonymous Class of all Individuals that satisfy a Property restriction (using the various OWL value and cardinality constraint constructs) By combining existing Classes using set operators (the OWL intersectionof, unionof, and complementof constructs) These Class descriptions can be nested to create arbitrarily complex new descriptions. Descriptions can then be combined into a Class definition using the OWL subclassof, equivalentclass and disjointwith constructs. The Class definition specifies all of the necessary and/or sufficient conditions for Individuals to be members of a Class. A Class can therefore be viewed as defining a set of individuals (the class extension). A key feature of OWL is that it takes the form of a Description Logic (DL) [7] and therefore has formally stated semantics. A Description Logic is a logic that focuses on concept descriptions as a means of knowledge representation and has semantics which can be translated to first-order predicate logic. The nature of DLs means that classification and subsumption relationships can be automatically computed by a reasoner. In actual fact, there are three species of OWL. Two of these species, OWL-DL and OWL-Lite, correspond to decidable Description Logics. Decidable, in this context, refers to the fact that it is possible to determine, for any DL expression, whether or not it is provable (and therefore whether a reasoner can be created for that DL). OWL-Lite is simply a cutdown version of OWL-DL to allow for simpler implementation. Its cut-down nature also means that reasoning on it is usually faster than OWL-DL. The final OWL species, OWL-Full, adds features to OWL-DL but in doing so violates the constraints of Description Logic reasoners. In OWL reasoning, an open world assumption is made. This means that no assumptions are made about anything which is not asserted explicitly. This contrasts with the closed world assumption used in data modeling, where anything unstated is taken to be false. An individual may also be a member of many Classes. Because classifications can be inferred, the creator of an Individual does not need to be aware of all possible Classes into which the Individual may fall at the time of creation. Instead, all Classes of which it is a member can be inferred by a reasoner. 3. QoSOnt a QoS Ontology The ontology created as part of the DIRC project has been given the name QoSOnt [8], [9], [10]. Its aims are to provide a standard QoS vocabulary, an extensible taxonomy of QoS attributes and metrics, to provide a means of QoS requirements matching using standard OWL reasoners, as well as to represent as much knowledge about QoS as possible. Once such knowledge is formally represented it should be possible to create software which demonstrates the benefits of the machine understanding of QoS High Level Structure of QoSOnt The QoSOnt ontology is modular in nature in that it is structured as a set of interconnected, smaller ontologies. Ontologies in higher layers specialise and build upon those from lower layers. The ontologies fall into three logical layers as shown in Figure 1. Usage Domains Attributes Network Dependability Base QoS Service Performance Units Time Figure 1. Layers of the ontology

3 We use the term attribute to refer to a general QoS property (e.g. dependability, reliability, performance) and metric to refer to a specific way of measuring an attribute. Metric, Attribute and other basic QoS concepts are defined in the base ontology. Concepts specific to some attribute can then be built into separate ontologies on top of the base concepts. We currently have a relatively complete ontology of dependability concepts based upon [11]. We choose not to define specific metrics here as we do not wish to tie the generic concepts of dependability to specific ways of measuring dependability. We therefore have a separate ontology of actual metrics. We also have a less complete performance ontology, which plays an analogous role to the dependability ontology shown in Figure 1. One reason for creating an ontology for a particular attribute is to allow the concepts that metrics of that attribute refer to to be defined. For instance, the concept "failure" comes in useful in order to define probability of failure on demand (POFOD) and allows POFOD to be defined for specific types of failure rather than just referring to all failures. A further lightweight ontology ties the generic concepts of the base ontology to web services in particular. This is done by defining relationships between QoSOnt and OWL-S [12] an existing ontology for web services. This essentially allows Metrics and Attributes to refer to the OWL-S Service Class and subclasses of QoSOnt's Metric Class to be used as OWL-S ServiceParameters. A Requirements Matching tool for web services, which makes use of the ontology, has also been developed. I will say no more about this tool (or QoSOnt) here as a detailed picture is given in the papers in the appendix The Base QoS Ontology The base QoS ontology represents a minimal set of generic QoS concepts. We introduce the concept of a QoS attribute, and its unmeasurable and measurable subclasses. In using the ontology it is entirely optional whether one chooses to use these sub-classes or create one's own. Ontologies allow multiple inheritance, so many different classifications are possible. Indeed, a QoSOnt specification will always subclass something from the attribute layer as well as from the domain layer (e.g. to say that what is being referred to is the attribute reliability, and it is specifically the reliability of service X). Unmeasurable in this context relates to attributes which cannot be measured from a given viewpoint. An example of this could be adherence to a particular standard. Anything which is measurable has a metric. A metric represents one way of measuring a specific QoS attribute. It must result in a numerical value and must be calculable in practice as well as theory. For instance, a statement that a service has transactional throughput of 1000 transactions per second can be falsified by a single party (be they a client, provider or monitoring service) but cannot generally be measured by a client or third party as they have no access to the traffic statistics for the service. Measurable attributes have one or more associated metrics. At this level in the architecture we do not prescribe individual metrics; these are defined in more specific attribute ontologies. We define a metric to consist of a description, an acceptability direction and zero or more values. The acceptability direction indicates whether higher or lower values are preferable for the metric (e.g. A low probability of failure on demand is more desirable). It must be remembered that these classes can be extended or constrained by their subclasses, so being over-specific at this base level is undesirable. A metric value has one or more associated units. In many cases a numerical value alone cannot be understood without its unit type (e.g. You need to know whether time to complete is quoted in seconds, microseconds, milliseconds, etc.). Many metrics in QoS involve time, which is why we have included the time ontology in QoSOnt. Other types of physical quantity are rare in QoS but the structures are there to model them when they are required. Percentages can also be modelled as units in QoSOnt. This gives the ability to understand that availability of 0.99 is the same as availability of 99% for instance. For metrics which have values with simple types (e.g. alphanumeric strings or integer counts) a new datatype property would be included in that sub-class of Metric The QoSOnt Attribute Layer Figure 2 shows some attributes from both the dependability and performance ontologies (prefixed by d: and p: respectively).

4 Figure 2. Example Classes from the attribute layer The full dependability ontology is largely based upon the taxonomy defined in [11]. It not only includes the ability to represent dependability attributes but also, for instance, means of achieving dependability and dependability threats. These latter may be of less relevance to QoS but will find use in other forms of specification. There is therefore an overarching concept of dependability, as shown in Figure 2. The ability, given a particular Metric, to find the QoS attribute it measures through the ismetricof Property allows other Metrics for that attribute to be found. With the overarching concept of Dependability, a further step may be made through the ispartofdependability Property. This Property gives access to the Dependability Class and therefore all information relevant to dependability (threats, means, etc.). This shows how the attribute layer provides a good point at which to provide hooks to non-qos concepts. Doing so allows the integration of ontologies for further types of system description. As well as the reusable dependability (or other attribute) ontology, a further ontology contains actual metrics (e.g. probability of failure on demand, mean time between failures, mean availability, etc.). It is this level of detail which is perhaps the most important; as it is only once specific metrics are added that QoSOnt is usable for QoS specification. Organisations working together are likely to have their own metrics ontology which they can use whilst still gaining the benefits of the underlying QoSOnt The QoSOnt Usage Domain Layer Ontologies in the usage domain layer link QoS to a particular class of system. Currently QoSOnt supports networks and services as types of system that QoS may refer to. As with all layers, this can easily be expanded upon. The most important part of the service ontology simply links the concept of QoS attribute and service. Since we are working in the web services arena we use the Service class from the OWL-S ontology. Our ontology can also enhance the OWL-S ontology by providing concrete Classes to act as its ServiceParameters. An example is shown in Figure 3. Figure 4. Example of the QoSOnt/OWL-S link The prefixes in the figure refer to the following namespaces: s: OWL-S Service, p: OWL-S Profile, bqos: QoSOnt Base QOS, sqos: QoSOnt Service QoS, dm: DIGS metrics (Which contains our dependability metrics in the Attribute Layer). The solid lines labelled io indicate instance of. The instances are the part which would actually be visible in a specification. The Service instance (ephemerisservice in the figure) would be the point of entry to the OWL-S specification. The figure shows that a service presents a profile and that a profile has a parameter. Also depicted is how such a service parameter can make use of QoSOnt in this case by specifying a ServiceParameter which is Probability of Specific Failure on Demand. The unusual terminology is to distinguish it from probability of any failure on demand. Specific Failure refers to the fact that it represents the probability of one particular service failure defined using the dependability ontology. As well as service-specific, certain QoS attributes are also operation-specific (e.g. time-to-complete, accuracy) and therefore reference the OperationRef class from OWL-S. Other attributes, e.g. reliability, may be best modelled as workflow specific since they are specific to a usage pattern. OWL-S provides a Process class which is much like a workflow. However it would be preferable to also be able to reference other types of workflow definition (e.g. WS-BPEL). A provider (or QoS measurement service) publishes QoS data as part of their OWL-S description or directly using QoSOnt alone. The former is the

5 preferred option as it gives a standard way of referring to the service, operation, etc. in question. It also provides a single point of access for the complete specification SQRM a QoSOnt Application To demonstrate the use of the ontology, and aid in its evaluation, a prototype tool for service discovery and selection based upon QoS requirements has been developed. We have named the tool the Service QoS Requirements Matcher (SQRM). SQRM is designed to showcase a range of different situations in which QoSOnt can be utilised within the service domain. The tool supports the service discovery, requirement Specification and Service Differentiation/Selection. The tool may be used at design-time to specify initial QoS requirements (and find matching services) or to narrow down a set of services already selected using some other method. The code could also form the basis for an API to allow QoS-based service selection to be performed dynamically at runtime. The first stage SQRM is designed to undertake is the initial discovery of services. UDDI is used for this purpose. We do not attempt to address the well-known problems with UDDI registries (un-vetted/incorrect information etc), but instead use UDDI purely as one way to identify services worth further investigation. Clients query the repository via keyword search (see Figure 4). For each service the user selects the tool retrieves a QoSOnt document linked to the service entry (provided this information has been published in the registry or is available through the WSDL). In SQRM, a QoS requirement is basically a predicate (represented in XML), the truth value of which depends upon the asserted facts in the QoS descriptions of the client selected services. The subjects of the predicates are instances or Classes defined in QoSOnt. In contrast to requirements, the provider's description of their QoS capabilities consists of asserted propositions. These often simply say "QoS Metric X has been measured to have value Y". Requirement predicates are visualised as a tree the leaves of which are Values or Classes of Metric expressed in QoSOnt. The inner nodes are logical and arithmetic operators such as AND/OR. These allow expressions of the type shown below to be inputted: Mean time to Failure > 10 days AND Mean Availability > 98% Figure 5 shows a screenshot of the current implementation of our SQRM requirement specification environment. The requirements created can be matched against the QoS data (i.e. QoS adverts or QoS measurements) for the services discovered. The results of matching can then be browsed by a user (see Figure 6) to help them decide which service/s they wish to make use of or which they wish to negotiate an SLA for. The ontology becomes useful (for example) in situations where metrics are not defined in the same units between client and provider; this allows a tool to take into account and convert types with the aid of the ontology. The requirements matching phase takes files from both client and provider(s), analyses, and provides feedback to the client on the compatibility of the requirements and capabilities documents. Figure 4. Service Discovery in SQRM Figure 5. Requirement Creation in SQRM

6 Figure 6. Requirement Matching in SQRM 4. QoSOnt Research Plan The aims of QoSOnt were mentioned at the start of Section 3. The aim of providing a shared vocabulary for QoS has been achieved to some extent. However, only core QoS concepts and the area of dependability have really been expanded fully. The latter is by design: we chose not to develop a complete ontology, but to demonstrate what would be involved in doing so by concentrating on one specific attribute. This applies equally to the aim of creating a QoS taxonomy. A more complete ontology could be created with input from other parties. Even then, as with any standardisation process, the ontology would not serve everyone s needs. However, it is always possible for groups to agree their own custom extensions to QoSOnt. The aim of using OWL reasoners to perform requirements matching has unfortunately frustrated us. One of my aims is to achieve this, as discussed in the following Section. The aim of representing deeper (and broader) knowledge about the QoS domain and demonstrating the advantages of this in software has also shown little progress. I discuss some possibilities in this regard in Section 4.2. Section 4.3. discusses 4.1. Convert QoSOnt to pure OWL One of the main difficulties encountered in the development of QoSOnt was that datatyping support in OWL is poor. Unlike its predecessor, DAML+OIL, OWL does not have its own types but relies purely upon RDF datatypes, which in turn rely purely upon XML datatypes. Despite this, the OWL specification is unclear on how to reference custom XML types [13]. This has led to us being unable to perform QoS requirements matching in the way we desired. We wished to perform requirements matching using a standard OWL reasoner in a way much akin to the approach used by DAML-QoS [14]. However, not only does DAML-QoS use the outdated DAML+OIL but it misuses the cardinality constraint as its means of expressing QoS constraints (i.e. rather than saying I want all metrics with values greater than 99 it actually says I only want metrics with more than 99 values ). The approach I wished to take in QoSOnt was to use the allvaluesfrom construct from OWL, which translates to universal quantification in predicate logic. A requirement (R) would therefore essentially consist of the set of all Xs with values from U, where U would be a user defined XML datatype such as all floats from A QoS advertisement, or measured bound would have essentially the same form. A straightforward inference of the subsumption relationship between the two classes could then indicate whether the requirement was matched by the advert/measurement in question. For instance if the provider was advertisting (A) that they could provide metric X at levels then the subsumption relationship would show that A was a subclass of R meaning that the requirement was matched. This interpretation of the subsumption relationship follows directly from the literal interpretation that all individuals meeting the requirement R are also part of the set of individuals the provider is capable of providing. If A stated a capability of the situation would clearly be reversed. This is not to say that all requirements (and adverts) should be simple bounds. They could still be arbitrarily complex (within the bounds of OWL s descriptive capabilities, as explained in Section 2). However, the most common form of requirement would probably involve the intersection of a Metric Class with an allvaluesfrom property restriction. A complete set of requirements would then be combined using intersection and union constructs. It is interesting to note that XML schema datatypes can be derived by a number of means including by regular expressions (for types derived from strings). This means that requirements on non-numeric (qualitative) metrics could still be matched using the same means in many cases. At the time that QoSOnt was developed reasoners simply did not support quantification over custom XML datatypes. Therefore we used a separate XML language to express requirements and custom matching code. However, the situation is beginning to change, and the Pellet reasoner [15] in particular now has much

7 more extensive support for custom XML datatypes. Therefore, my immediate aim is to reimplement the requirements concepts in QoSOnt to use OWL alone. Unfortunately, Pellet uses the DAML+OIL form of referencing XML datatypes (see [13]). This cannot be edited directly in the Protégé ontology engineering environment (in fact this tool has now introduced a separate, entirely proprietary way of creating numeric ranges). Thankfully this is only a minor annoyance, as requirements will generally be created from tools such as our own. The Jena [16] library which is already used in the current code base handles DAML+OIL style referencing. With this in place it might be interesting to investigate the use of this form of requirements matching for qualitative requirements, as described above Represent More Knowledge about QoS In the papers in the appendix we talk about the conversion of metric units (e.g. if a requirement is stated in different units to a measurement) but have yet to demonstrate this. Moreover, the current representation of conversion rates requires externally held understanding of their use. The conversion rates are held in the ontology but appropriate code needs to be written to know that, e.g. 60 seconds = 1 minute. The current approach also fails to allow for more complex conversions such as C = ( F-32)*5/9 (although this particular example is obviously unlikely to appear in a QoS metric). The related area of inferring composite metrics from their components could also benefit from a way of expressing arithmetic in a machine understandable way, e.g. availability can be computed as MTBF/(MTBF + MTTR) and so can be inferred in MTBF and MTTR (Mean Time Between Failures and Mean Time to Repair respectively) are stated. OWL on its own has no built-in arithmetic operators, and moreover does not allow the kind of inference required to state that if a metric (M) is quoted with a value of 60 seconds and a seconds to minutes conversion rate exists in the knowledge base then it is equivalent to M also being stated to have a value of 1 minute. The Semantic Web Rules Language (SWRL) [17] allows for exactly these things however. SWRL basically extends the set of OWL axioms (i.e. what are termed Class descriptions in Section 2) to include Horn-like rules (based upon RuleML [18]). These rules allow implication between a set of antecedent conditions and a set of consequent conditions. One of my aims is therefore to investigate the use of SWRL for expressing conversions. There are issues about reasoner support for OWL and SWRL together but this should not be too difficult to overcome (although it may involve using more than one reasoner in the prototype system). The other kind of QoS knowledge we have begun to represent in QoSOnt is the effect of different types of composition on metrics. Currently this has a similar form to conversion rates in that the data is in the ontology but code contains the real understanding. Since many of the interesting QoS-based decisions are to do with workflows it will be interesting to investigate semantically marked up workflows and perhaps use a SWRL-based approach to infer aggregate QoS and make dynamic decisions based upon QoS at a given time. Given that SWRL, rather than OWL alone, may be used for all of the above this leaves the open question of what knowledge, other than the ability to perform QoS requirements matching can be represented (and demonstrated to be machine understood ) in OWL? 4.3. Make the Ontology Accessible/Usable One of the main problems with an ontology is that it is meant to be understood by machines. If it is handed to a human-being it appears to be a somewhat cryptic, static representation of some facts about QoS. There is little point in an ontology without software that uses it. However, there is also the problem that ontologies are not widely understood by software engineers. High level APIs for software developers (beyond those which map directly to OWL concepts such as Jena) are therefore desirable. These should be couched in the terms from the domain rather than the terms of ontology engineering. One of my aims is therefore to develop a QoSOnt API. This should facilitate developing code for populating the ontology (i.e. creating OWL Individuals representing, e.g. requirements, measured data, SLAs, QoS advertisements). It should also provide an abstract interface to useful reasoning capabilities, means of adding extensions to the ontology and so on. Clearly humans interact with many parts of this software. The issue of suitable abstractions for human computer interfaces might also be worth considering. In the QoS world there is also the interface with traditional documents to consider. How the ontology maps onto human readable documents (SLAs, requirements documents, etc.) also needs to be considered. As discussed in my first year report the

8 ontology could also act as an Interlingua. Translating to and from the QoS languages used in legacy systems is also worth considering (and providing a translation API) Other Potential Research Avenues Other research avenues I may pursue are the integration of our fault tolerance approach [19] and QoSOnt. This would allow, e.g. for dynamic selection of equivalent services based upon their QoS, e.g. a workflow could be made adaptive to tweak performance, cost, etc. The other thing which I want to give deeper thought to is what clients actually want to ask about QoS and what kind of guarantees (if any) they would like. This involves two main areas. Firstly it involves modeling alternate metrics for, e.g. availability in QoSOnt and showing how they can be used, how they complement each other/confuse the user. Secondly there is a link with the HCI issues mentioned in Section 4.3. I feel that most people really just want to say I want operation X to work when I call it (with usage profile P), and I want X to complete within T seconds (at least 99% of the time), and I want to be able to call X 100 times per second. Obviously there are numerous variations and caveats that can be added to these basic forms but this might lend itself to a very high level way of investigating QoS for a group of services.

9 5. Plan of Work for next Year 6. References [1] Glen Dobson, PhD 1 st yr report, October 2004, pdf [2] W3C, Web-Ontology (WebOnt) Working Group (Closed), [3] Dependable Service-Centric Computing (DSCC), [4] DIRC, Interdisciplinary Research Collaboration in Dependability, [5] W3C, Resource Description Framework, [6] W3C, Extensible Markup Language (XML), [7] Franz Baader, Ian Horrocks, and Ulrike Sattler, Description logics for the semantic web, in Künstliche Intelligenz, vol. 16, No. 4, pp , [8] Glen Dobson, Russell Lock, Ian Sommerville, Quality of Service Requirements Specification using an Ontology in SOCCER Workshop, Requirements Engineering 05, 2005 [9] Glen Dobson, Russell Lock, Ian Sommerville, QoSOnt: a QoS Ontology for Service-Centric Systems in Euromicro SEAA 05, pp , 2005 [10] Glen Dobson, Russell Lock, Ian Sommerville, QoSOnt: an Ontology for QoS in Service-Centric Systems in UK e- Science AHM 05, 2005 [11] Jean-Claude-Laprie, Brian Randell, Carl Landwehr, Basic Concepts and Taxonomy of Dependable and Secure Computing, in IEEE Transactions on Dependable & Secure Computing. vol. 1, No. 1, pp [12] DAML, OWL-S, [13] Jeremy J. Carroll, Jeff Z. Pan, XML Schema Datatypes in RDF and OWL, [14] Chen Zhou, Liang-Tien Chia, Bu-Sung Lee. "DAML- QoS Ontology for Web Services," icws, p. 472, IEEE International Conference on Web Services (ICWS'04), [15] Pellet OWL Reasoner, [16] Jena Semantic Web Framework, [17] Ian Horrocks et al, SWRL: A Semantic Web Rule Language Combining OWL and RuleML, [18] RuleML, [19] Glen Dobson, Stephen Hall, A container-based mechanism for service fault tolerance, Results/ServiceFaultTolerance.html

10 Appendix Related Publications The following is a list of papers on QoSOnt which have been published: Glen Dobson, Russell Lock, Ian Sommerville, Quality of Service Requirements Specification using an Ontology in SOCCER Workshop, Requirements Engineering 05, Glen Dobson, Russell Lock, Ian Sommerville, QoSOnt: a QoS Ontology for Service-Centric Systems in Euromicro SEAA 05, pp , Glen Dobson, Russell Lock, Ian Sommerville, QoSOnt: an Ontology for QoS in Service-Centric Systems in UK e-science AHM 05, Glen Dobson, Russell Lock, Ian Sommerville, Addressing the Contract Issue, Standardisation for QoS in echallenges 05, Glen Dobson, Russell Lock, Ian Sommerville, Developing an Ontology for QoS in 5 th Annual DIRC Research Conference, pp , As these papers represent an evolving body of work, only the most recent has been included here. However, the interested reader can find all of the above online at the URLs given.