Coupling Abstractions for Communication Middleware

1
Coupling Abstractions for Communication Middleware

• Lachlan Aldred1
• 1 Queensland University of Technology
• BPM Research Group,
• Brisbane, Queensland, 4001
• 2 Eindhoven University of Technology
• Department of Information and Technology
• The Netherlands

Joint work with Marlon Dumas1, Wil van der
Aalst2, and Arthur ter Hofstede1
2
Context

• An Australian Research Council funded project.
• Deals with interoperability issues induced by
  workflow /BPM language heterogeneity.
• Focus is on process integration modelling.
• YAWL - a powerful workflow language
• a best of breed of practical insights (workflow
  patterns) and theoretical insights (Petri nets).
• Inception 2002.
• Sourceforge implementation gt 1500 d/l month.
• Backed by a fortune 500 company in the US and a
  Telco in the UK.

3
The Problem

• Distributed architectures are highly
  heterogeneous, including their requirements for
  coupling.
• Terms such as (a-) synchronous, (non-) blocking,
  and (non-) directed are used to describe
  coupling.
• These are often used with various connotations in
  mind.
• Informal definitions exist, but no overarching
  framework.
• Perhaps the right set of abstractions are
  missing.
• The vendors claim that the problem is solved.
• Their solutions are big sexy and expensive so it
  must be true!
• Researchers agree seem to agree that the problem
  is not solved.
• Solutions are for too conceptually diverse.
• Hence models over distributed systems are not
  portable, conceptually or otherwise.

4
Objectives

• Find a conceptually complete set of abstractions
  for defining the decoupled-ness of applications.
• Establish a formal semantics for each abstraction
  in terms of CPNs.
• Create a notation that represents their semantics
  e.g. based on Message Sequence Charts.
• The classification of middleware according to
  their ability to provide support for each
  abstraction.

5
The 3 Dimensions of decoupling

• Taken from the work of Eugster et.al. Eug 2003
• Synchronisation decoupling receives and sends
  are non blocking.
• Time decoupling - the sender and receiver of a
  message do not need to interact at the same
  moment.
• Space decoupling the sender does not need to
  directly address the recipient.
• Some of these are not well understood, and have
  not been the subject of a formal analysis.

6
Synchronisation decouplingNon-blocking send

• Sender object /application doesnt need to yield
  its thread.
• Middleware client (inside application) uses its
  own thread.
• CPN shows that embedded middleware is time,
  space, synch coupled regardless.
• Fairly uncommon, never seen is RPC paradigms,
  rarely seen in MOM.
• Store-N-Forward, useful over unreliable
  connections.

7
Synchronisation decouplingNon-blocking send
(continued)

• Dotted lines represent application embedded
  middleware.
• Processing and sending can be interleaved.
• Transition initiate.
• begin can fire at same time as process.
• begin finish exist at boundary of system.

8
Synchronisation decouplingNon-blocking receive

• Doesnt need to yield its thread.
• Object/app either polls middleware client (e.g.
  MPI) or client triggers thread creation inside
  application (e.g. JMS).
• Total synch-decoupling implies NB-send
  NB-receive otherwise partial.

9
Synchronisation decouplingNon-blocking receive
(continued)

• Transitions begin finish are shared hence
  systems are transition bounded.
• After transition initiate has fired CPN is
  primed to receive messages.
• System never prevents process from firing.

10
Time decoupling

• The receiver can be down when the sender sends (
  vice versa).
• Relies on half way destination (e.g. message
  server, directory file, DB).
• Petri net analysis reveals that time (de-)coupled
  systems, are (not) transition-bounded.

11
Space decoupling

• The sender need not directly address the
  receiver.
• Address abstraction is a channel - used by sender
  receiver.
• Channel abstraction holds for single message and
  publish subscribe.
• Petri net analysis shows that it does not relate
  to time decoupling.

12
The 3 Dimensions of Decoupling

• Underpin most integration models.
• Now have precise semantics.
• Can be combined.

13
Combining the 3Ds
14
Combining the 3Ds (continued)

• Formal semantics of each dimension are clear,
  concise.
• They do not create any side effects on any other
  dimension.
• Therefore in one directional messaging there are
  (22 x 2 x 2 16) coupling combinations.
• Each combination can be formally defined by
  overlaying the CPNs of each of the 3 dimensions.
• Each one with its own behaviour potential
  usages.

15
Combining the 3Ds - CPN

• e.g. Synch Coupled (total), Time Coupled, Space
  Coupled

16
Combining the 3Ds - CPN

• e.g. Synch Decoupled (total), Time Decoupled,
  Space Decoupled

17
Middleware Comparison Matrix
18
Conclusions

• Time de/coupling ? ? Synchronisation de/coupling.
• ?terms such as a/synchronous are too imprecise
  for distributed modelling.
• The abstractions alleviate the middleware
  muddle.
• Support is fractured.
• Little or no overlap. No configuration supported
  by all platforms.
• Platforms mostly specialize on 1 or 2 coupling
  abstractions.
• None of the surveyed platforms supported more
  than 25 of the 16 abstractions.

19
Further Work

• Seeking to create a language for modelling the
  integration of Business Processes.
• These abstractions will form a layer between
  middleware platforms and the core process
  constructs.
• They allow us to represent strong integration
  models without tight bindings to m/w platforms.
• This will allow integration modellers to change
  and flex with changing business requirements.
• May need to refine notation.
• Would need to do more careful study existing of
  middleware platforms.

20
Questions?