In traditional Service-oriented Architecture (SOA) interactions, the three main interacting elements are the service provider, the service requester and the service registry. The service provider defines a service and publishes it through the service registry. The service registry acts as a data center that holds the services published by the different service providers. The service requester accesses the registry to get information about available services. It will then use this information to select a specific service that meets its requirements and will interact with the service provider of the selected service.

Hence, the main activities in SOA are service publication, service discovery and service provision. Service publication refers to the process of defining service contracts by service providers and publishing them through available service registries. Service discovery is the process of finding services that have been previously published and that meet the requirements of a service requester [1]. Typically, service discovery includes service query, service matching, and service ranking. Service requesters define their requirements as service queries. Service matching refers to the process of matching the service requester requirements, as defined in the service query, with the published services. Service ranking is the process of ordering the matched services according to the degree they meet the requester requirements. The ranking will enable the service requester to select a specific or a most relevant service from the list of candidate services. Service provision refers to the process of executing a selected service. The execution may include some form of an interaction between the service requester and the service provider.

In practice, before publishing services a service provider defines the contract that can be guaranteed by a service. This contract includes the functionalities and quality of services guarantees that the provider can make. But such guarantees are not absolute. A service cannot guarantee its contract in all situations. It can only guarantee its contract in a predefined set of conditions. These conditions are usually related to the context of the service provider and requester. Context information has been defined as any information used to characterize the situation of an entity, such as location, time and purpose [2]. Legal rules also play a crucial role in constraining the publication and discovery of services. For example, a wireless phone provider may include in the service contract a guarantee of excellent quality, but this guarantee is not absolute. It may have a constraining condition stating that in order to ensure excellent quality, the consumer should be located within 1000 meters from cell phone stations. This constraint is related to the contextual information of the service consumer. In addition, local legal rules may black-out wireless service in secure-critical locations. Such legal rules should be an essential part of every contract.

It is necessary to distinguish between legal rules and nonfunctional requirements. If a nonfunctional property is “a soft” requirement it may be ignored. However ignoring a legal rule is equivalent to a “legal violation”, which might land in legal disputes and even lead to loss of entire business. In essence, not enforcing a legal rule prevents the execution of a contract. Almost all current approaches use only functional and nonfunctional properties to enable the publication, discovery and provision of services. In [3], no distinction is made between legal rules and nonfunctional properties. Failure to include contextual information and legal rules will only mislead the consumer to believe in the advertised excellent quality of wireless service, regardless of where the consumer is domiciled which is not true.

To remedy the drawbacks of available service provision frameworks we have introduced two main concepts [46]. The first is a formal service model, which is called ConfiguredService. In this model, service and contract are packaged together. The service part includes functional and nonfunctional aspects of service, and the data parameters and attributes that are essential to define the functional and nonfunctional aspects. The contract part includes business rules, legal aspects, and context information. The second concepts is the Formal Framework for Providing Context-dependent Services (FrSeC) in which ConfiguredServices and their compositions are formally embedded. Service publication, service discovery, service selection and ranking, and service delivery are rigorously defined. The significance here is the way context information is defined for each stage, and is used in the interactions between the different components of the architecture elements in order to sustain the trustworthiness properties at all stages.

Motivation and contribution

In FrSeC, we have introduced contextual information, trustworthiness properties and legal rules as first class elements in both service publication and discovery. The introduction of contextual information and legal rules in service contracts introduces many challenges in service adaptation during service rediscovery process. The main goal of this paper is to address these challenges, and offer novel approaches for service publication, discovery and ranking, taking into consideration contextual information and legal rules.

This paper is structured as follows. First, we provide an overview of our formal framework for providing context dependent services FrSeC[46]. FrSeC supports the provision of services with context dependent services. Second, we focus on the publication and discovery of context-dependent services. We provide a novel formal notation for service publication. The three issues that we emphasize are context, legal rules, and adaptability. In FrSeC, service providers publish only ConfiguredServices in the service registry. A ConfiguredService is a structure that bundles together service functionality, service contract, and provision context. Service requesters query the service registry to find available ConfiguredServices. Often there is a semantic gap between the service query and the services in the registry. To deal with this, we introduced in the third part of this paper three novel query types for service discovery, and a ranking algorithm. Fourth, we discuses adaptability in FrSeC. Fifth, we introduce a prototype implementation of the ranking and matching supported by FrSeC. Finally, we briefly compare our work with the related work and provide concluding remarks.

An overview of FrSeC

This section briefly introduce the formal framework for providing context-dependent services FrSeC. The introduction of the main elements of FrSeC is essential to understand the contribution of this paper, namely the publication, discovery and ranking of services supported by FrSeC.

