IET Software Research Article
Ontology-based service discovery framework for dynamic environments
ISSN 1751-8806 Received on 26th April 2016 Revised 16th December 2016 Accepted on 4th January 2017 E-First on 21st February 2017 doi: 10.1049/iet-sen.2016.0048 www.ietdl.org
Furkh Zeshan1 , Radziah Mohamad2, Mohammad Nazir Ahmad2, Syed Asad Hussain1, Adnan Ahmad1, Imran Raza1, Abid Mehmood3, Ikram Ulhaq4, Arafat Abdulgader2, Imran Babar2 1Department
of Computer Science, COMSATS, Institute of Information Technology (CIIT), Lahore, Pakistan of Software Engineering, Universiti Teknologi Malaysia (UTM), Johor, Malaysia 3Department of Computer Science, King Faisal University, Saudi Arabia 4ICSL, Federation University, Australia E-mail:
[email protected]
2Department
Abstract: With all the recent advancements in the electronic world, hardware is becoming smaller, cheaper and more powerful; while the software industry is moving towards service-oriented integration technologies. Hence, service oriented architecture is becoming a popular platform for the development of applications for distributed embedded real-time system (DERTS). With rapidly increasing diversity of services on the internet, new demands have been raised concerning the efficient discovery of heterogeneous device services in the dynamic environment of DERTS. Context-awareness principles have been widely studied for DERTS; hence, it can be used as an additional set of service selection criteria. However, in order to use context information effectively, it should be presented in an unambiguous way and the dynamic nature of the embedded and real-time systems should be considered. To address these challenges, the authors present a service discovery framework for DERTS which uses context-aware ontology of embedded and real-time systems and a semantic matching algorithm to facilitate the discovery of device services in embedded and real-time system environments. The proposed service discovery framework also considers the associated priorities with the requirements posed by the requester during the service discovery process.
1 Introduction With recent advancements in the electronic world, particularly in the area of microprocessor technology, embedded systems are becoming increasingly popular. Devices such as mobile phones are being widely used in industry. Due to these advancements (power efficiency, processing power, storage and the usage of wireless networks, respectively), embedded systems and applications are becoming ever more complex. In-order to deal with this complexity, practitioners have adopted server and desktop technology in the development of embedded applications [1] and are using TCP/IP networks for the interconnection of embedded and real-time systems. Therefore, it is only natural to consider the use of web services for distributed embedded real-time system (DERTS). Web services provide a standard method of interoperation among applications running on different platforms. Services are platform-independent and can be accessed through the Internet. It is an evolved technology based on distributed objects [2] and can be used for the exchange of information between distributed applications in a heterogeneous environment [3, 4]. With an ever increasing number of services in a central repository, it is becoming more important to use an efficient and effective service discovery mechanism to locate the best service among several functionally similar services according to a user's requirement. Although different researchers have proposed very effective solutions, still a number of issues (priorities, value type direction, QoS and context-awareness) related to the efficient and accurate discovery of services have been overlooked. These issues, if considered, can play an important role in producing the most relevant and accurate results during the service matching process. Particularly, context-awareness can be used as an additional set of criteria in a selection process. However, due to highly interrelated nature of the context, it is difficult to represent it uniquely, as well as reuse and interpret it perfectly [5]. Moreover, to use context information effectively, it should be presented in an unambiguous way and the dynamic nature of embedded and real-time systems IET Softw., 2017, Vol. 11 Iss. 2, pp. 64-74 © The Institution of Engineering and Technology 2017
should be considered. As ontologies can be used for the explicit representation of concepts and the relationships that are held among entities, so context ontology can solve the problem of ambiguity. In this paper, based on the above mentioned limitations, we present a context-aware ontology for DERTS computing environments. We also introduce a framework which utilises this context ontology for modelling the user demand and a service discovery algorithm. The proposed service matching framework also considers the associated priorities, together with the requirements of the requester, during the service discovery process. The framework has the ability to extend and adapt the vocabulary used to describe services and to utilise the existing concepts defined in the context ontology for obtaining inferential benefits of logical reasoning over such descriptions. Such benefits are necessary within dynamic and evolving environments. The remainder of the paper is organised as follows. Section 2 presents an overview of related work. Section 3 explains the proposed context-aware ontology. Section 4 clarifies the service discovery framework. In Section 5, we present an algorithm using the proposed context-aware ontology and in Section 6, an evaluation is performed with experimental results. In Section 7, a comparison with related work is presented. Finally, we conclude the paper in Section 8.
2 Related work Context-awareness, along with formal context languages for specifying facts and inter-relationships for querying and reasoning on contextual information, has been a hot topic since the last decade. Recently, a number of semantic matching approaches have been developed, which try to address various limitations in the traditional discovery techniques. Before starting the review process, we consulted our domain experts and ask them to identify necessary requirements for a successful system. They highlighted
64
several and we initiated our literature review in the light of their remarks. A short overview of such approaches is as follows. In context broker architecture (CoBrA) [6] the context is represented as a context knowledge base [7]. During the application of CoBrA to the information tailoring problem, it was determined that ontologies need to be enriched in order to ensure an effective context knowledge base. CoBrA has not focused greatly on the notion of services and related aspects, such as user interfaces and mobile devices, on which these services are deployed. This has resulted in difficulties when multiple multidimensional contexts need to be modelled during the application process. Chen [8] has presented a standard ontology called standard ontology for ubiquitous and pervasive applications (SOUPA) for the support of knowledge-sharing and context reasoning for achieving interoperability among agents in the CoBrA. However, this work does not provide support for role, resources or resource usage level. The aspect-scale-context (ASC) model [9], expresses context information that can be used to characterise the aspect of any entity. However, this work lacks an effective representation of activity, resources and resource usage level, respectively. CONON is a context model proposed by Wang et al. [10] which is based on the idea of the ASC/CoOL approach. This is a two layered ontology. At the upper layer of the ontology, contexts such as location, person and activity have been presented; while at the lower layer, a domain-dependent abstraction has been presented. However, this work does not represent resources, resource usage level or activity schedule. In [11], Tan et al. have proposed a context model, multi-Sensor Oriented COntext Model (SOCOM) which classifies various types of context sources of a sensor along with the definition of the properties and the relationships among them. However, this work does not provide support for activity, role and resource usage level. CoDaMoS [12, 13] is a two layered context model. The notion of mobile services seems to be beyond the scope of this context model. This model does not offer explicit ways to limit the number of expressible contexts resulting in service discovery limitations. The work of Bandara [14] is one of several good works which address different kinds of requirements including: dynamicity, prioritisation, clarity, correctness, scalability and extensibility. However, it does not address many other limitations which leads to low precision results. Moreover, it does not take into consideration the value type directions. Although the above-discussed context-aware ontology-based semantic matching approaches address many limitations of the traditional service matching approaches, there are still certain issues that must be addressed for effective service discovery, matching and ranking, respectively. It is particularly necessary for any approach in the DERTS environment to consider role, resources, schedules, value type direction, as well as timeliness and user priorities during the service matching and ranking process (these are some of the requirements which were common, identified during the review of literature [5–28] and proposed by the experts). In addition, if no exact service matches, corresponding to user's defined criteria, are found the approach should return the approximate results to the user [14]. Based on this gap, we have focused on the following issues in this paper: • Use of context-aware ontology for the representation of the context knowledge of DERTS in an unambiguous way; in addition to the processing of context knowledge during the service matching process. • Design of a context-aware service discovery algorithm for embedded real-time systems to determine a service by considering the context information of that service. • An automatic services discovery framework for DERTS which should enable the user to create a query based on the ontological concepts so as to ascertain services from the service repository.
3 DERTS context ontology The effective description of services plays an important role in the semantic discovery of services. Therefore, a flexible and expressive approach is required that describes the services at a IET Softw., 2017, Vol. 11 Iss. 2, pp. 64-74 © The Institution of Engineering and Technology 2017
Table 1 Concept dictionary table Concepts activity bandwidth CPU device embedded device real-time device operating system
activity schedule execution time service QoS metric unit memory battery
resources context context provider location role mode actuator
conceptual level. Although several device description proposals which address many limitations have been published [6–13, 15, 16, 18], there are still certain issues that must be addressed for effective communication and interaction among devices. It is particularly necessary for any approach in the DERTS environment to consider issues of role, resources, schedules and timeliness to deal with heterogeneity and complexity for effective communication as discussed in the above section. Therefore, an upper level ontology was developed and, for the development of this ontology, a number of papers and manuals were reviewed. In the concepts selection stage, we used the term ‘weighting technique’ [18] along with the following formula (each time a concept was repeated we increased the score of that concept by one. Finally, the concept with above average score were selected). Table 1 provides the list of a few of these concepts. AvgConceptScore =
Σ ConceptScore Σ Concepts
Fig. 1 presents a context-aware ontology for DERTS; while Fig. 2 shows a conceptual UML representation of the most relevant classes of the ontological model along with the relations that hold among them. For the development of this ontology we have used METHONTOLOGY [20] methodology guidelines since they are based on some of the sound software engineering ideas which can improve ontology applicability. The key benefit of the proposed context ontology is that it can provide smooth interaction between users and DERTS since it concisely describes the properties of DERTS. Moreover, this ontology enables both humans and automated agents to specify the context-sensitive behaviour of different entities.
4 Service discovery framework Due to the continuous increase in functionally similar services in the central repository, the demand for automatic and efficient retrieval of services based on a set of required context attributes has increased. To deal with automatic discovery of web services, the service discovery framework for DERTS (SDFD) has been established and this is presented in Fig. 3. This framework consists of, namely: the service repository where advertised service descriptions are stored; the context base which stores the context descriptions of context providers (agents, phones and sensors etc.) as shown in Fig. 3; and the ontology base where domain and application ontologies are stored. The framework supports the service requester by querying services through an interface aligned with the classes and the data-type of the ontologies stored in the ontology base using protégé editor [19] and a rigorous algorithm which discovers services from a service repository. Using this framework (SDFD), the service requester creates a demand (D) to discover services. In the next step, consistency of the query is checked against the ontologies stored in the ontology base with the help of a reasoner. If the demand (D) is consistent, it is then converted into a constraint satisfaction problem (CSP) in the constraints evaluation section of the framework. The CSP is then checked for an appropriate solution through the Eclipse engine (Eclipse is a development environment for Java to develop client applications. It is an independent tool in which a user may initiate Protégé directly using the plug-in). If the solution exists, then a SPARQL query is generated against the demand (D). This query is 65
Fig. 1 Context ontology for DERTS
Fig. 2 UML diagram of context ontology
similar to a SELECT statement as it retrieves the services from the service repository. Finally, the service selector component of the framework returns the ranked results to the requester. 4.1 Service matching and ranking The first step in the process of service discovery is for the service demand (D) to be checked for its consistency. After this step, demand (D) constraints are checked for their satisfiability. The service matchmaking and ranking process then starts where the context descriptions of the web services are matched with the user demand (D). The process of service concept's matching, ranking and selection is given in Sections 4.2–4.6 and Section 5. The detail of notions used in these sections is presented in Table 2. For effective retrieval of services through semantic matching, it is necessary that services should be described in a language which facilitates logical reasoning. In this regard, Web Ontology Language [6] is used for describing the offer and demand. Hence, to facilitate the semantic matching process with ontology, the ontologies described in Fig. 1 and Fig. 4 [23] are used. 66
Fig. 4 is based on the idea of an application in health-care services. In hospitals, if temperature, humidity levels and air pressure are not controlled, they can cause respiratory infections and allergies resulting in serious consequences among patients, staff and visitors. In order to monitor and keep the temperature, humidity levels and air pressure in the acceptable range, different devices can be used which can offer more than one service at a time. An administrator can efficiently monitor the hospital to take corrective action by using any of the services offered by these devices. 4.1.1 Evaluation settings: Suppose different devices are installed at different places in the hospital offering different services whose DL description is provided below while the high level descriptions are provided in Table 3. Demand ⊆ srv : Service ∩ ( ∃ srv: performsActivity.srv : _Temperatue_Measurement) ∩ ( ∃ srv : hasStatus.srv : ON) ∩ ( ∃ srv : hasRemainingBattery.srv ≥ 95) ∩ ( ∃ srv : hasRemainingMemory.srv ≥ 90) ∩ ( ∃ srv : hasLocation.srv : CCU) ∩ ( ∃ srv : hasDeadline.srv ≤ 2) IET Softw., 2017, Vol. 11 Iss. 2, pp. 64-74 © The Institution of Engineering and Technology 2017
Fig. 3 Service discovery framework for DERTS
Fig. 4 Part of application ontology
Table 2 Notation description Notation Description
Following are the DL notions of the device services offered (advertisements):
WD(attrib)
weight of request (demand) attribute
parent(C) Oi
function to move C to its parent ith offer (advertisement)
Offer1 ⊆ srv : Service ∩ (∃ srv : performsActivity.srv : _Temperatue_Measurement) ∩ (∃ srv : hasStatus.srv : ON) ∩ (∃ srv : hasRemainingBattery.srv ≥ 51) ∩ (∃ srv : hasRemainingMemory.srv ≥ 57) ∩ (∃ srv : hasLocation.srv : Laboratory) ∩ (∃ srv : hasDeadline.srv ≤ 7) Offer2 ⊆ srv : Service ∩ (∃ srv : performsActivity.srv : _Temperatue_Measurement) ∩ (∃ srv : hasStatus.srv : ON) ∩ (∃ srv : hasRemainingBattery.srv ≥ 65) ∩ (∃ srv : hasRemainingMemory.srv ≥ 53) ∩ (∃ srv : hasLocation.srv : PICU) ∩ (∃ srv : hasDeadline.srv ≤ 9)
D
sij siO
demand (request) is a weighted score of jth attribute of ith service score of ith offer
ScharAtrib
score of named attribute
SnumAtrib
score of numeric attribute
↑
positive monotonic direction of value.
Table 3 Instance table of services Service code Activity description
Status Remaining battery life ↑ Remaining mem. space↑ Deadline ↓ Location description
O1 temperature measurement 1 51 O2 temperature measurement 1 65 O3 humidity level measurement 1 79 O4 temperature measurement 1 61 O5 temperature measurement 1 76 O6 temperature measurement 1 57 O7 air pressure measurement 1 75 O8 temperature measurement 1 71 O9 temperature measurement 1 53 O10 humidity level measurement 1 61 O11 humidity level measurement 1 75 D temperature measurement 1 95 Legends: ↑ High values are preferred; ↓ Low values are preferred IET Softw., 2017, Vol. 11 Iss. 2, pp. 64-74 © The Institution of Engineering and Technology 2017
57 53 88 51 67 55 72 63 54 73 68 90
7 9 10 8 7 11 8 5 12 13 13 2
laboratory PICU ward PICU NICU laboratory PICU ICU laboratory PICU ward NICU
67
Offer3 ⊆ srv : Service ∩ (∃ srv : performsActivity.srv : Humidity Leve _Measurement) ∩ (∃ srv : hasStatus.srv : ON) ∩ (∃ srv : hasRemainingBattery.srv ≥ 79) ∩ (∃ srv : hasRemainingMemory.srv ≥ 88) ∩ (∃ srv : hasLocation.srv : Ward) ∩ (∃ srv : hasDeadline.srv ≤ 10)
demanded concept is positive monotonic then the following formula will be used.
The remainder of the services can be described in a similar way. For better understanding of the service attributes described in the above DL notions, these attributes are presented in a tabular form in Table 3.
Otherwise the following formula will be used.
4.2 Semantic matching
Offer.value is the value of the advertised service. In (3) and (4) the denominator cannot be a zero because there exist a taxonomic relation among demand and offer concepts.
Various authors [17, 29–32] have proposed different semantic matching approaches for services discovery in dynamic environments. However, the process of calculating the semantic similarity between the demand (D) and offers (O) is not clearly defined. This section presents the method for calculating the closeness between the offers (O) and the demand (D) attributes as follows: ContextMatch O, D = O = D ∨ (O ⊆ D) ∨ (D ⊆ O)
(1)
where (see equation below) Concepts in either the demand (D) or in the offer (O) may be named or given as a number. In the case of named concepts, both concepts will relate through a taxonomy. The taxonomic relation among these concepts may fall into one of three categories which can be determined by the rules of equation (1). For example, fifth attribute (deadline) of demand and offer in Table 3 is a number and a negative monotonic. This attribute (deadline) belongs to the concept of QoSMetric in Fig. 1. So, both attributes are considered semantically equal because both belongs to the same concept (QoSMetric) and have the same value type direction. Similarly, sixth attribute (location) of demand and offer in Table 3 is a named attribute. This attribute belongs to the concept of Location in the application ontology as shown in Fig. 4. In this case the similarity among both concepts depends on the distance between the demand and offer on a taxonomy which will be measured through the levels of taxonomy. 4.3 Calculating semantic similarity score In literature, different approaches [33–35] have been proposed for calculating the semantic similarity among demand and offer attributes of the service. For example, the approaches presented by Resnik and Lin [6, 8] are based on probability; while the approach proposed by Skoutas et al. [34] works on the same assumption for calculating the similarity score between two concepts. However, these approaches cannot consider taxonomic deviation effectively because Resnik [33] does not consider the attributes and instances whereas Skoutas [34] has focused more on QoS-aware service retrieval. Lin's work [8] is based on strings similarity by creating graph structure which requires lexicographic expertise. Based on these limitations, the degree of similarity between named concepts can be determined by the following equation, where CountAttributes(O) denotes the total number of attributes of class O. LevelO =
SnumAttrib =
Demand . value − Offer . value Demand . value
1 Demand . value − Offer . value − 1 Demand . value
(2)
If both concepts (demand and offer) of services are numbered and exactly equal then the similarity score will be equal to 1; otherwise the score will be calculated based on the value type direction. If the
(3)
(4)
4.4 Service categorisation Description of a logic-based approach [30] other than [15, 22, 29] uses ontology for describing the services and a description logic reasoner for computing the matches for a given demand (D). However, these approaches do not consider user priorities for the demanded attributes during the matching process. Based on the limitations of these approaches, we propose below a method for calculating the similarity score considering user assigned priorities. sij =
∑ (S j charAtrib ∪ S j numAtrib )W attrib j (
)
(
)
(5)
where W(attribj) is a weight attached with attribute j of a service by the requester. To categorise the services based on their score, expert judgment along with the method used by Kritikos [21] is adapted. In this regard, we conducted empirical evaluation using three cut-off values (70–30, 80–20 and 90–10) to define score band (range of values defined for service categorisation). We asked our experts to comment on the results of score bands (70–30, 80–20 and 90–10) and with their agreement the categorisation band (70–30) was decided. Evaluation results of score bands (70–30, 80–20 and 90– 10) are discussed in detail in Section 6.1. Whereas, in Sections 4.4.1–4.4.4, service categorisation based on the score band 70–30 is discussed. 4.4.1 Exact match: If a CSP of offer contains the same score as the CSP of the demand (D), then the offer is called an exact match. This type of match is the highest preferable match which completely satisfies all of the demand (D) constraints. Following is the rule used for categorising the exact math of a service: If siO ≥ sD
(6)
4.4.2 Good partial match: If a CSP of offer contains most of the variables but not all variables of the CSP of the demand (D), then it is a good partial match. This is the next level of preferred results as it contains a total score of 70% and above of the computed score of the demand (D). The following rule is used for categorising the good partial math of a service: If siO ≥ sD ∗.7 ∧ siO < sD
∑ Level O
If Level D < Level O CountAttributes D ScharAtrib = CountAttributes O
SnumAttrib = 1 −
(7)
4.4.3 Partial match: This is the third level of preferred results as the offer contains a total score of a service between 30 and 70% of the demand (D) score. The rules used for such categorisation are given as follows If siO ≥ sD ∗.3 ∧ siO < sD ∗.7
(8)
O = D = O . IsNumeric ∧ D . IsNumeric ∧ O . valuetype = D . valuetype (D ⊆ O) = O . IsNamedConcept ∧ D . IsNamedConcept ∧ ( O . level ≤ D . level (O ⊆ D) = O . IsNamedConcept ∧ D . IsNamedConcept ∧ O . level ≥ D . level ) 68
IET Softw., 2017, Vol. 11 Iss. 2, pp. 64-74 © The Institution of Engineering and Technology 2017
Fig. 5 Proposed algorithm
4.4.4 Fail match: If the offer does not contain any, or only a few, variables of the demand (D) then it is a failed match. In this case, the user will be informed and the request must be altered. If siO < sD ∗.3
(9)
4.5 Service ranking Service ranking based on their final score may be beneficial for the requester. This is particularly important in the absence of exact matches; the requester might be interested to consider additional services which meet most of the requirements [14]. A matchmaking engine performs this task based on the calculated scores of the offers. The final score will be calculated with the help of the following formula: Total Score = max ∑ S j(charAttrib)W D attrib + S j(numAttrib)W D (10) attrib By providing a sorted list (based on the final scores) of the best possible matches, the service requester is supported in choosing the best offer (O) according to his preferences.
IET Softw., 2017, Vol. 11 Iss. 2, pp. 64-74 © The Institution of Engineering and Technology 2017
5 Algorithm Bandara [14] has proposed one of the prominent service discovery algorithms for device services. However, this algorithm has three major drawbacks: first, it does not consider the rich context information of the devices; second, it calculates the similarity score of services based on the sub and super class relations (which produces low precision results); and, finally, it does not consider the value type directions (i.e. higher values are better than smaller ones or vice versa). Our proposed algorithm (as follows) has addressed these limitations (see Fig. 5). Concepts occurring in the user demand (D) may be one of two types (named and numbered). In the case of named concepts, the taxonomic relationship is checked through the taxonomy. If no taxonomic relationship exists between the concepts, then these concepts are considered disjoint; in this case, the method ConceptSimilarityScore() will return a score 0. Otherwise, the score will be calculated by using equations (2) and (5). For example, the score of both attributes (activity description and location description) of service O3 in Table 4 is 0 because both concepts are declared disjoint in the application ontology (Fig. 3). Whereas in case of service O4 (Table 4), the score of the sixth attribute (location description) is 0.71 because there exists a taxonomic relationship between the demand (D) and offer (O) concepts as shown in Figs. 2 and 3 and the score is calculated 69
Table 4 Score according to the SDFD approach Service code Activity description Status Remaining battery life Remaining mem. space Deadline Location description Total score O1 O2 O3 O4 O5 O6 O7 O8 O9 O10 O11 D
1 1 0 1 1 1 0 1 1 0 0 1
1 1 1 1 1 1 1 1 1 1 1 1
0.537 0.684 0.832 0.642 0.800 0.600 0.789 0.747 0.558 0.642 0.789 1.000
0.633 0.589 0.978 0.567 0.744 0.611 0.800 0.700 0.600 0.811 0.756 1.000
0.286 0.222 0.200 0.250 0.286 0.182 0.250 0.400 0.167 0.154 0.154 1.000
0.00 0.71 0.00 0.71 1.00 0.00 0.71 0.83 0.00 0.71 0.00 1.00
3.45 4.20 3.01 4.16 4.83 3.39 3.54 4.67 3.32 3.31 2.69 6.00
example, it is assumed that the requester has assigned the following priorities to the demand (D) attributes. Activity = .5, Location = .3, Deadline = .2
Fig. 6 Service score comparison of SDFD and Bandara [14] approaches
based on the distance (level) that exists between demand (D) and offer (O) concepts and the associated attributes with these concepts in the taxonomy. More detail on scores calculation is provided in Section 6.2. Similarly, if the concepts are numeric concepts, then the score will be calculated by using equations (3) and (4). For example, in case of service attribute ‘RemainingMemory’ from Table 3 which belongs to a concept of Resources in Fig. 1 is numeric and positive monotonic. Its score will be calculated using equation (3). Once the score of all offers is computed, the offers are categorised into four groups on the basis of their final score.
6 Evaluation In this section, the proposed framework is evaluated with respect to its effectiveness (how good it is in discovering the most suitable service). 6.1 Results and discussion To perform the proposed ranking and selection method, we have considered a small set of 11 services. A random-number generator for creating context specification and service attribute values for the experiment was used because we could not find a suitable data set. However, before finalising the service specification and attribute values, domain experts were consulted. It is supposed that users will assign weights to the service attributes between 0 to 1 cumulating to 1. However, if a user assigns the weights out of the range (0 to 1) then the total weighted score of services will increase or decrease but the order of the services will not be affected. However, if user interchanges attribute weights then the order of the services may be changed. Similarly, if a user does not assign weights to the service attributes then all service attributes will be considered equal and no priority will be given services. The service with higher score will be returned to the requester. Moreover in our 70
Table 4 presents the computed scores of the offers and the demand (D) based on the formulae presented in Sections 4.2–4.5. In the case of first offer O1; the first attribute (activity description) of this offer is a named concept and exactly matches with the attribute of the demand (D) because both attributes belong to the same class in the taxonomic relation. Thus, according to equations (1) and (2), its score is 1. In the case of the third and fourth concepts (remaining memory space; which are numeric concepts and positively monotonic), their scores according to equations (1) and (3) are 0.537 and 0.633, respectively. Conversely, the score of the fifth attribute (deadline) is 0.286 (using equations (1) and (4)) because it is negatively monotonic. Similarly, the score of the last attribute (location description) is 0 because both concepts (offer and demand) belong to the disjoint classes in the taxonomic relation. However, the score of the last attribute (location description) of the second offer (O2) in Table 4 is 0.71 because there exists a taxonomic relationship which is evaluated using equation (1) while score is calculated using equation (2) which depends on the attribute associated with the ontological concepts. In this case, five attributes are associated with ICU which are common with the PICU concept as well while seven attributes are associated with NICU in our application ontology (Fig. 4). Finally, the total score of the services is calculated using equation (10). Table 5 presents the computed score of the services based on the technique presented by Bandara [14]. While the variation among score of both approaches can be observed in Fig. 6. Here we have categorised the services of Table 6, based on score band 70–30 and according to equations (6)–(9). These are, namely: Exact match list = [∅];Good partial match list = [O5, O8, O2]; Partial match list = [O4, O7, O1, O6, O9, O10, O3, O11]; Fail match list = [∅]. Whereas according to the score band 90–10 the lists are as: Exact match list = [∅]; Good partial match list = [∅]; Partial match list = [O5, O8, O2, O4, O7, O1, O6, O9, O10, O3, O11]; Fail match list = [∅]. While the list of services using score band 80-20 is as: Exact match list = [∅]; Good partial match list = [O5]; Partial match list = [O8, O2, O4, O7, O1, O6, O9, O10, O3, O11]; Fail match list = [O3, O11]. By analysing these results, it is observed that for band 80–20, only O5 service is appeared in the good partial list; for band 90–10, there was no result in the good partial list while for band 70–30, a good number of services appeared in the good partial list. This means that the service requester has a choice to select, next to high score service from good partial list in case of unavailability of that service. Next are the categorised lists of the services based on the calculated score in Table 5 as follows: Exact match list = [∅]; Good partial match list = [∅]; Partial match list = [O1, O2, O4, O5, O6, O7, O8, O9, O10]; Fail match list = [O3, O11]; Final ordered match list = [O4, O2, O5, O8, O9, O1, O6, O10, O7]. In Table 4, no exact match found, therefore, O5 is the next highest preferred result (returned to the requester) as it meets most of the IET Softw., 2017, Vol. 11 Iss. 2, pp. 64-74 © The Institution of Engineering and Technology 2017
Table 5 Scores according to the Bandara [14] approach Service code Activity description Status Remaining battery life Remaining mem. space Deadline Location description Total score O1 O2 O3 O4 O5 O6 O7 O8 O9 O10 O11 D
1 1 0 1 1 1 0 1 1 0 0 1
1 1 1 1 1 1 1 1 1 1 1 1
0.463 0.316 0.168 0.358 0.200 0.400 0.211 0.253 0.442 0.358 0.211 1.000
0.367 0.411 0.022 0.433 0.256 0.389 0.200 0.300 0.400 0.189 0.244 1.000
0 0 0 0 0 0 0 0 0 0 0 1
Table 6 Scores according to the different score bands defined for SDFD framework Service code Score band 70 - 30 Score band 80 – 20 O1 O2 O3 O4 O5 O6 O7 O8 O9 O10 O11 D
2.42 2.94 2.11 2.92 3.38 2.38 2.48 3.27 2.33 2.32 1.89 4.20
1.04 1.26 0.90 1.25 1.45 1.02 1.06 1.40 1.00 1.00 0.81 1.80
2.76 3.36 2.41 3.33 3.86 2.71 2.83 3.74 2.66 2.65 2.15 4.80
0.69 0.84 0.60 0.83 0.97 0.68 0.71 0.93 0.66 0.66 0.54 1.20
0 1 0 1 1 0 1 0.75 0 1 0 1.00
2.83 3.73 1.19 3.79 3.46 2.79 2.41 3.30 2.84 2.55 1.46 6.00
Score band 90 – 10 3.11 3.78 2.71 3.74 4.35 3.05 3.19 4.20 2.99 2.98 2.42 5.40
0.35 0.42 0.30 0.42 0.48 0.34 0.35 0.47 0.33 0.33 0.27 0.60
Fig. 7 Normal Q-Q plot of Bandara's framework
Fig. 8 Normal Q-Q plot of SDFD framework
requirements of the requester. Result O8 is the second-best while O2 is the third-best service for meeting most of the user requirements. Conversely, according to the data of Table 5 (Bandara [14] approach) the following results were obtained: O4 is the best service; O2 is the second-best while O9 is the third best service. These findings are in fact incorrect and this can be seen in Table 3 by using human judgement. Therefore, it is concluded that the proposed technique can produce accurate results when used in the dynamic environments of DERTS.
Before executing the t-test, we set our alternative (H1) and null (H0) hypothesis as:
6.2 Significance test To know whether the proposed approach really increases the correctness of the discovered results, a t-test experiment was designed in SPSS Version 16. In most disciplines, the researcher looks for a significance level of 0.05 to signify that there is only 5% probability that the observed results and occurred by chance. The significance level determines whether the null hypotheses is accepted or rejected, which is the crucial part of hypothesis testing. We have decided to use the t-test to compare the population means of two variables. t-test computes the difference to see if the average differences are significantly different from each other or not. IET Softw., 2017, Vol. 11 Iss. 2, pp. 64-74 © The Institution of Engineering and Technology 2017
H1: SDFD approach has improved correctness of discovered services with respect to Bandara approach. H0: SDFD approach has not improved correctness of discovered services with respect to Bandara approach. To perform the test, a group of 11 (n = 11) services were selected randomly from the population of one hundred services to investigate whether the proposed approach really improves the correctness of searched results or not. Before starting the experiment, normality was checked with the help of the Shapiro– Wilk test. The test statistics are shown in Figs. 7 and 8. Fig. 9, the mean for the SDFD framework is 3.111 and the mean for the Bandara's framework is 2.3764 while the standard deviation of SDFD is 0.52807 whereas the standard deviation for Bandara [14] is 0.47163. From Fig. 9, the Sig.(2-tailed) value is 0.000 which is
