ICT role in 21st century education and its challenges
Are you weak in the middle?
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
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
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
17.
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?
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
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
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