1. Last Updated: Jan. 2014
Director
–
Solu-ons
Architecture
Manoj
Fernando
SOA
Pa/erns
Webinar
Series
Reliable
Messaging
/Guaranteed
delivery
2. 2
About
WSO2
๏ Global
enterprise,
founded
in
2005
by
acknowledged
leaders
in
XML,
web
services
technologies,
standards
and
open
source
๏ Provides
only
open
source
plaIorm-‐as-‐a-‐service
for
private,
public
and
hybrid
cloud
deployments
๏ All
WSO2
products
are
100%
open
source
and
released
under
the
Apache
License
Version
2.0.
๏ Is
an
AcQve
Member
of
OASIS,
Cloud
Security
Alliance,
OSGi
Alliance,
AMQP
Working
Group,
OpenID
FoundaQon
and
W3C.
๏ Driven
by
InnovaQon
๏ Launched
first
open
source
API
Management
soluQon
in
2012
๏ Launched
App
Factory
in
2Q
2013
๏ Launched
Enterprise
Store
and
first
open
source
Mobile
soluQon
in
4Q
2013
5. 5
About
the
Presenter
Manoj
Fernando
(Director
-‐
SoluQons
Architecture
@
WSO2)
Email
:
manojf@wso2.com
Blog
:
h/p://manoj-‐fernando.blogspot.com/
6. 6
Problem
Service
communicaQon
cannot
be
guaranteed
when
using
unreliable
messaging
protocols
or
when
dependent
on
an
otherwise
unreliable
environment.
Source
:
h/p://soapa/erns.org/
7. 7
Need
for
reliability
§ Guaranteed
message
delivery
is
a
guaranteed
requirement
in
Distributed
and
Service
Oriented
Architectures.
§ ApplicaQons
usually
depend
on
middleware
+
infrastructure
for
making
sure
that
messages
are
delivered…
§ Just
Once
(Avoiding
duplicaQons)
§ Accurately
(In
full
and
uncorrupted)
§ On
Qme
(In
order
and
as
soon
as
possible)
§ Resilience
over
transport
and
system
failures.
8. 8
EvoluQon
§ Various
a/empts
to
handle
reliability
using
addiQonal
message
exchanges.
§ WS-‐RM
specificaQon
aimed
at
delivering
messages
Exactly
Once
and
In
Order
which
was
the
primary
moQve.
§ SpecificaQon
also
aimed
at
keeping
Composability
intact
with
other
specificaQons
and
standards
(i.e.
WS-‐RM s
dependency
on
WS-‐Addressing).
§ WS-‐Reliability
-‐
an
alternaQve
specificaQon
(implementaQon
:
RM4GS)
submi/ed
and
standardized
in
parallel
to
WS-‐RM.
10. 10
So…where
does
WS-‐RM
currently
stand?
§ Various
vendors
have
adapted
the
standard
and
have
come
up
with
their
different
implementaQons.
§ SQll
in
use,
but
not
as
much
as
it
should
have
been.
§ Dependency
on
addiQonal
service
and
client
level
configuraQons
were
probably
a
key
reason
behind
its
less
adaptability.
§ Some
of
these
drawbacks
have
led
for
applicaQon
designers
to
look
for
alternaQve
means
to
achieve
reliable
delivery.
11. 11
Key
CharacterisQcs
of
Reliability
IrrespecQve
of
the
specificaQon,
standard
or
implementaQon…
the
objecQves
are
clear!
§ Resilience
and
Delivery
Assurance
(Transport/Component)
§ Must
be
transparent
to
sender
and
ulQmate
receiver
§ AutomaQc
retying
over
failure
a/empts.
§ IdenQficaQon
and
Sequencing
(Avoid
duplicaQons)
§ Order
needs
to
be
maintained.
§ Acknowledged
and
noQfied.
12. 12
SoluQon
An
intermediate
reliability
mechanism
is
introduced
into
the
inventory
architecture,
ensuring
that
message
delivery
is
guaranteed.
Source
:
h/p://soapa/erns.org/
13. 13
Service
Pa/ern
§ Service
consumers
depends
on
an
intermediate
reliability
mechanism
to
reliably
deliver
the
messages
to
the
backend
service.
intermediate reliability
mechanism
Service Consumer
Backend Service
(A)
(A)
(ACK)
(ACK)
(B)
(A) – Message Delivery flow
(B) – Persistence Repo
Message
send and
retry
14. 14
Sample
Scenario
An
account
holder
makes
a
credit
card
repayment
at
an
ATM,
and
the
transacQon
must
update
the
account
balance
upon
confirmaQon.
Transaction
Creation
Transaction
Dispatch
Card Repayment
Workflow
Transaction
Processor
RM Source
RM Destination
Transmit
Acknowledge
Accept
Accept
Send
Deliver
Application
Source
Application
Destination
15. 15
CriQcal
Success
Factors
for
this
model
to
work
§ RM
Source
must
persist
the
message
immediately
aner
accepQng
§ RM
Source
has
to
asynchronously
deliver
the
message
not
leong
the
applicaQon
source
to
wait.
§ Message
has
to
be
delivered
iteraQvely
(with
configurable
wait
Qmes,
and
number
of
retries)
and
the
delivery
process
should
only
end
aner
the
acknowledgement
is
received
back
from
RM
desQnaQon.
§ The
ApplicaQon
source
needs
to
be
noQfied
(opQonal)
RM Source
RM Destination
Transmit
Acknowledge
Accept
Accept
Send
Deliver
16. 16
ImplemenQng
RM
using
WSO2
plaIorm
Service Consumer
Service
(ACK)
(ACK)
(B)
Message send /
retry
Message
Store
(REQ)
(REQ)
Message
Processor
Queue
17. 17
Use
Case
:
Scenario
A
§ The
client
sends
requests
to
a
proxy
service.
§ The
proxy
service
immediately
stores
the
messages
to
a
JMS
message
store.
§ The
back-‐end
service
is
invoked
by
a
message
forwarding
processor,
which
picks
stored
messages
in
the
JMS
message
store.
§ Message
is
removed
from
the
store
upon
acknowledgement
by
the
backend
service.
Proxy
Message
Store
Message
Forwarding
Processor
Backend
Service
Reliable In
Only
Invocation
18. 18
Use
Case
:
Scenario
B
§ Extension
to
Scenario
A
§
Service
invocaQon
places
the
response
on
to
a
reply
sequence.
§ Can
use
a
callback
URL
to
noQfy
the
ApplicaQon
source.
Proxy
Message
Store
Message
Forwarding
Processor
Backend
Service
Reliable
Invocation
Reply Sequence
Callback URL
to Notify
19. 19
What
makes
a
Message
Broker
a
good
candidate?
§ Message
Autonomy
Messages
are
self-‐contained
autonomous
entries
and
can
be
sent
and
re-‐sent
many
Qmes
across
its
lifecycle.
§ Store
and
Forward
nature
Once
marked
as
persisted,
it
is
the
responsibility
of
the
JMS
provider
to
deliver
to
the
desQnaQon.
§ Message
Acknowledgements
Message
Acknowledgement
is
an
in-‐built
feature
of
JMS.
22. 22
TesQng
the
sample
scenario
JAX-WS
Service
Service Consumer
Service
(ACK)
(B)
Message send /
retry
Message
Store
(REQ)
(REQ)
Message
Processor
Queue