FrSeC was motivated by the need for a framework that supports the publication, discovery and provision of services with context-dependent contracts. The main elements of FrSeC are shown in Figure 1. A complete formal definition of FrSeC is presented in the two recent papers [4, 6]. Below is a brief summary of FrSeC elements.

Figure 1
figure 1

FrSeC Architecture. A presentation of the architectural components of the FrSeC architecture and the interactions between those components.

Service Provider (SP)

It is the entity that provides an implementation of a service specification. The service specification is published by the SP using SRe.

Service Registry (SRe)

It is a central repository for services, in which Service Providers publish their services and PU discovers services. It includes semantic definitions for domain specific concepts.

Context Gathering Unit (CGU)

FrSeC contains at least three context gathering units. One unit collects contextual information to assist SR in formulating their service queries. Another unit collects contextual information relevant to SP. The third unit collects contextual information to assist EU and PU in dynamic planning activities. A central context manager may be added to monitor and trigger the adaptive context-aware behavior of the framework.

Service Requester (SR)

It is the entity requiring a certain functionality to be satisfied. It represents the client side of the interaction. It can be an application or another service. SR defines its requirements in a service query.

The Authentication Agency (AU)

It is the entity responsible for ensuring trustworthy access to SRe. It provides requesters with certificates (tokens) that allow them to access SRe. The certificate type depends on the legal and contextual information of the requester.

Planning Unit (PU)

It is responsible for managing the service discovery process by interacting with SR, SRe and AU. It also defines service composition. The composition includes defining the plans that can satisfy a query requirement. A plan defines the execution logic of a service or multiple services that collectively achieve the functional, nonfunctional and trustworthiness requirements of the requester. A complete formal composition theory is defined in [5]. This theory considers the functional, nonfunctional, legal and contextual parts of the service when defining the composition result.

Plan Selection Unit (PSU)

It is responsible for helping SR to select one or more plans from the set of plans received from PU. For each plan received, it requests additional information, such as data parameters, from SR and verifies that the information in the plan is complete with respect to the request. If it finds the information incomplete the chosen plan is ignored, otherwise the plan is selected for SR.

Execution Unit (EU)

It is responsible for managing the provision of services. It executes the selected plan. The execution process will include communicating with the service providers involved in the plan by sending service requests and obtaining service responses.

Service publication

Service providers publish service contracts through the Service Registry (introduced above) in order to make them available for discovery. In current approaches (discussed in the Related Work Section), the service contract includes only the functional and nonfunctional requirements together with any semantic information the service provider wishes to make public. But in FrSeC the service definition is much richer. It includes the service contract together with the related contextual conditions. Hence, we introduced the concept ConfiguredService, which is a structure in which service functionality, service contract, and service provision context are bundled together. SP publishes the two main elements, namely the contract and context, in the ConfiguredService.

The contract includes function, nonfunctional properties and legal issues. The context part of the ConfiguredService includes the main parts context info and context rules. The context info defines the contextual information of the ConfiguredService. The context rules define the contextual information related to SR that should be true for SP to guarantee its ConfiguredService contract.

Example 1.

Table1shows a ConfiguredService of a Car Repair Shop. The repair shop charges 60$ per hour and requires a deposit of 300$ with the condition that the car owner is a member of the Canadian Automotive Association (CAA).

Table 1 RepairShop ConfiguredService description

In [5], we introduced the novel service model ConfiguredService. ConfiguredService is formally defined using a model-based approach. The formal model is built from set theory and logic. Below is a formal presentation of ConfiguredService.


A constraint is a logical expression, defined over data parameters and attributes in first order predicate logic. If C denotes the set of all such logical expressions, XC is a constraint. The following notation is used in our definition:

  • T denotes the set of all data types, including abstract data types and DtT means Dt is a datatype.

  • v:Dt denotes that v is either constant or variable of type Dt.

  • X v is a constraint on v. If v is a constant then X v is true.

  • V q denotes the set of values of data type q.

  • x:Δ denotes a logical expression XC defined over the set of parameters Δ.


A parameter is a 3-tuple, defining a data type, a variable of that type, and a constraint on the values assumed by the variable. We denote the set of data parameters as Λ={λ=(Dt,v, X v )|DtT,v:Dt, X v C}.


An attribute has a name and type, and is used to define some semantic information associated with the name. The set of attributes is α={(Dt, v α )|DtT, v α :Dt}.


A context is formalized as a 2-tuple β = 〈r,c〉, where rC, built over the contextual information c. Context information is formalized using the notation in [7]: Let τ: DIMI, where DIM = {X1,X2,…,X n } is a finite set of dimensions and I = {a1,a2,…,a n } is a set of types. The function τ associates a dimension to a type. Let τ (X i ) = a i , a i I. We write c as an aggregation of ordered pairs (X j , v j ), where X j DIM, and v j τ(X j ).

