1. Service technology based on process models
Dr.ir. Arjan J. Mooij

2. Service-oriented architecture
Service Broker
publish
find
bind
Service Provider
Service Requester

3. What does compatible mean?
Service broker
Core functionality:
Given a service requester
Select a compatible service provider
What does compatible mean?

4. Service modeled as an open Petri net

5. Two compatible services

6. Two compatible services and their composition

7. Some other compatible services

8. Incompatible services

9. How to represent all controllers?
Service broker
Core functionality
Given a service requester
Select a compatible service provider
Controller
Notion of compatibility
How to represent all controllers?

10. Formalisms: Open Petri net  State machines
?Euro
?TBut
?CBut
!Tea
!Coffee

11. Most-permissive controller
?Euro
?TBut
?CBut
!Tea
!Coffee
!Euro
!TBut
!CBut
?Tea
?Coffee

12. !Euro !TBut !CBut ?Tea ?Coffee ?Euro ?TBut ?CBut !Tea !Coffee
Operating guidelines
!Euro
!TBut
!CBut
?Tea
?Coffee
!CBut ˅ !TBut
!CBut ˅ !Euro ˅ !TBut
final
?Euro
?TBut
?CBut
!Tea
!Coffee

13. Tool support: Wendy
Most-permissive controller Operating guidelines

14. Operating guidelines: some compatible services
!Euro
!CBut
?Coffee
!Euro
!TBut
!CBut
?Tea
?Coffee
!Euro
!CBut
?Coffee
?Coffee
!Euro
!CBut

15. What if there is no compatible service provider?
Service broker
Core functionality
Given a service requester
Select a compatible service provider
Controller
Notion of compatibility
Operating guidelines
Compact representation of all controllers
What if there is no compatible service provider?

16. Running example

17. Running example: incompatibilities
Integration problems:
incompatible interface ports
composition has undesirable behavioral properties …

18. Running example: towards an adapter
Using this adapter:
compatible interface ports …

19. Running example: an adapter
Using this adapter:
compatible interface ports
after composition: deadlock freedom, weak termination, etc. …

20. Running example: another adapter?
Using this adapter:
compatible interface ports
after composition: deadlock freedom, weak termination, etc. …

21. Adapter specification
Requirements on composition of the adapter with the services:
closed interface: fitting connectors, same set of message types, etc.
some behavioural property: deadlock freedom, weak termination, etc.
maybe some application specific goal?
Requirements on the structure of the adapter:
implementable data transformations: meters to inches, etc.
preserve the semantics of the messages: switch on, or switch off
Given asynchronous communication, we assume that:
adapters may buffer messages: delaying, reordering, etc.

22. Specification of the Elementary Activities (SEA)
Each elementary activity is specified as a transformation rule
B  C
B and C are bags of message types (names of interface places)
by consuming B messages, C messages can be produced
focus on what can be done, not on whether, when or how
The available rules depend on the semantics of the messages:
Creation a
(e.g., electronic, but no password)
Copy
a  a, a
(e.g., electronic)
Delete
a 
(e.g., electronic, but not legal)
Transform
a  b
(e.g., data conversion)
Split contents
a  b, c
Merge contents
a, b  c

23. Running example

24. Running example: adapter specification
Transformation rules
dEuro 
mEuro
mCBut
mTBut
mCoffee
dCoffee
Behavioral property:
Deadlock freedom

25. Adapter generation (without SEA restrictions)
Given two services P and R with disjoint sets of interface places:
wish: an adapter A, such that P + A + R is closed and deadlock free
associativity and communitativity of composition operator ‘+’
P + A + R = (P + R) + A
that is, A is a controller for P + R
Reduction to controller synthesis:
given a service P
C is a controller for P if P + C is closed and deadlock free
(This can be generalized to other behavioral properties)

26. Adapter generation (with SEA restrictions)
Given two services P and R, and an SEA
Two-piece adapter structure (data and control):
Engine E: SEA-based message transformations;
Controller C: controller for P + E + R.
The final adapter A is C + E.

27. The engine has three interfaces:
interface to given service P: complement of P’s interface
interface to given service R: complement of R’s interface
interface to controller C: new interface (to be determined later on)

28. For delaying and re-ordering of messages, we introduce:
Engine
For delaying and re-ordering of messages, we introduce:
for every interface place m an internal place (m, c)
for every input place m, a transition with notification
for every output place m, a transition with enabler

29. For each SEA rule rR we introduce a transition:
Engine
For each SEA rule rR we introduce a transition:
that applies the transformation on the internal places
that has an enabler (rR, e)
that has a notifier (rR, n)

30. Properties of such adapters
By construction, we have that the adapter C + E
only applies SEA operations to the messages between P and R;
contains a transition for every SEA rule;
is a controller of P + R
(i.e., the composed system is closed and deadlock free)
Conceptual separation of data and control in C and E

31. Tool chain
Push-button technology for generating adapters:
given two open nets P and R, and a given SEA;
generate from the SEA an engine E (an open net);
compose the open nets P, R and E;
apply Petri net reduction rules;
use Fiona/Wendy to synthesize an operating guideline;
use Fiona/Wendy to derive a controller (a transition system);
use Petrify/Genet to transform the controller to an open net C;
compose the open nets C and E;
apply Petri net reduction rules.

32. Performance is mainly influenced by:
Tools
Performance is mainly influenced by:
Fiona/Wendy: state space of P + E + R
Petrify/Genet: size of the controller C as an automaton (FSM)

33. Running example: computed adapter

34. Running example: computed adapter

35. Goal: reduce concurrency between engine and controller
Alternative engine
Goal: reduce concurrency between engine and controller
use asynchronous communication with given services (as before)
use synchronous communication with the controller

36. Running example: computed adapter
Performance benefits:
the state space explored by Fiona/Wendy is smaller
the controller generated by Fiona/Wendy is smaller

37. Asynchronous Synchronous Experimental results Asynchronous/Vendor:
Petrify takes more time than our patience admits
substantial speed-ups using synchronous interface
smaller results using synchronous interface
Asynchronous
Synchronous
Size (p/t/a)
Time (s)
Time(s)
Coffee
22/11/31 1
11/3/11
Coffee*
40/33/172 2
9/2/9
Ticket
45/22/80
17/6/23
Car
56/28/91 60
29/10/43
Vendor ?
23/8/36

38. Asynchronous Synchronous Experimental results Asynchronous/Vendor:
Petrify takes more time than our patience admits
substantial speed-ups using synchronous interface
smaller results using synchronous interface
Asynchronous
Synchronous
states
control
state reduction
interface
Coffee
9162 56
168 11
55 (~ 26)
Coffee*
9853 65 9
59 (~ 26)
Ticket
7811
256 21 13
372 (~ 29) 12
Car
180833
2624
242
100
747 (~ 210) 14
Vendor
541956
59504 64 35
8468 (~ 213) 17

39. Operating guidelines: Adapter specification:
Summary
Operating guidelines:
compact representation of all controllers
Adapter specification:
behavioral models of the given services
behavioral property on the composed system
specification of the elementary activities (SEA)
Adapter generation
Adapter = engine + synthesized controller
Service-technology.org:
Wendy
Marlene
Live!

40. Bonus example Tourist Cook: Gives the money, and waits for food
Food is only guaranteed after an order, but before any money

41. Bonus example Tourist Cook: Gives the money, and waits for food
Food is only guaranteed after an order, but before any money
Transformation rules 
cOrder
cFood
tFood
tMoney
cMoney

42. Tourist --- Adapter --- Cook
Bonus example
Tourist Adapter Cook
Adapter = tour guide?