Discovery of adaptable services

3 of December, 2010 Ayia Napa, Cyprus

Feature-Based Discovery ofServices with Adaptable Behaviour

J. Antonio Martín and Ernesto PimentelUniversity of Málaga

Spain

ECOWS'10

Introduction

We assume Web services have complex behavior

E.g., Web services described as BPEL processes

a:

Mismatches

a:

b:

Services might have incompatibilities in signature and behavior

These lead the orchestration to a deadlock situation

We want to discover both compatible services and incompatible but usefull services

Adaptable services are usefull services

Adaptation

a:

b:

Behavioral adaptation deploys an adaptor in the middle of the communication which overcomes signature and behavioral incompatibilities

Adaptors are described by abstract adaptation contracts

Adaptation

<b:?find(S);a:!request(S,I)><b:!results(SS);a:?POIlist(SS)>

<a:!quit()>

a:

b:

AdaptationContract

Adaptors are generated from adaptation contracsAdaptation contracs can be designed or automatically createdWe focus the dicovery on adaptability requirements

Current Approaches

One-by-one comparisonExpensive behavioural analysisUse of OWL-S based ontologies

IndexesRE indexesGraph indexes

Sub-isomorphism search

Pros & Cons

Pros:These approaches take into account all the behavioral information of the servicesIndexes allow fast narrowing of the results and offer distance measures between the services so we can find similar, but incompatible, servicesSub-isomorphism, in several steps, could allow us to find not just a single service but several that can conform an orchestration which complies with the expected behaviorSome related work is based on chemistry DB and they put a lot of emphasis on scalability

Cons:Although they are able to return similar services, these don't take into account the adaptability of those services

Motivation

Behavior as a first class entity for service discovery"I want to look up a service that can be orchestrated within this business process"

Use indexes to narrow the search and quicken the discoveryAdaptability as an integral part of the discovery

Indexes should support similarity searches which, in turn, return adaptable servicesThe more adaptations are required (adaptation cost), the more distant those services must beExtreme case: avoid heuristics/similarity and search for adaptable services, no matter the adaptation cost

Overview

Restriction:The adaptor is a mere "router" of data with a protocolData and side-effects are features provided and consumed by services at appropriate timesThe adaptor does not make decisions nor generates any new feature

Cases:Message names, extra argument which is not needed,an extra optional branch,some "superfluous" messages,data and message reordering,message splitting and merging, data reutilization

What can be adapted?

Cases:Message names, extra argument which is not needed,an extra optional branch,some "superfluous" messages,data and message reordering,message splitting and merging, data reutilization


<a:!request(S,T);b:?command(S)>

AdaptationContract

Cases:Message names, extra argument which is not needed,an extra optional branch,some "superfluous" messages,data and message reordering, message splitting and merging, data reutilization.


<a:!request();b:?request()>



<a:!request();b:?request()><b:!ack()>



<b:!b()><a:!a(X,Y);b:?a(Y,X)>

<a:?b()>



<a:!login(P)><a:!request(R);b:?request(R,P)>

<a:?reply(D);b:!reply(D)>

Adaptation Example


<a:!quit()>

a:

b:

I is ignored.!quit() is ignored.?noPOI() is not required.

Adaptor

Adaptation Example


<a:!quit()>

a:

b:

This is control driven adaptation but focused on featuresData dependencies steam from the behaviorMessage names are irrelevant in adaptation terms

Discovery through feature deps.

Let's abstract the behavior of a WS by the minimum amount of required features and the maximum amount of provided featuresFeatures can be reused and services have a finite set of features, therefore we can unfold behaviours into trees with the first occurrences of the featuresWe unfold the different traces of adaptation dependencies (AD) and compose them together in an AD-tree

Local choices (IF,WHILE,FOR) are AND nodesExternal choices (PICK) are OR nodes

Any service which complies with the complementary AD-tree of another service can be adapted without generating new data or deadlocks

AD-Tree example

behavior AD-Tree

AD-Tree example

Tree Traversal

Matching between two AD-treesOR: A match exists with any (possibly several) branchesAND: A match exists for every branch!-nodes can be skipped?-nodes require their data from previous !-nodes in the other sideFinal nodes match with final nodes

Sent argumens are carried throughout the trace and received arguments can be reused

Naive Discovery

a:

a:

b:

b:

