chapter 19 process integration
DESCRIPTION
Chapter 19 Process Integration. Lachlan Aldred. Overview. Introduction. Introduction. Process Integrations (PIs) need to couple (connect) differently depending on the purpose of integrating. E.g. Feedback or Fire-and-forget - PowerPoint PPT PresentationTRANSCRIPT
a university for the worldrealR
WW LLLYYY AA
© 2009, www.yawlfoundation.org YYY
Chapter 19 Process Integration
Lachlan Aldred
a university for the worldrealR
2WW LLLYYY AA
YYYYY
© 2009, www.yawlfoundation.org
Overview
• Introduction
a university for the worldrealR
3WW LLLYYY AA
YYYYY
© 2009, www.yawlfoundation.org
Introduction
• Process Integrations (PIs) need to couple (connect) differently depending on the purpose of integrating.
– E.g. Feedback or Fire-and-forget– Terms such synchronous/ asynchronous, point-to-point publish
subscribe refer to this coupling but have many meanings.
• Industry solutions create adapters in earnest. One of the most compelling Process Integration products claims over 350 adapters.
– No real support for aligning coupling with intent.– It is as if the what (the thing being integrated with) has
drowned out the how (online/offline).
a university for the worldrealR
4WW LLLYYY AA
YYYYY
© 2009, www.yawlfoundation.org
Introduction …
• Languages for process integration are not taken seriously enough.
– Important efforts such as BPEL and BPMN are not given the mindshare they deserve.
– Neither is formally defined.– Neither can handle correlated event processing.
• This lecture will not solve process integration.– Merely lay some conceptual groundwork.– Rediscover and redefine some old ideas.– Perhaps show some attributes we’ll see in future languages.
a university for the worldrealR
5WW LLLYYY AA
YYYYY
© 2009, www.yawlfoundation.org
Process Integration as a Field of Endeavour
• Workflow Reference Model (WRM) defined 5 interfaces– Interface 3 addresses invoking remote applications from a
process.– Interface 4 addresses being integration with remote processes.
– Large effort - requires programming to these interfaces.
• BPM systems and ESBs superseded WRM.– moved/reduced the need to program to APIs.– Represented a major improvement for business users.
• BPEL enabled SOA paradigm applied to Business Processes.
– Interfaces 3 & 4 of WRM became invoking a Web services and exposing a process as a Web service – simple.
– Sending incoming requests to the right process instance was addressed cleanly through Correlation-sets.
a university for the worldrealR
6WW LLLYYY AA
YYYYY
© 2009, www.yawlfoundation.org
Why do we Care?
• BPEL is a language for Process Integration so why improve it?
• Expressive– Can’t step outside of the Web service paradigm.– Can’t handle correlated event processing.– Models cannot discriminate between tightly coupled and
loosely coupled middleware (middleware is hidden in the WSDL binding).
• Conceptualisation– No publish-subscribe construct.– Over the wire message format exposed to process layer.
a university for the worldrealR
7WW LLLYYY AA
YYYYY
© 2009, www.yawlfoundation.org
Why do we Care …?
• BPEL is…
• Suitability– Difficult to model batch message processing.– Difficult to model message filtering.
• Understandable– No graphical representation.– One sided: can’t model two integrated processes together.
• Precise– Rules of BPEL written in English : ambiguity, interpretation.
a university for the worldrealR
8WW LLLYYY AA
YYYYY
© 2009, www.yawlfoundation.org
Process Integration is not Trivial
• Heterogeneity – of process engines, middleware, applications (most challenging)
• Uncertainty/trust– 2 Generals paradox – Cannot trust that other general will co-attack based on
messages.– There is no message protocol that can guarantee intent.
• Reliability– Latency of messages (delays, stale data)– Lost messages, duplicates deliveries.
• Events – Don’t wait for them to occur – just handle it if it occurs.– Composite events : Don’t do anything unless getX(Event_A) =
getX(Event_B)
a university for the worldrealR
9WW LLLYYY AA
YYYYY
© 2009, www.yawlfoundation.org
Process Integration is not Trivial …
• Batch Messaging– handle/create large numbers of messages.– Avoid clumsy loops and lists
• Conversations– Avoid clumsy correlation IDs.– Correlation ID variables– Technology agnostic– Nested conversations
• Channel passing– Processes learn of new message source/sinks through
message contents.– Technology agnostic
a university for the worldrealR
10WW LLLYYY AA
YYYYY
© 2009, www.yawlfoundation.org
Conceptualizing PI
• Conceptual modelling community have learned that conceptualising a domain has pitfalls.
• Avoiding pitfalls - guiding principles:– 100 percent principle:
• Every aspect of process integration should be describable.
• Full expressiveness. No need to express aspects of process integration outside the language.
– Conceptualization principle:• Only need to express relevant aspects.
• Avoid needing to express every low-level detail (e.g. access credentials, message formats).
a university for the worldrealR
11WW LLLYYY AA
YYYYY
© 2009, www.yawlfoundation.org
Conceptualizing PI …
• Software development community have learned that abstracting a domain can fail:
• e.g. Law of Leaky abstractions:– “all non-trivial abstractions, to some degree, are leaky“
(Spolsky).– Abstract APIs can save huge amounts of development time,
but leaky ones cost just as much in learning time.
a university for the worldrealR
12WW LLLYYY AA
YYYYY
© 2009, www.yawlfoundation.org
Why Patterns?
• Patterns express what the key static and dynamic aspects of the domain are.
• Patterns, collectively, express what needs to be modelled.
– Blueprint for a process integration language
a university for the worldrealR
13WW LLLYYY AA
YYYYY
© 2009, www.yawlfoundation.org
Pattern Categories
• Patterns of Coupling– Dimension of Threading, Time, and Space
• Batch Patterns– Multiple message sends/receives, filtering.
• Bi-directional Interactions– Various patterns for receiving feedback – within the interaction.
• Composed Interactions– Patterns achieving state-aware conversations, across many
interactions.
• Event-based Process Patterns– Patterns for handling unsolicited messages in-process
a university for the worldrealR
14WW LLLYYY AA
YYYYY
© 2009, www.yawlfoundation.org
Pattern Categories …
• Transformations– Patterns that transform messages and message data.
• Process Discovery– Patterns that dynamically change during runtime to perform
new actions.
a university for the worldrealR
15WW LLLYYY AA
YYYYY
© 2009, www.yawlfoundation.org
Coupling Pattern: Non-blocking receive
• Occurs when the receiving process is not waiting for the message to arrive.
• Observable as foundation of most asynchronous architectures.
• Enabler for Event-handling.
• e.g. reallocate seats for airline cancellations.
a university for the worldrealR
16WW LLLYYY AA
YYYYY
© 2009, www.yawlfoundation.org
Coupling Pattern: Time Decoupled
• No indication back to sender about success of interaction.
• ‘Fire and forget’ – send message and start doing something else while the interaction is running.
• e.g. Reconciling inter-bank payments overnight.
a university for the worldrealR
17WW LLLYYY AA
YYYYY
© 2009, www.yawlfoundation.org
Composed Interaction: Property-based Conversation
• Modelled by expressing functions over messaging tasks• You only need to model the function logic and identify
the tasks involved.• The process environment does the matching.• When a match is found the message is directed to the
right process instance.
a university for the worldrealR
18WW LLLYYY AA
YYYYY
© 2009, www.yawlfoundation.org
Conclusions
• Patterns have been used in software engineering to express conceptual solutions to re-occurring problems.
• Process Integration Patterns, on the other hand, are requirements patterns.
– They express what process integration needs to b able to do.
• They indicate what is relevant and what is less relevant (Conceptualisation Principle).
• They indicate what a fully expressive PI language should be capable of (100 Percent principle).