Example 2.

Using the context notation, the contextual information of ConfiguredService RepairShop(rs) presented in Table 1 , is written as β rs =〈r rs , c rs 〉, where r rs = {(membership == caa)} is the context rule and c rs = {(Location, Montreal)} is the contextual information of the service provider.


A contract is a 3-tuple σ = 〈f, κ, l〉, where the service function f , the set of nonfunctional properties κ and the set l of legal issues that bind the service contract are defined below.

Example 3.

Using this formalism the RepairShop contract presented in Table 1 , is written as σ rs =〈 f rs , κ rs , l rs 〉.

  • Service function: A service function is a 4-tuple f = 〈g, i, pr, po〉, where g is the function signature, i is the function result, pr is the precondition, and po is the postcondition. A signature is a 3-tuple g = 〈n, d, u〉, where n is the function identification name, d is the set of function parameters and u is the function address, the physical address on a network that can be used to call a function. The result is defined as i = 〈m, q〉, where m is the result identification name and q is the set of parameters resulting from executing the ConfiguredService. The precondition pr and the postcondition po are data constraints.

Example 4.

The RepairShop contract functionality presented in Table 1 , is formally written as f rs =〈 g rs , i rs , p r rs , p o rs 〉, where

  • g rs = 〈n rs ,d rs ,u rs 〉, where n rs = (ReserveRS), d rs = {(CarBroken, bool), (deposit, double), (CarType , string), (failureType, string)}, and u rs = (XXX).

  • i rs = 〈m rs ,q rs 〉, where m rs = (ResultRS) and q rs = {(HasAppointment, bool), (numberOfHours, int)}.

  • pr rs = {(CarBroken == true)} and po rs = {(HasAppointment == true)}.

  • Nonfunctional property: Defined as a 6-tuple κ=〈ρ,ε,ψ,η,p,tr〉. The safety guarantee ρ includes time guarantee ρ t and data guarantee ρ d . The time guarantee is defined as the time the service takes to provide its function. The data guarantee refers to the accuracy of data. The security guarantee ε defines the set of security protocols that the Service Provider has followed to guarantee confidentiality and integrity constraints. The reliability guarantee ψ refers to the guaranteed maximum time between failures. The availability guarantee η refers to the guaranteed maximum time for repairs. The price is defined as a 3-tuple p = 〈a, cu, un〉, where a is the price amount defined as a non negative double, cu is currency tied to a currency type cType, and un is the pricing unit. Provider Trust is defined as a 3-tuple tr = 〈ce, pg, re〉. Lowest price guarantee pg is represented by a Boolean flag that is true when a ConfiguredService can guarantee its price to be lower than the price of any other ConfiguredService providing the same functionality. Client recommendations ce and recommendations from independent organizations re can be defined as sets of ordered pairs representing the clients or organization and associated recommendation.

Example 5.

The nonfunctional property in the RepairShop contract presented in Table 1 , is formalized as κ rs =〈 p rs 〉, p rs =〈 a rs , cu rs ,un rs 〉, where a rs = (60) is the cost, c u rs = (dollar) is the currency, and un rs = (hour) is the pricing unit.

  • Legal issues: A legal issue is a rule, expressed as a logical expression in C. A rule may imply another rule, however no two rules may conflict each other. We write l={y|yC} to represent the set of legal rules. The legal aspect of the RepairShop contract presented in Table 1, is formally written as l rs = {(deposit = 300), (CarType == toyota)}.

Putting the above definitions together we arrive at a formal definition for ConfiguredService.

Definition 1.

A ConfiguredService is a 4-tuple s = 〈Λ,α,β,σ〉, where Λ is a set of parameters, α is a set of attributes, βis a context, and σis a contract.

Service discovery

To be able to select and invoke a service that meets its requirements, a service requester should initiate a discovery process. The discovery process includes service query, service matching, and service ranking. First, SR defines his requirements in the service query. Second, the query is matched with available ConfiguredServices by PU. Third, PU ranks available candidate ConfiguredServices. Fourth, SR with the help of PSU, selects a ConfiguredService from the set of ranked ConfiguredServices. The novelty of the discovery process supported by FrSeC is two-fold. First, the discovery process takes into consideration legal requirements and context conditions together with functional and nonfunctional requirements. Second, depending on the requirements of the service requester, FrSeC supports the two types of queries traditional style and buffet style. The rest of this section discusses service query and matching. Service ranking is discussed separately in the next section.

Traditional style

