Use of message oriented middleware for secure transaction processing.

1. FSCONS 2010
Vjaceslavs Klimovs, Nicolae Paladi
Are you weak
in the middle?
Use of message oriented middleware for
secure transaction processing in
heterogeneous application environment

2. About us
●Vjaceslavs Klimovs
● Software Engineering degree from
Gothenburg University
● Employed by Opera Software
● Various hobby projects
● SCJP, SCJD, SCWCD, ZCE, CCNP
●Nicolae Paladi
● Software Engineering degree from
Gothenburg University
● Current studies at Luleå University
● Intrest in functional languages and
miscellaneous open source projects

3. Overview
● Theory
● Definition
● Motivation
● Classification
● MOM
● Practice
● Standards
● APIs
● What's on the market
● Case study
● Sloth – transaction processing system at
Peer Mobile AB

4. Middleware

5. Middleware is a link between two
or more objects:
● Different parts of the application
● Different local applications
● Different distributed applications
Essentially, middleware is a
software glue.

6. There are several types of middleware:
● Transactional – X/Open XA
● Procedural – XML-RPC...
● Object oriented – CORBA...
● Message oriented – AMQP, Stomp

7. Transactional middleware
Includes:
● Transaction process monitors
● Web application servers
Used for:
● Monitoring transaction while it is passed from
one resource to another
● ACID across multiple resources
Examples:
● TPM: JBoss Enterprise Middleware Suite
● Web application server: WebSphere

8. Procedural middleware
Includes:
● Technologies and standards for remote
procedure calling
Used for:
●(Typically) synchronous remote procedure
invocation
● Hiding complexity from the caller
Examples:
● Java RMI
● .NET Remoting
● XML-RPC

9. Object oriented middleware
Includes:
● Object request brokers
Used for:
● Object oriented, often asynchronous,
local or remote method invocation
● Hiding complexity from the caller
Examples:
● CORBA

10. Message oriented middleware
Includes:
● Message brokers
Used for:
● Store and forward messaging
● Publish/subscribe messaging
Examples:
● RabbitMQ
● ActiveMQ

11. Distinction between middleware types is
blurry.
● CORBA is ultimately used for remote
procedure invocation → Procedural semantics
● RMI requires proxy (stub) object → Object
orientation
● Message broker +
transaction monitor →
Transactional capabilities

12. (Message oriented) middleware key requirements
● Heterogeneity
● Scalability
● Reliability

13. ● Message receiving subsystem – register and
acknowledge
● A message routing system - filter and process
● Message delivery subsystem - deliver
MOM key components

14. Looks familiar, doesn't it?

15. System of that kind was around for a very long
time - e-mail
● Receive – SMTP
● Filter – before after or inside MTA
● Deliver – POP, IMAP
Another example is XMPP – solves
federation problem.

16. The problem, revisited
● High number of requests
● High request variance in both priority and
workload
● Reliability requirements
● Not a lot of money for development
From the perspective of Next Big Thing

18. Transactional, procedural, object oriented
middleware are not suitable for this kind
of work:
● Not scalable enough
● Not reliable enough
● Poor coping with request variance

19. OTOH, it is important to know what is important
Does it really matter for this particular user,
right now, this very second, that their status
update, tweet or whatever highly important
information they have just created reaches
their friends immediately?
But even more important is to know what is not
important.
Also, how many times can you potentially use word “important” on one slide?

20. Probably not

21. There is no need to do everything all at once
From the Next Big Thing perspective, there are
however three types of latency requirements:
● No tolerance for delay (150-200 ms) – typically
the creator of the content
● Small tolerance (8-10 s) – typically direct
connections of the creator of the content
● Ample tolerance (1-2 minutes) – everyone else

22. Queue everything and delight everyone with the
Help of
Message oriented
middleware (MOM)

23. “Great thing about standards is that there
are so many to choose from”
Standards:
● AMQP - binary, draft specification
● STOMP - text based, specification is final
● JMS – not a protocol but an API, many
implementations

24. Plenty of message brokers on the
market:

26. Which message broker do I choose?
It depends.
● Inconclusive performance benchmarks
● Only partially overlapping feature sets
● Varying level of support, both community and
commercial
● Different use case focus

27. Peer Mobile AB business concept
● SMS-based mobile commerce service
● Usable for both online and offline media
● Focuses on identifying and processing
customer data based on mobile phone numbers

28. ● Reliability ---> loosing transactions will mean
loss of customer goodwill
● Latency tolerance ---> the use of SMS
assumes allows tolerance for a latency of up to 2
minutes
● Scalability ---> large number of transactions
during peak times
● Interoperability with up to 6 external services
and an arbirary number of business partners
● Priority variation ---> amount and priority of
external service communication depends on the
type of the transaction

29. At Peer Mobile AB, we choose Apache
ActiveMQ for several reasons:
● Better configuration flexibility
● Excellent community support
● More appropriate focus –
● Relatively low number of
producers/consumers
● High number of messages
● Appropriate reliability guarantees

30. ActiveMQ is packed with features. Key features
are*:
●OpenWire for high performance clients in Java, C, C++, C#
●Stomp support so that clients can be written easily in C,
Ruby, Perl, Python,
●Supports many advanced features such as Message
Groups, Virtual Destinations, Wildcards and Composite
Destinations
●Fully supports JMS 1.1 and J2EE 1.4 with support for
transient, persistent, transactional and XA messaging
●Supports pluggable transport protocols such as in-VM,
TCP, SSL, NIO, UDP, multicast
●Supports very fast persistence using JDBC along with a
high performance journal
●Designed for high performance clustering, client-server,
peer based communication
●Can be used as an in memory JMS provider, ideal for unit
testing JMS
*from ActiveMQ website

31. Types of messages:
● Persistent
● Non persistent

32. Types of message
acknowledgement:
● Auto
● Explicit acknowledgement
● JMS transactions
● XA

33. Meet the Sloth

34. As used in Peer Mobile:
● Simple PHP frontend (talking Stomp to the
broker)
● Geographically distributed ActiveMQ message
brokers
● Clustered JDBC high-performance persistence
● Sloth - geographically distributed transaction
processor

35. Benchmark
●Multiple cheapest Xen instances
●Geographic distribution
●Enqueueing more than 1,5 thousand
transactions per second
Potential:
● Reasonable vertical scalability
● Virtually unlimited horizontal scalability
● Dynamic scaling using cloud
● Potentially open sourcing

36. Thank you for listening!
vklimovs [swirly thing] peermobile.se
nicolae.paladi [swirly thing] peermobile.se