A Visual Query Language for Business Processes

A Visual Query Language for Business Processes

Catriel Beeri Hebrew University

Anat Eyal, Simon Kamenkovich, Tel Aviv UniversityTova Milo

Beeri, Eyal, Kamenkovitch, Milo 2006 2

Outline

Introduction and motivation

Overview by example

System and query formal model

Compact representation of query answers

Implementation

Summary


The Standard Example

ClientPO Service

Credit Service

Inventory Service

Purchase Order

Credit

Check

ReserveInventory

Credit

Response

InventoryResponse

InvoiceConsolidate

Results


Web Services Meet Business Processes

Web Service 1

Web Service 2

Web Service 3

Web Service 4

Web Service 5

Web Service n

Company A business process

Local to company A

At company B On the Web


Recent History of Business Process Standards

2000/05

XLang(Microsoft)

2001/03

BPML(Intallio et al)

2001/05

WSFL(IBM)

2001/06

BPSS(ebXML)

2002/03

BPEL4WS 1.0 (IBM, Microsoft)

BPEL4WS 1.1(OASIS)

2002/06 2003/01

WS-Choreography(W3C)

2003/04

WSCI(Sun et al)

WSCL(HP)

2002/08

BPEL


BPEL in a nutshell

Business process -- control and data flow

• Actions: – atomic

– compound : fork, join, while, procedure/process call,…

• Process spec. represented in XML

• Commercial products:– design tools with “conceptual” model

– Application generators compile to executable code

– Application servers execute the code


Points to note

• Not just a modeling language: applications are automatically generated from the (relatively declarative) specs.

• There will be plenty of such specs around

• Specs are data; a lot of interest in querying them:

“What kind of credit services are used (in)directly”?

“How can I buy a plane ticket ?”

“Can one get a price quote without giving first credit card info?”

motivation for developing a query facility


Can a QL be based on BPEL?

NO!

The BPEL XML representation is machine oriented,

unfit for human consumption

It decomposes the system diagram into a (XML-based)

relational representation of nodes and edges

loss of understanding + queries will require lots of joins

Need: Similarity of system and query models


Why not XQuery?(on XML representation of conceptual model)

Additional requirements from query language :

• Graphs rather than trees

• Queries about control & data flow paths

• Need to query at different level of granularity– Zoom-in/zoom-out

• P2P architecture: Specs are distributed

We use a home-brewed QL


Querying Specs, not Runs

• Not the same semantics– Q: “ does the spec contain these two operations ? ”

– V: “ can there be a run that contains these two operations?“

• Querying the specs is – Cheaper (specs are data, not possible executions)

– Gives a reasonably good approximation for actual runs

• A (practical) problem with verification:

It needs a clear semantics...


Outline


Overview by example



Implementation

Summary


A system specification

• Property, data & activity nodes

• Control and data flow edges

• A process is a di-graph of atomic and compound activities

• Compound activities can be zoomed-in (a-la statecharts)


Travel Agency Process


Zoom In