In traditional style discovery, the requester has a clear idea about the requirements. But, the semantic information necessary to define the query is missing. Hence, SR accesses SRe to get the domain knowledge which will help in defining the query. The query process can be defined in the following steps:

  1. 1.

    SR sends a request to the AU for a certificate to access SRe.

  2. 2.

    AU provides the certificate depending on the legal and contextual information of SR.

  3. 3.

    SR, with the help of the certificate, browses SRe to gain domain knowledge.

  4. 4.

    SRe provides SR with domain knowledge, such as available domains and their associated functionalities.

  5. 5.

    SR uses this domain knowledge to construct the query and sends it to PU.

  6. 6.

    PU defines and sends service lookups to SRe.

  7. 7.

    The service lookup result is then used by PU to perform matching between the query and available services.

  8. 8.

    PU defines the query result (plan) and sends it to SR with any feedback if necessary.

Traditional style discovery can be either exact-match discovery or weighted-match discovery as discussed below.


In exact-match discovery, the requester requires an exact match to the requirements. The candidate ConfiguredServices should be able to guarantee all the requirements. The exact-match query, as shown in Figure 2, consists of the five main parts required function, required nonfunctional properties, required legal issues, consumer contextual information, and authentication certificate. The query also contains the set of parameters that it can understand. This set is a subset of the parameters associated with the functionality it chose when accessing SRe. The required nonfunctional properties are a subset of the nonfunctional properties associated with the functionality defined in SRe. The three following definitions formalize an exact-match query.

Figure 2
figure 2

Exact-match query. The content of a traditional style query of type exact-match.

Definition 2.

An exact-match query q e is defined as q e = f ̂ , κ ̂ ,ĉ, l ̂ ,E, Λ ̂ , where f ̂ is a query required function, κ ̂ is the nonfunctional requirement, l ̂ is the legal rules requirements, ĉ is the contextual information of the service consumer, E is the authentication certificate and Λ ̂ is the set of parameters SR can provide or understand. The formal definitions of context information, legal rules and parameters are identical to the definitions in the previous section.

Definition 3.

The required function is defined as f ̂ = pr ̂ , po ̂ , D ̂ , SF ̂ , where pr ̂ is the set of preconditions of the required function, po ̂ is the set of postconditions of the required function, D ̂ =(x:x|string) is the associated domain as defined in SRe and SF ̂ =(x:x|string) is the functionality as defined in SRe. The formal definition of precondition and postcondition is identical to the one in the previous section.

Definition 4.

The required nonfunctional property is defined as κ ̂ = ρ ̂ , ε ̂ , ψ ̂ , η ̂ , p ̂ , tr ̂ , where ρ ̂ is the required safety guarantee, ε ̂ is the required security guarantee, ψ ̂ is the required availability guarantee, η ̂ is required the reliability guarantee, p ̂ is the maximum price required and tr ̂ is the required provider trust guarantee. The formal definition of each of those nonfunctional properties is identical to the definition in the previous section.

Example 6.

If a service requester is attempting an exact-match query for the repair shop functionality defined in Table 1 , the query could be defined as q e = f ̂ , κ ̂ ,ĉ, l ̂ ,E, Λ ̂ where:

  • f ̂ = pr ̂ , po ̂ , D ̂ , SF ̂ , where pr ̂ ={(CarBroken==true)}, po ̂ ={(HasAppointment==true)}, D ̂ =(CarDomain), and SF ̂ =(RepairShopFunctionality).

  • κ ̂ = p ̂ , where p ̂ =â, cu ̂ , un ̂ ,â=(50), cu ̂ =(dollar)and un ̂ =(hour).

  • l ̂ ={(deposit=500)}.

  • ĉ={(membership==caa)}.

  • Λ ̂ ={(CarBroken,bool),(deposit,double),(CarType,string),(failureType,string)}

After receiving the lookup result from SRe, PU will match available ConfiguredServices with the service query. In exact-match the matching process will result in a ServiceType which is a list of candidate ConfiguredServices. All ConfiguredServices in the ServiceType provide the exact match to all the requirements defined in the service query. For each ConfiguredService in the lookup result the matching will:

  1. 1.

    compare the query functionality with the ConfiguredService functionality,

  2. 2.

    compare the query nonfunctional requirements with the ConfiguredService nonfunctional properties,

  3. 3.

    compare the query legal issues with the ConfiguredService legal rules, and

  4. 4.

    use the query contextual information to make sure the ConfiguredService context rules are met.


