Service technology based on process models Dr.ir. Arjan J. Mooij (arjan.mooij@esi.nl)

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

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

Service modeled as an open Petri net

Two compatible services

Two compatible services and their composition

Some other compatible services

Incompatible services

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?

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

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

!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

Tool support: Wendy Most-permissive controller Operating guidelines

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

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?

Running example

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

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

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

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

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.

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

Running example

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

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)

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.

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)

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

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)

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

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.

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)

Running example: computed adapter

Running example: computed adapter

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

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

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

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

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 http://www.service-technology.org/tools/wendy/ Marlene http://www.service-technology.org/tools/marlene/ Live! http://www.service-technology.org/live/

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

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

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