310 likes | 452 Views
Supporting Adaptive Web-Service Orchestration with an Agent Conversation Framework . Warren Blanchet, Eleni Stroulia, Renée Elio University of Alberta. Outline . Introduction & Motivation Workflow & Conversations WRABBIT: Workflow reconfiguration Case studies Conclusion & Future work.
E N D
Supporting Adaptive Web-Service Orchestration with an Agent Conversation Framework Warren Blanchet, Eleni Stroulia, Renée Elio University of Alberta
Outline • Introduction & Motivation • Workflow & Conversations • WRABBIT: Workflow reconfiguration • Case studies • Conclusion & Future work ICWS 2005, Orlando
Web services • Pool of available services • User doesn’t care about implementation • Compose services • Use services together to provide higher-level service ICWS 2005, Orlando
Change • Web services accommodate change • …that doesn’t expose itself at the interface level • What about rules on messages exchanged? • Compositions: • No peers: too centralized • Peers: hard to change messages exchanged due to effect on others ICWS 2005, Orlando
Outline • Introduction & Motivation • Workflow & Conversations • WRABBIT: Workflow reconfiguration • Case studies • Conclusion & Future work ICWS 2005, Orlando
Workflow & Conversations • Workflows are processes that produce work products • Distribution of abilities requires cooperation • Cooperation requires communication • Communication requires shared understanding ICWS 2005, Orlando
Conversation model • Agent-communication community • Agents have a shared conversation model • Defines the permissible messages at any point in a conversation • Deviation from this model is a conversation error, which will cause the conversation to fail • This is signaled by a ‘not-understood’ message • Conversation failure indicates the shared model is inconsistent: the parts shared do not match ICWS 2005, Orlando
Web-services Workflow • Accomplishing work: web-services • Controlling flow between services • Equivalent to ‘composition’ • BPEL4WS tailored for separation of work and flow for a given workflow participant • WS-CDL (forthcoming) means to verify correct information flow between participants ICWS 2005, Orlando
Aside on BPEL-based interaction • Suppose a composed service is implemented in BPEL, and has a non-trivial communication protocol • How to ensure the service client conforms? • Inspect by hand • Use a monitoring proxy with an abstract BPEL specification of the client’s communication • Merge the client’s abstract BPEL specification of the client’s communication into the client’s executable BPEL specification • Use an adapter pattern style executable BPEL client specification • Integrate the client’s abstract BPEL specification into the client’s workflow dynamically using constraint-based matching ICWS 2005, Orlando
Observations • Each participant in a workflow can be modeled in BPEL4WS • Each BPEL file specifies the messages exchanged with its partners • The shared workflow model is composed of these per-participant pieces • The shared conversation model is a subset of this workflow model ICWS 2005, Orlando
Goal • Given: • Per-participant workflow model segments (which we call workflow scripts) • Conversation failure detection & signaling • Produce: • A system which can repair inconsistent workflow models (as signaled by conversation failures) automatically ICWS 2005, Orlando
Outline • Introduction & Motivation • Workflow & Conversations • WRABBIT: Workflow reconfiguration • Case studies • Conclusion & Future work ICWS 2005, Orlando
Introduction • WRABBIT: • Workflow Reconfiguration with Agent- and BPEL-Based Intercommunication Technology • Website: • www.cs.ualberta.ca/~stroulia/WRABBIT ICWS 2005, Orlando
Requirements • WRABBIT agents need: • declarative specifications for workflow scripts (BPEL4WS + extra custom stuff) • to execute these scripts • to recognize conversation failures • to determine where to obtain a correct workflow script (if it is at fault) • to retrieve the correct workflow script, if necessary • to incorporate the new workflow script into its operation ICWS 2005, Orlando
WRABBIT Architecture ICWS 2005, Orlando
WRABBIT Details: Messaging • WRABBIT agents use an ACL for a message transport layer • This allows agents to send out-of-band information such as conversation failure signals (not-understood) • A straightforward mapping from WSDL operation types to mini-protocols • one-way: (inform) • request-response: (inform)(request) ICWS 2005, Orlando
WRABBIT Details: Workflow Script Execution • WRABBIT agents may be configured: • to execute particular scripts in response to incoming messages • to execute a script that satisfies some criteria • Workflow scripts inherit BPEL features • importantly can be executable or abstract ICWS 2005, Orlando
WRABBIT Details: Workflow Script Composition • Why leave scripts abstract? • Loose coupling • Easy updating • WRABBIT agents compose abstract scripts automatically through means-end analysis • Others have done this more thoroughly, this work uses a very simplistic method, and assumes a better mechanism exists ICWS 2005, Orlando
WRABBIT Details: Conversation Failure Detection • WRABBIT agents use the BPEL-derived workflow scripts to detect conversation failure • Failure categories: • Invalid content: message payload unfamiliar • Invalid sender: the model does not allow this sender for this message • Message unexpected: the message is not valid in the current context ICWS 2005, Orlando
WRABBIT Details: Conversation Failure Recovery • WRABBIT agents first determine who is the authority for a given failure • May depend on failure type, workflow script, etc. • WRABBIT agents rely on a shared policy to determine the authority • Then, agents exchange the files that define the authoritative workflow script ICWS 2005, Orlando
Outline • Introduction & Motivation • Workflow & Conversations • WRABBIT: Workflow reconfiguration • Case studies • Conclusion & Future work ICWS 2005, Orlando
Environment • Academic department • Agents: • Instructor • Department administration employee • Story: • the Department agent dispenses student transcripts • the Instructor agent uses this service ICWS 2005, Orlando
Missing Precondition Study • Change: • To get a student transcript, you now have to provide an authorization token • A separate service of the Department agent provides these tokens • The token is provided in a new message at the beginning of the agents’ interaction ICWS 2005, Orlando
Missing Precondition Study (2) • The Department agent is updated • The Instructor agent has not • The Instructor agent begins the conversation with the first message (from its perspective) which is the second message from the Department agent’s view • Not-understood! ICWS 2005, Orlando
Missing Precondition Study (3) • The Department agent is the authority, so it does nothing • The Instructor gets the new script from the Department agent • The Instructor then retries • It discovers it needs to satisfy the new abstractness • It does so with the authorization workflow, and successfully obtains its transcript ICWS 2005, Orlando
Missing Precondition Study Trace ICWS 2005, Orlando
Outline • Introduction & Motivation • Workflow & Conversations • WRABBIT: Workflow reconfiguration • Case studies • Conclusion & Future work ICWS 2005, Orlando
Summary • WRABBIT • is an agent-based (peer-to-peer, distributed) framework • executes BPEL4WS web-service compositions • identifies and dynamically recovers from conversation failures • has been tested with case studies ICWS 2005, Orlando
Contributions • WRABBIT enables flexibility • Service owners can change their services without an involved migration process • Service ownership can be distributed without anarchy ICWS 2005, Orlando
Future work • Better support for new script preconditions • Rollback/compensation • Negotiation policies ICWS 2005, Orlando
Questions? • blanchet@cs.ualberta.ca • www.cs.ualberta.ca/~stroulia/WRABBIT ICWS 2005, Orlando