The formal definition of the weighted-match query is very close to the exact-match query. The only difference is the inclusion of the weights. In weighted-match discovery, the requester knows the requirements, however unsure about them. SR states the requirements in a query with the expectation that the best matched services, that might not be exact matches, will be given. That is, the ConfiguredServices received by the service requester do not have to match all the stated requirements. When stating the query the requester assigns a weight, representing the priority, with every property requirement. A higher weight indicates a higher priority. SR can also state exact property to indicate that an exact match is necessary for this particular property. Stating the weight is valid for the elements of the required function, nonfunctional requirements and the required legal rules. With respect to contextual information, SR can state more than one possible set of contextual information. As an example, the context information for service delivery can be either the service be delivered at home or at office. Each contextual information will be assigned a weight to indicate the preference of the requester. In our further discussion we assume that the assigned weights belong to the set {Low, BelowAverage, Average, AboveAverage, High, Exact}, in which the values are listed in strictly decreasing order of priority.

Definition 5.

A weighted-match query is defined as q w = f ̂ , κ ̂ ,ĉ, l ̂ ,E, Λ ̂ ,Ξ , where f ̂ , κ ̂ , l ̂ , ĉ , E and Λ ̂ are defined as in the traditional query, and Ξ :(x ∈ {Low, BelowAverage,Average,AboveAverage,High,Exact})(y{ pr ̂ , po ̂ , ρ ̂ , ε ̂ , ψ ̂ , η ̂ , p ̂ , tr ̂ , l ̂ ,ĉ} is a function that assign weights to the elements of the weighted-match query.

Example 7.

Adding weights to the query defined in Example 6 the weighted-match style query will be defined as q w = f ̂ , κ ̂ ,ĉ, l ̂ ,E, Λ ̂ ,Ξwhere f ̂ , κ ̂ ,ĉ, l ̂ , E and Λ ̂ are defined as in Example 6, and Ξ= {((CarBroken == true), Exact), ((HasAppointment ==true), Exact ),( p ̂ , High ),((deposit=500), Average )}.

The matching process in weighted-match discovery considers all possible ConfiguredServices even if some properties are not satisfied. All candidate ConfiguredServices will be included in the matching result ServiceType, with the exception of the ConfiguredServices that do not provide a match for a requirement with Exact weight.

Buffet style

The main difference between traditional style and buffet style is that in traditional style the requester is more or less clear about the requirements in order to be able to define the query in terms of these requirements, whereas in buffet style the requester is not at all clear about the requirements. Hence, the SRe is browsed for available ConfiguredServices and a query is defined only in terms of existing ConfiguredServices. The buffet style query process can be defined in the following steps:

  1. 1.

    SR sends a request to the AU for a certificate to access SRe.

  2. 2.

    AU provides the certificate depending on the legal and contextual information of SR.

  3. 3.

    SR, with the help of the certificate, browses SRe for available ConfiguredServices.

  4. 4.

    SRe provides SR with high level information about the set of available ConfiguredServices.

  5. 5.

    SR defines the query in terms of specific ConfiguredServices and sends it to PU.

  6. 6.

    PU will access the SRe to get the complete information about the required ConfiguredServices.

  7. 7.

    SRe will verify that SR has the required authentication to use the required ConfiguredServices.

  8. 8.

    PU defines the query result (plan) to include the complete ConfiguredServices information and sends it to SR with any feedback if necessary.

No matching process is necessary in buffet style, because the service requester is querying only ConfiguredServices. As a consequence, the definition of buffet style query, shown in Figure 3, consists of the three main parts required ConfiguredService, consumer contextual information, and authentication certificate. The following two definitions formalize a buffet style query.

Figure 3
figure 3

Buffet style query. The content of a buffet style query.

Definition 6.

A buffet style query is defined as q b = cs ̂ ,ĉ,E, Λ ̂ , where cs ̂ is the required ConfiguredService defined as in Section 2, ĉ is the contextual information of the service consumer defined as in Section 2, E is the authentication certificate and Λ ̂ is the set of parameters SR can provide or understand, all defined as in Section 2.

Example 8.

If SR is attempting a buffet style query for the ConfiguredService RepairShop defined in Table1, the query will be defined as q b = cs ̂ ,ĉ,E, Λ ̂ , where cs ̂ = s rs . ĉ={(membership==caa)}, and Λ ̂ ={(CarBroken,bool),(deposit,double),(CarType,string),(failureType,string)}.

Service ranking

In buffet-style the service requester queries for a concrete ConfiguredService, and hence no ranking is necessary. Service ranking is necessary for weighted-match service queries, for the following reasons. In exact matching, the only difference between the ConfiguredServices in the ServiceType is the order they were discovered. A ConfiguredService A that was discovered before ConfiguredService B will precede it in the ServiceType list. This is because all services provide an exact match to the requirements, which is not the case in weighted-match. For a weighted-match, the position of a service in a ServiceType should indicate the degree to which the requester requirements are met. That is, in weighted-match search a service that appears first in a ServiceType should have the best match with the stated requirements than a service that appears later in the ServiceType list. These considerations have motivated us to discover a ranking method. In FrSeC, the ranking process is performed by PU. The process takes as inputs the weighted-match query and the ServiceType, and generates as output an ordered ServiceType. The ranking process can be defined in the following 3 steps.

Form weight vector

In formulating a weighted-match query the requester assigns a weight to each property that is relevant for him. PU extracts these weights and constructs the weight vector, as in Equation 1, where Q w is the weighted-match query weight vector and w i is the weight of property i as defined by the service requester. Property i can be a precondition, a postcondition, a nonfunctional requirement or a legal requirement. The number of properties n depends on the weighted-match query defined by the service requester.

Q w =[ w 1 , w 2 , w 3 ,.., w n ]

We have mentioned earlier that the weight can be {Low, BelowAverage, Average, AboveAverage, High, Exact}. ConfiguredServices that do not satisfy Exact values are filtered when doing the weighted-match matching. So the possible weight values are {Low, BelowAverage, Average, AboveAverage, High}. We assume in further discussion that weight values are whole numbers in the range 1…5, where 1 denotes Low and 5 denotes High.

Construct weight matrix

By using the weight vectors constructed in Step 1, the weight matrix for the ConfiguredServices in the ServiceType is constructed. This is shown in Equation 2, where n is the number of properties defined in Equation 1 and m is the number of ConfiguredServices in the ServiceType. Each column represents the weights of the properties in a single ConfiguredService. Each row represents the weights of a single property in the different ConfiguredServices.

C S w = w 1 , 1 w 2 , 1 .. w m , 1 w 1 , 2 w 2 , 2 .. w m , 2 .. .. .. .. w 1 , n w 2 , n .. w m , n

The value of the ConfiguredService property weight depends on the property type. If a property j is a precondition, postcondition, legal rule (without values) or a security property, a weight w i,j is equal to 1, if ConfiguredService i satisfies property j and is equal to 0 otherwise. If property j is price, legal rule (with values), availability or time-safety, w i,j is calculated according to Equation 3, where z is the required property value as defined in the weighted-match query and x is the actual property value specified in ConfiguredService.

w i , j = 1 if x z 1 x z 2 z z = 2 x z if z < x < 2 z 0 if x 2 z

Equation 3 assumes that actual value that is more than double the required value will be given a weight of 0. Anything that is less than the required value will be given 1. And an actual value between the required value and double the required value will be given a weight that depends on how close the actual value is to the required value. For example, if the required price as defined in the service query is 50, an actual ConfiguredService price of 55 should be given a better weight than a price of 80.

If property j is reliability, wi,j is calculated according to Equation 4, where z is the required reliability value as defined in the weighted-match query and x is the ConfiguredService actual reliability value.

w i , j = 1 if x z 1 z x z z 2 = 2 x z 1 if z 2 < x < z 0 if x z 2

Equation 4 assumes that actual values that is less than half the required value will be given a weight of 0. A value that is more than the required value will be given a weight of 1. And an actual value between the required value and half the required value will be given a weight that depends on how close the actual value is to the required value. The main difference between reliability and other properties is that reliability values represent a minimum while other properties represent a maximum.

Calculate weights for ranking

A single weight value for each ConfiguredService is computed, and the services are ranked based on these weights. Equation 5 uses the results of steps one and two to calculate the raking weight vector.

W= Q w ×C S w

The ranking weight vector W contains the weights of the different ConfiguredServices. These weights are used to rank the ConfiguredServices. The ConfiguredService with the highest weight value is placed first in the ServiceType. The ConfiguredService with the second highest weight value is placed second in the ServiceType and so on for the rest of the ConfiguredServices.

Example 9.

Two ConfiguredServices RepairShopA and ReapirShopB provide the functionality required in Example 7. They don’t provide an exact match to the nonfunctional and legal requirements, but rather a partial match. The list of properties will include: {RequiredPrecondition, RequiredPostcondition, RequiredPrice, RequiredDeposit}. The RequiredPrecondition and the RequiredPostcondition will be filtered out because they require an exact match. So we are left with RequiredPrice and RequiredDeposit. Hence, the weighted-match query weight vector is Q w = High Average . In numbers, Q w = 5 3 . ConfiguredService RepairShopA (rsA) has a cost of rs A c = 40 $/hour and requires a deposit of rsA d = 600 $. ConfiguredService RepairShopB (rsB) has a cost of rsB c = 70$/hour and requires a deposit of rs B d = 400$. Hence, the ConfiguredServices weight matrix is defined, using Equations 2 and 3, as:

C S w = w rsA , c w rsB , c w rsA , d w rsB , d

where, wrsA,c = 1, wrsB,d = 1 and:

w rsA , d = 2 600 500 = 0 . 8
w rsB , c = 2 70 50 = 0 . 6

The ranking weight vector will then be defined using Equation 5 as:

W = 5 3 1 0 . 6 0 . 8 1 = 7 . 4 6

Hence, ConfiguredService RepairShopA scores 7.4 and ranked first, while ConfiguredService RepairShopB scores 6 and ranked second.

FrSeC adaptability

One of the main features of FrSeC is its ability to adapt to situations that trigger a need for a rediscovery or re-ranking process. Below is a discussion of the most important triggers and how they are handled in FrSeC.

Context change

The discovery process uses the contextual information of the service requester at service discovery time. But during service execution, the contextual information of the service requester might have changed. As a consequence, the contextual rules of the discovered service(s) might be violated, other services may be more suitable. In order to deal with the dynamic change in context we introduce an adaptable discovery mechanism. In FrSeC, this mechanism includes the following steps:

  1. 1.

    CGU senses the new context information and informs SR.

  2. 2.

    SR generates a new query with the new context information.

  3. 3.

    The context change may result in a change to the security level. So SR contacts AU with the new context information.

  4. 4.

    AU sends a new token to SR.

  5. 5.

    SR sends the new query to the PU which will initiate a new discovery process.

  6. 6.

    PU will send a new plan with the set of new ordered ConfiguredServices.

  7. 7.

    EU will migrate from the old ConfiguredService to the new ConfiguredService.

Failure in service availability

During service execution, the executing service might fail or become unavailable. For example, the wireless router might fail. FrSeC is designed to adapt to service failures. In our design, PU uses ServiceType, and not specific ConfiguredServices when defining query result. The list ServiceType contains ordered ConfiguredServices that can meet the requirements of a specific query. These ServiceTypes will be part of the plan sent to EU. During run time, if a ConfiguredService fails or becomes unavailable, the EU will select the next ConfiguredService in the ServiceType. The worst case is that an equivalence class has only one ConfiguredService and it fails. The feedback loop in FrSeC will restart the discovery process in this case.

New alternative services

Service executions may be performed over days, or even months. But service selection and binding are usually performed only the first time the requester uses the service. This might not be practical because new services might be available during this long execution time. The new alternative services might be new services or old services with new modified contracts. A new contract might include a lower price or a better quality. For example, a wireless provider with cheaper price and same quality guarantees might become available. In order to adapt to new alternative services during run time, SR registers with PU. This registration will guarantee that PU will inform SR in case of a new ConfiguredService that provides the requester the required functionality becomes available. Thus, SR can initiate a new discovery process.

New contract rules

Contracts bound to ConfiguredServices may be either strict or flexible. In a strict contract, the life-time of contract is made explicit. Providers and requesters are bound by this timeline. In a flexible contract, there is no life-time specification, which allows providers to change the contract terms at any point of time. For example, the service provider might increase the price of his wireless Internet connection. Providers might not be aware of the identity of their clients. This design decision was made to enshrine privacy issues. In FrSeC, providers inform EU of changes to service contract. At the time of service delivery, EU informs SR of changes to the contract and delivers the service only upon receiving the acceptance of new contract terms from SR. In order not to deny service, requesters are allowed to initiate a rediscovery process in accordance with the new contract terms.

New requester requirements

Some service executions might be too long and during this service time the requirements of the requester might change. To deal with new requirements, the requester has the choice of a rediscovery process or a re-ranking process. In the rediscovery process the requester will define a new query and go through all steps of service discovery. In a re-ranking process, the requester will ask PU to re-rank the ConfiguredServices in the ServiceType taking into consideration the new assigned weights to the elements in the modified query.

Evaluation and experiments

To evaluate the contributions presented in this paper, a Java based application has been implemented to represent the Planning Unit. This application takes as input the set of ConfiguredService that provide a specific functionality as returned from the Service Registry, and the service query. The application will then match between the service query and the candidate ConfiguredServices taking into consideration the functional, nonfunctional, legal, and contextual information. Two types of matching has been implemented 1) exact match and 2) weighted-match. The ranking algorithm has also been implemented. Figure 4 shows a snap shot of the Planning Unit application.

