This is the talk I gave at ECOWS'10. This work passed through an acceptance rate of 19% (http://goo.gl/Atqic) If we want to create a system out of various stateful services, we have to cope up with their different interfaces and protocol/behavior. We already presented papers which tackled how to recognize these differences (http://goo.gl/z9CAX) and build upon them (http://goo.gl/y1aIH). Now we develop a scalable technique to discover these incompatible, yet useful, services

1. Feature-Based Discovery of
Services with Adaptable Behaviour
J. Antonio Martín and Ernesto Pimentel
University of Málaga
Spain
3 of December, 2010 Ayia Napa, Cyprus ECOWS'10

2. Introduction
a:
We assume Web
services have
complex behavior
E.g., Web services
described as BPEL
processes

3. Mismatches
a:
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 b:
usefull services
Adaptable services
are usefull services

4. Adaptation
a:
Behavioral adaptation
deploys an adaptor in the
middle of the communication
which overcomes signature
and behavioral
incompatibilities
Adaptors are
described by b:
abstract
adaptation
contracts

5. Adaptation
Adaptation a:
Contract
<b:?find(S);a:!request(S,I)>
<b:!results(SS);a:?POIlist(SS)>
<a:!quit()>
Adaptors are generated from
adaptation contracs
Adaptation contracs can
b:
be designed or
automatically created
We focus the dicovery
on adaptability
requirements

6. Current Approaches
One-by-one comparison
Expensive behavioural analysis
Use of OWL-S based ontologies
Indexes
RE indexes
Graph indexes
Sub-isomorphism search

7. Pros & Cons
Pros:
These approaches take into account all the behavioral
information of the services
Indexes allow fast narrowing of the results and offer
distance measures between the services so we can find
similar, but incompatible, services
Sub-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 behavior
Some 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

8. 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
discovery
Adaptability as an integral part of the discovery
Indexes should support similarity searches which, in
turn, return adaptable services
The more adaptations are required (adaptation cost),
the more distant those services must be
Extreme case: avoid heuristics/similarity and search
for adaptable services, no matter the adaptation cost

9. Overview

10. What can be adapted?
Restriction:
The adaptor is a mere "router" of data with a protocol
Data and side-effects are features provided and
consumed by services at appropriate times
The 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

11. 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)>
Adaptation
Contract

12. 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();b:?request()>

13. 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();b:?request()>
<b:!ack()>

14. 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.
<b:!b()>
<a:!a(X,Y);b:?a(Y,X)>
<a:?b()>

15. 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:!login(P)>
<a:!request(R);b:?request(R,P)>
<a:?reply(D);b:!reply(D)>

16. Adaptation Example
a:
<b:?find(S);a:!request(S,I)>
<b:!results(SS);a:?POIlist(SS)>
<a:!quit()>
I is ignored.
!quit() is ignored.
?noPOI() is not required. b:
Adaptor

17. Adaptation Example
a:
<b:?find(S);a:!request(S,I)>
<b:!results(SS);a:?POIlist(SS)>
<a:!quit()>
This is control driven adaptation
but focused on features
Data dependencies steam from
the behavior
b:
Message names
are irrelevant in
adaptation terms

18. 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 features
Features can be reused and services have a finite set of
features, therefore we can unfold behaviours into trees
with the first occurrences of the features
We unfold the different traces of adaptation dependencies
(AD) and compose them together in an AD-tree
Local choices (IF,WHILE,FOR) are AND nodes
External 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

19. AD-Tree example
behavior AD-Tree

20. AD-Tree example

21. Tree Traversal
Matching between two AD-trees
OR: A match exists with any
(possibly several) branches
AND: A match exists for every
branch
!-nodes can be skipped
?-nodes require their data from
previous !-nodes in the other
side
Final nodes match with final
nodes
Sent argumens
are carried throughout the trace and
received arguments can be reused

22. Naive Discovery
This index is the "union" of AD-
trees with a root OR-node
We must merge equivalent
nodes, though
Some optimizations are
possible for having less
nodes
We might have both AND-results b:
and OR-results. AND-results
must be intersected to obtain
feasible results a:
This naive approach has high
complexity per query b: a:

23. FD-Rules
Abstract the behavior into a set of rules
which specify which features must be
provided before being offered a certain AD-Tree
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 requirements
Discovery request are composed with the
duals of these rules, e.g.:
S <- {} | {SS} ; {I,D} <- {SS} | {}

24. AD Search Tree
c:
b: a:
SS <- {S} | {I,D}; SS<- {S} | {}; {S,I} <- {} | {}

25. 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 query
f = # of features
s = # 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

26. Compositional Discovery
Compositional discovery is to return
several services that, together, can
fulfil the query
There 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

27. 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.

28. Open Questions
We need a set of relevant features
Enough arguments to alleviate semantic mismatches
Not so many to hamper adaptation and efficiency
What 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?

29. Thank you
Any advise? Comments? Questions?

30. Thank you
Any advise? Comments? Questions?
Criticism completes this work

31. 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.

32. 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.

33. 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 Discriminative
Frequent Structure Analysis". TODS. ACM, 2005
[3] D. W. Williams et al. "Graph Database Indexing Using Structured Graph
Decomposition". ICDE. IEEE, 2007.