QueriesUse process patterns (like tree patterns for xml) • Single/double-headed edges (compare to / and // in XPath)

– – edges – – paths of arbitrary length

• Single/double-bounded activities: – w/o zoom-in

– unbounded zoom-in

• Allow * as node label• Node label variables• Mark requested nodes/edges by


Query1: provided operations?


Query2: used credit card services?

local


Query3: search without login?

"Ø $Ø


Query4: data flowData elements affected by searchRequest and affecting returnTripResults


Outline


Overview by example



Implementation

Summary


Formal Model

System:• Process graphs + implementation function• Graph refinement (graph rewriting)

Query:Process patterns + implementation function


System example

Alpha-tours

serviceprovider

behaviorsearchCars searchRoomssearchFlights

fork

getTripRequest

join

...

searchTrip

reserveTrip

cancelTrip

startTrip

endTrip

startSearch

endtSearch...

confirmTrip

provided

provided

provided provided

requestedrequested

requested

capability

implementation


Refinement (rewriting)

Alpha-tours

serviceprovider

behavior

searchCars searchRoomssearchFlights

fork

getTripRequest

join

reserveTrip

cancelTrip

startTrip

endTrip

startSearch

endtSearch

confirmTripprovided

provided

requestedrequested

requested

capability

...

...provided

searchTrip

refined to


Query

Process patterns:• * node labels, node variables • Nodes / edges can be marked as transitive

– Transitive edges: paths of arbitrary length

– Transitive node: refinements of arbitrary depth

• Nodes / edges can be marked as output

Patterns related by a query implementation function


Query semantics• An embedding: a mapping

– from: query graphs (with uniquely identifiable nodes)– to: [refinements of] process graphs

satisfying conditions:(nodes): preserves nodes types and labels(edges): edge mapped to

edge mapped to a path (imp): preserves implementation relationships

• A result: image of query graph under an embedding• Answer: all results

m n ( ) ( )m n m n ( ) .... ( )m n


Examples:

A B C A1 B2 B3 *4

A1 B2 B3 C4

answersystem query


Examples:

A B C

A1 B2 B3 *4

A1 B2 B3 C4

Answer:

System:

Query

A B C D

A1 B2 D3

A1 B2 C B D3


Outline


Overview by example



Implementation

Summary


Many fork/joins exponential number of paths

Large or Infinite answers!


Infinite answers can be generated by either

• Cycles in process graph (example seen previously)

• Cycles (recursion) in zoom-in relationships Infinite # of refinements

Path vars (double headed edges) + cycles

infinite # of results


Recursive zoom-in


A query with an infinite answer


Finite representation


Systems and queries are essentially regular graph grammars

• Bad news: not closed under intersection (general case)

• Good news: – Our systems and queries are sufficiently simple:

Psize representation (as a regular grammar) can be computed in Ptime (data complexity!)

skip


Answer constructionObservations:• Embeddings (results) can be composed of query pattern to system process embeddings (results)

glue: the constraint (imp)

• Multiple embeddings can be represented by

a shared node mapping

(that satisfies (nodes) and (edges) -- a homomorphism)

Construction of node mappings is the core problem


Node mapping/answer constructionThe simple case: from pQ to pS (not into refinement) :• Find node mappings that satisfy (nodes), (edges):

NP-complete in pQ (query) , Ptime in pS (data)

• Results are 1-1 images of mappings:– each query node is distinct,– new nodes and edges for paths (images of )

A B C D

A1 B2 D3A1 B2 C B D3


The complex case: from pQ to refinement of pS :• A mapping may be split into parts:

– into pS itself – into implementation of a compound action of pS, and so on

with double-headed edges – to any depth, including cycles

Observations: • Only sub-graphs of pQ with single entry/exit can be

mapped to an implementation • In one mapping, a disjoint set of such graphs can be

mapped to an implementation


The construction: For each pQ and pS :

• For disjoint set J of such sub-graphs, construct mappings for pQ/J (each member of J replaced by $* node) to pS

• Do same for also for these sub-graphs

• Glue together using by a regular grammar:– $* nodes (suitably labeled) are non-terminals

– Each node (for G) is associated with the mappings for G


C

Query :

A

B

B

F

D

E

C

A

B

System :

A

C


Extensions to QL:

• OK extensions:– label predicates , – Regular path expressions (on node labels),– Negation, – Joins on node labels

• Not OK extensions : – Joins on path variables

• The result is not a regular graph grammar• Emptiness is undecidable• NP-hard even without cycles and recursion


Outline


Overview by example



Implementation

Summary


• Simple and intuitive query formulation similar to how processes are specified

• Operates in distributed environment• System and queries modeled as graph grammars

allows compact representation of large/infinite answers

• Ignores semantics of composite actions• AXML as an implementation platform supports

– Transparent distribution

– Taking advantage of built-in optimizations


High Lights of Model & QLBase system unit: directed node-labeled graphQL primitives|:• /, // (forward axis only)• Node equality• Node label equality• Node label predicates• Regular expressions on node labels in paths • Negation on sub-patterns Can be seen as adaptation of XPath to di-graphs, but

selection not restricted to one path


Advanced system structure: an infinite family of directed node-labeled graphs, specified by a

graph grammar

Additional QL primitives:• double-headed node: query on all graphs derived

from a given graph• Answer representation as a graph grammar


Future work

• Investigate queries on logsDoes this pattern exist?

• “Querying of runs” – essentially verification• “Marxist” extensions to QL primitives

Documents

A Visual Query Language for Business Processes