Figure 4
figure 4

Planning unit tool. A snapshot of the planning unit tool.

The application was tested on a standard PC using an Intel Centrino processor with 4GB of memory and running Windows 7 Professional. The average matching and ranking time was in in milliseconds for each ConfiguredService which eliminate the concerns of scalability issues.

The tool was tested on multiple case studies including the Automotive Emergency Case Study. Table 2 shows the set of ConfiguredServices that are matched and ranked according to the service requester query presented in Table 3. The matching and ranking result of these ConfiguredServices are:

  • ConfiguredService RepairShop5 is matched by 100.0%

  • ConfiguredService RepairShop4 is matched by 88.19%

  • ConfiguredService RepairShop1 is matched by 83.33%

  • ConfiguredService RepairShop2 is matched by 80.56%

  • ConfiguredService RepairShop3 is matched by 78.12%

Table 2 Multiple RepairShop ConfiguredServices descriptions
Table 3 Service query description

Related work

Related work can be divided into related publication approaches and related service discovery approaches.

The most notable publication approaches are UML-based such as [8, 9], WSDL [10], OWL-S [11], WSMO [12], SOADL [13], SRML [14], and (SOFM) [15]. These approaches are compared and the result of comparison is presented in Table 4. It is clear that all approaches support the modeling of the functional behavior. Nonfunctional and trustworthiness properties are only supported in a simple manner by few approaches. Contextual information is not represented by any approach, hence the relationship between contract and context is totally ignored. A couple of approaches, which have ignored the modeling of nonfunctional and trustworthiness properties, have used formal methods and conducted formal verification. Except for UML and Web services languages most of the approaches provide a minimum amount of tools to support the modeling using their service models.