This index is the "union" of AD-trees with a root OR-node

We must merge equivalent nodes, thoughSome optimizations are possible for having less nodes

We might have both AND-results and OR-results. AND-results must be intersected to obtain feasible resultsThis naive approach has high complexity per query

FD-Rules

AD-Tree

Abstract the behavior into a set of rules which specify which features must be provided before being offered a certain feature

?S is needed before !SS... and which further features are needed to guarantee that an stable state is reached afterwards:

end(SS) requires {D,I,S}FD-rule: SS <- {S} | {I,D}

With OR nodes we keep the least demanding rule and with AND nodes we merge the requirementsDiscovery request are composed with the duals of these rules, e.g.:

S <- {} | {SS} ; {I,D} <- {SS} | {}

AD Search Tree

a:b:

c:

SS <- {S} | {I,D}; SS<- {S} | {}; {S,I} <- {} | {}

AD Search Tree

A query to the AD Search Tree has an time complexity of O(q.f.s.log(s))

q = # of AD-rules in the queryf = # of featuress = # of services in the registry

We have lost the "intra-session dependencies" among several emissions (e.g., !S,!SS and !I).

Therefore adaptation with this approach might need to invoke several instances of a WS

Compositional DiscoveryCompositional discovery is to return several services that, together, can fulfil the queryThere are two straighforward ways to perform compositional discovery with AD Search Tree:

Each FD-rule in the query is answered by a different service

Obtain !S from a: and !SS from b:

We can go further down in the tree if we delegate in other services

We can use a: to satisfy c: to deliver !SS

Future Work

We abstracted a lot of behavioral information, hence further comparisons are needed to refine and rank the candidate services.

Semantic information is missing. Loop tests over AD-Trees would be desirable.

Use in parallel with another behavioral index (graph-based or RE-based) and intersect their results.Final pruning and ranking of the candidates with an in-deep comparison* but without penalizing adaptation.

* See Kozlenkov et al. "Architecture-driven Service Discovery for Service Centric Systems", IJSR, 2007.

Open QuestionsWe need a set of relevant features

Enough arguments to alleviate semantic mismatchesNot so many to hamper adaptation and efficiencyWhat to do with structured or custom data types?Decompose them into a set of elemental data types?Use the 47 built-in datatypes in XML Schema as an starting point?

Are AD search trees expressive enough to quickly differentiate WSs?Are AD search trees space-efficient?What is the complexity of creating and updating AD search trees?There are no behavioral WS, how to evaluate this proposal?

Synthetic examples? TravelAgency?

Thank youAny advise? Comments? Questions?

Thank youAny advise? Comments? Questions?

Criticism completes this work

Trace Index

1. Encode service behavior as regular expressions (RE) of observable communication.

2. Include those RE into a RE-Index [1]. This will be the registry of services.

3. Identify the query as a set of relevant traces.4. Look up those traces in the index.5. The intersection of the services found are candidates for

further comparisons.

[1] C. Y. Chan et al. "RE-tree: an efficient index structure for regular expressions". The VLDB Journal. Springer, 2004.

Behavior Index

1. Encode service behavior as regular expressions (RE) of observable communication.

2. Include those RE into a RE-Index [1]. This will be the registry of services.

3. Identify the query as the RE which represents the expected behavior.

4. "Insert" the query in the index.5. The leaf-node where the query-RE is going to be inserted

contains the candidate services.1. More candidates can be found in the descendants of ancestor

nodes. The farther, the worse (more dissimilar).

[1] C. Y. Chan et al. "RE-tree: an efficient index structure for regular expressions". The VLDB Journal. Springer, 2004.

Behavior Graph Index

Encode service behavior as graphs, Labelled Transitions Systems with specially marked nodes for start and final nodes.Introduce these graphs in a graph index [2,3,...].Queries are composed as "expected behavior" encoded as graphs and using sub-isomorphism graph queries over the index.Several similarity metrics allow us to rank the candidates found: size of the graphs, edit distance [3], common features [2]...

[2] X. Yan et al. "Graph Indexing Based on DiscriminativeFrequent Structure Analysis". TODS. ACM, 2005[3] D. W. Williams et al. "Graph Database Indexing Using Structured Graph Decomposition". ICDE. IEEE, 2007.

Discovery of adaptable services

Technology

Transcript of Discovery of adaptable services