Workflow Metadata John Koisch, Guidewire Architecture

Overloaded Workflow Workflow has at least four connotations that could be in play: – Clinical Workflow – what a care giver does at the point of care – UI Workflow – the way User Interfaces support users managing and moving between sets of information – Business Process Workflow – usually captured in BPMN or Activity diagrams, with underlying process semantics captured – Automated Managed Workflow – configurations on software components that handle long running transactions and their state semantics

Behavioral Framework Provides facilities for decomposing systems in a distributed environment – Separates based on Accountability How to describe what a system does? What system does what when? How can systems be bound to various business processes?

BF and Workflow The BF can describe both Business Process Workflow and Automated Managed Workflow – Interoperability Specifications, when complete, tie ODP Enterprise Viewpoint with Computational + Informational Correspondence view Computational + Informational + Engineering Correspondence view – This allows Community Obligations to be bound to systems Contract Driven view Assumption: that most discussions are about Automated Managed Workflow Choreographies or Orchestrations

Interoperability Specifications Interoperability Specifications are described in the BF as Solution Specifications The BF provides a framework for discussing these in an technology / platform / environmentally neutral way But to really get to usability, you have to see how Interoperability Specifications look within a given architecture – They look very different in a SOA than in a P2P environment Responsibility is apportioned differently

Interoperability Specifications and Contracted Obligations

Interoperability Specifications assemble expected behaviors

Interoperability Specs in caCIS Relies on Emerging Ontologies for – Behavior – Information These appear in the deployed architecture very often as patterns – QRL

QRL Query, Retrieve, Locate applies common behavioral semantics to Various Information types This means the contract, and the context, is the same, regardless of information exposed – Common Error Handling – Common expectations of service Information Model Resolution, e.g. – Common operations Not tied to persistence Not tied at specification time to information expression – Semantic Signifiers are used to express what is supported by a given QRL instance – Services are Self Describing

One QRL Functional Profile This Profile is QueryByParameter – Assumes infrastructure (knowledge by the client of the model) – However, contains operations to describe these things – Very similar to Data Services, but not tied to object models or persistence

QRL is Useful We use QRL in many places It is not a generic CRUD solution It is heavily contextualized

QRL in the NCI QRL would provide the underpinnings for distributed queries – Can be bound early or late to underlying information ontologies – Can categorize information endlessly in an extensible, reproducible way