Table 4 Related service publication

The most notable service discovery approaches are SeGSeC [16], eFlow [17], SELF-SERV [18], SHOP2 [19], SWORD [20], Argos [21], FUSION [22], Proteus [23], SPACE [24], StarWSCoP [25], METEOR-S [26], SeCSE [27], DynamiCoS [28] and TSCN [29]. These approaches have been compared with respect to the following criteria.

  • Dynamic selection: The service provision framework should be designed to allow service requesters specify the requirements with the full knowledge that some service bindings may occur only at run time.

  • Dynamic composition: With the increased number of services and the increased composition complexity, it is difficult to have all service compositions predefined in a static manner.

  • Context support: Contextual information is essential at service publication, service query, service selection and planting, and service execution.

  • Semantic support: Semantic information is essential at service specification, service query, and service composition.

  • Formal: Formalism is necessary to 1) verify the interaction between services by making sure there are no incompatible behaviors between services in a composition, 2) achieve correct automatic composition by verifying that the composition satisfies the requirements of the requester, and 3) check the conformance of requester requirements and the contracts of the services being provided.

  • Negotiation support: Each service requester has his own set of requirements. In many cases, none of the available services may fully match these requirements. The service provision framework should provide a mechanism to support the negotiation between service requesters and providers.

  • Nonfunctional and trust: The consideration of nonfunctional and trustworthiness properties in service publication, discovery and ranking is essential.

  • Replanning support: At run time, the contextual information of the service consumer and requester might change. The service provision framework should support a replanning process to generate a new plan that best satisfies the requirements in the new context.

  • Fault-tolerance: If a service fails or becomes unavailable at run time, the service provision framework should recover from this failure by selecting alternative services.

