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