1 / 45

A Visual Query Language for Business Processes

A Visual Query Language for Business Processes. Catriel Beeri Hebrew University Anat Eyal, Simon Kamenkovich, Tel Aviv University Tova Milo. Outline. Introduction and motivation Overview by example System and query formal model Compact representation of query answers

vina
Download Presentation

A Visual Query Language for Business Processes

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. A Visual Query Language for Business Processes Catriel Beeri Hebrew University Anat Eyal, Simon Kamenkovich, Tel Aviv University Tova Milo

  2. Outline • Introduction and motivation • Overview by example • System and query formal model • Compact representation of query answers • Implementation • Summary Beeri, Eyal, Kamenkovitch, Milo 2006

  3. CreditResponse InventoryResponse CreditCheck Purchase Order ReserveInventory Invoice The Standard Example Credit Service Consolidate Results PO Service Client Inventory Service Beeri, Eyal, Kamenkovitch, Milo 2006

  4. Web Services Meet Business Processes Local to company A Web Service 1 Web Service 4 Web Service 2 Web Service 5 Web Service 3 Web Service n At company B On the Web Company A business process Beeri, Eyal, Kamenkovitch, Milo 2006

  5. Recent History ofBusiness Process Standards BPML (Intallio et al) BPSS (ebXML) WSCI (Sun et al) WS-Choreography (W3C) 2000/05 2001/03 2001/05 2001/06 2002/03 2002/06 2002/08 2003/01 2003/04 XLang (Microsoft) WSFL (IBM) WSCL (HP) BPEL4WS 1.0(IBM, Microsoft) BPEL4WS 1.1(OASIS) BPEL Beeri, Eyal, Kamenkovitch, Milo 2006

  6. 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 Beeri, Eyal, Kamenkovitch, Milo 2006

  7. 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 inqueryingthem: “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 Beeri, Eyal, Kamenkovitch, Milo 2006

  8. 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 querymodels Beeri, Eyal, Kamenkovitch, Milo 2006

  9. Why not XQuery?(on XML representation of conceptual model) Additional requirements from query language : • Graphs rather than trees • Queries about control & data flowpaths • Need to query at different level of granularity • Zoom-in/zoom-out • P2P architecture: Specs are distributed  We use a home-brewed QL Beeri, Eyal, Kamenkovitch, Milo 2006

  10. 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... Beeri, Eyal, Kamenkovitch, Milo 2006

  11. Outline • Introduction and motivation • Overview by example • System and query formal model • Compact representation of query answers • Implementation • Summary Beeri, Eyal, Kamenkovitch, Milo 2006

  12. 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) Beeri, Eyal, Kamenkovitch, Milo 2006

  13. Travel Agency Process Beeri, Eyal, Kamenkovitch, Milo 2006

  14. Zoom In Beeri, Eyal, Kamenkovitch, Milo 2006

  15. Queries Use 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 Beeri, Eyal, Kamenkovitch, Milo 2006

  16. Query1: provided operations? Beeri, Eyal, Kamenkovitch, Milo 2006

  17. Query2: used credit card services? local Beeri, Eyal, Kamenkovitch, Milo 2006

  18. Query3: search without login? Beeri, Eyal, Kamenkovitch, Milo 2006

  19. Query4: data flow Data elements affected by searchRequest and affecting returnTripResults Beeri, Eyal, Kamenkovitch, Milo 2006

  20. Outline • Introduction and motivation • Overview by example • System and query formal model • Compact representation of query answers • Implementation • Summary Beeri, Eyal, Kamenkovitch, Milo 2006

  21. Formal Model System: • Process graphs + implementation function • Graph refinement (graph rewriting) Query: Process patterns + implementation function Beeri, Eyal, Kamenkovitch, Milo 2006

  22. System example implementation Beeri, Eyal, Kamenkovitch, Milo 2006

  23. Refinement (rewriting) searchTrip refined to Beeri, Eyal, Kamenkovitch, Milo 2006

  24. 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 Beeri, Eyal, Kamenkovitch, Milo 2006

  25. 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 Beeri, Eyal, Kamenkovitch, Milo 2006

  26. system answer query A1 B2 B3 *4 A B C Examples: A1 B2 B3 C4 Beeri, Eyal, Kamenkovitch, Milo 2006

  27. System: A B C D A B C Examples: Query A1 B2 B3 *4 A1 B2 D3 Answer: A1 B2 B3 C4 A1 B2 C B D3 Beeri, Eyal, Kamenkovitch, Milo 2006

  28. Outline • Introduction and motivation • Overview by example • System and query formal model • Compact representation of query answers • Implementation • Summary Beeri, Eyal, Kamenkovitch, Milo 2006

  29. Large or Infinite answers! Many fork/joins  exponential number of paths Beeri, Eyal, Kamenkovitch, Milo 2006

  30. 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 Beeri, Eyal, Kamenkovitch, Milo 2006

  31. Recursive zoom-in Beeri, Eyal, Kamenkovitch, Milo 2006

  32. A query with an infinite answer Beeri, Eyal, Kamenkovitch, Milo 2006

  33. Finite representation Beeri, Eyal, Kamenkovitch, Milo 2006

  34. 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 Beeri, Eyal, Kamenkovitch, Milo 2006

  35. Answer construction Observations: • 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 Beeri, Eyal, Kamenkovitch, Milo 2006

  36. Node mapping/answer construction The 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 C B D3 A1 B2 D3 Beeri, Eyal, Kamenkovitch, Milo 2006

  37. 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 Beeri, Eyal, Kamenkovitch, Milo 2006

  38. 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 Beeri, Eyal, Kamenkovitch, Milo 2006

  39. Query : System : A A D A B B E B C C C F Beeri, Eyal, Kamenkovitch, Milo 2006

  40. 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 Beeri, Eyal, Kamenkovitch, Milo 2006

  41. Outline • Introduction and motivation • Overview by example • System and query formal model • Compact representation of query answers • Implementation • Summary Beeri, Eyal, Kamenkovitch, Milo 2006

  42. 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 Beeri, Eyal, Kamenkovitch, Milo 2006

  43. High Lights of Model & QL Base system unit: directed node-labeled graph QL primitives|: • /, // (forward axis only) • Nodeequality • Node labelequality • 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 Beeri, Eyal, Kamenkovitch, Milo 2006

  44. 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 Beeri, Eyal, Kamenkovitch, Milo 2006

  45. Future work • Investigate queries on logs Does this pattern exist? • “Querying of runs” – essentially verification • “Marxist” extensions to QL primitives Beeri, Eyal, Kamenkovitch, Milo 2006

More Related