The result of this comparison is presented in Table 5 and it shows the following:

  1. 1.

    With the exception of SWORD and Argos, all approaches support dynamic selection.

  2. 2.

    Dynamic composition is considered by almost half of the approaches. In most of these approaches AI planning techniques are used.

  3. 3.

    Contextual information is used by very few approaches. In these approaches, context is used to filter the services, but not to constrain the service contract. Hence, the relationship between the contract and context is not considered.

  4. 4.

    Semantic information using ontology is supported by almost half of the approaches. The use of ontology restrains the semantic support due to the complexity and difficulty of composing ontologies.

  5. 5.

    With the exception of three approaches, all remaining approaches are not formally based. This will limit their verification support.

  6. 6.

    None of the investigated approaches supports negotiation.

  7. 7.

    The support of nonfunctional and trustworthiness properties is very simple and limited.

  8. 8.

    Replanning is supported by almost half of the approaches. With the exception of protus, approaches that support replanning do not support dynamic composition and hence the replanning is manually performed.

  9. 9.

    Fault-tolerance is supported by only few approaches. A number of approaches such as Argos, Composer, FUSION and Meteor-s do not mention fault-tolerance. Hence, by default we consider that they do not support fault tolerance.

Table 5 Related service discovery

Conclusion and future work

We have presented FrSeC that supports the publication, discovery, and provision of services with context-dependent contracts. FrSeC is formally based and considers legal rules and contextual conditions during service provision. It also supports an adaptive rediscovery and reranking operations. We are currently working on a detailed service architecture extended with flexible contracts and trustworthiness guarantees. We are developing a set of tools and a process model in order to provide a platform in which service-oriented applications within the confines of FrSeC can be developed.