This document discusses how messaging can be used for more than just investment banks. It provides examples of how messaging can improve application integration and decouple processes for better performance, scalability, and resilience compared to traditional HTTP integration. Specific benefits highlighted include better isolation, asynchronous processing, guaranteed delivery, and improved testability. Case studies demonstrate how messaging can solve problems with email delivery after registration and credit card processing. Common messaging tools and situations where messaging is applicable are also outlined.

1. Messaging is not just for
investment banks!
(+ web is not the only way)
Gojko Adzic
http://gojko.net
gojko@gojko.com
twitter.com/gojkoadzic

2. Web is now ubiquitous
... we use it to display content, to share data, for
remote procedure calls, to integrate systems...

3. It started like this...

4. And simply exploded...

5. But why this???

6. HTTP distribution/integration

Easy to use

Cross-platform

Clustering and load balancing

Almost never blocked by firewalls

Even then works with proxying

Stateless

Synchronous

Unreliable/Non transactional

High latency

7. Web technologies are not for
everything...
... sometimes other stuff can save a lot of effort
http://www.flickr.com/photos/33453508@N02/

8. HTTP distribution/integration

Easy to use

Cross-platform

Clustering and load balancing

Almost never a security problem

Even then works with proxying

Stateless

Synchronous

Unreliable/Non transactional

High Latency

9. Messaging

Application integration pattern

Data transformation, routing, resilience, high
performance, high throughput

Message oriented middleware(MOM)

10. http://www.flickr.com/photos/wirenine/

11. http://www.flickr.com/photos/17675967@N02/

13. http://www.flickr.com/photos/stewf/

14. Messaging

Application integration pattern

Data transformation, routing, resilience, high
performance, high throughput

Message oriented middleware(MOM)

Event driven processing

Split workflows into several asynchronous parts

Share data instead of functionallity
− But use data to invoke actions!

15. Not just for multi-billion enterprises

Some really
lightweight solutions
out there

Can even run
everything on a
single machine

Typical web sites
can benefit from
this approach as
well

16. Benefits

Better isolation
− Easier scaling
− Better performance

Resilience

Responsiveness

Better resource usage

17. Case Study #1: E-mail after
registration/order

18. Case Study #1: E-mail after
registration/order

19. Case Study #1: E-mail after
registration/order

20. Case Study #1: E-mail after
registration/order

21. Problems

DNS/Networking issues

SMTP rules (external verification, spam filters)

How do we test this?

How do we guarantee that the message gets
through?
− What if it doesn't

What if the DB rolls back?

22. An alternative approach

23. An alternative approach

24. An alternative approach

25. An alternative approach

26. An alternative approach

27. Why is this better?

External system problems don't affect user
registration

SMTP rules don't slow it down

If e-mail sending fails, we can easily re-send
later

28. Key Difference:
The first part of the process succeeds
without waiting for the second
- but the second is guaranteed to
happen

29. Transactional guarantee

30. How do we test this?

Mock queue/In memory implementation

Process registration and look at the queue
contents

Easily unit testable

Focuses the test on what is really important

31. Publish/Subscribe (Fire & Forget)
http://www.sxc.hu/photo/1084274

32. Publish/Subscribe (Fire & Forget)

When you need to talk to external systems but
don't really need to wait for them to finish

Batch/overnight processing

Decouple processes so that they can be
performed asynchronously

Effectively observer over messaging

Option to have multiple subscribers (observers)

33. Case study #2: Credit card
processing

34. Case study #2: Credit card
processing

35. Case study #2: Credit card
processing

36. Case study #2: Credit card
processing

37. What could possibly go wrong?

User closes the window mid-way

User clicks on refresh

Web call times out

CC channels too busy/RPC times out

Order processing fails after authorisation

38. On top of that, we're wasting web/db
resources!

39. Alternative solution

40. Alternative solution

41. Alternative solution

42. Alternative solution

43. Alternative solution

44. Alternative solution

45. Alternative solution

46. Alternative solution

47. Alternative solution

48. Alternative solution

49. What's improved?

Closing the window makes no difference

Refresh makes no difference

Web call will not time out

We can wait for CC channels

Web and DB resources used much better

50. Some ways to improve this...

Enqueue operation result, authorise order
asynchronously (increase resilience)

Scale to more servers

Process cards using dedicated servers (VLAN)

Avoid polling, send a message to the client

51. Some other situations where
messaging might come in handy

Distributing work across multiple machines

Performing a number of actions when
something happens (eg notify admin, notify
customer)

Pushing frequent updates to clients

52. Tools

ActiveMQ: http://activemq.apache.org/

NServiceBus: http://www.nservicebus.com/

AMQP: http://amqp.org

53. Bridging the Communication Gap

learn how to improve communication
between business people and software
implementation teams

find out how to build a shared and
consistent understanding of the domain
in your team

learn how to apply agile acceptance
testing to produce software genuinely fit
for purpose

discover how agile acceptance testing
affects your work whether you are a
programmer, business analyst or a
tester

learn how to build in quality into software
projects from the start, rather than
control it later
http://www.acceptancetesting.info