Are you weak in the middle?

1,720 views

Published on

Use of message oriented middleware for secure transaction processing.

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
1,720
On SlideShare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
19
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Are you weak in the middle?

  1. 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. 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. 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. 4. Middleware
  5. 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. 6. There are several types of middleware: ● Transactional – X/Open XA ● Procedural – XML-RPC... ● Object oriented – CORBA... ● Message oriented – AMQP, Stomp
  7. 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. 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. 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. 10. Message oriented middleware Includes: ● Message brokers Used for: ● Store and forward messaging ● Publish/subscribe messaging Examples: ● RabbitMQ ● ActiveMQ
  11. 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. 12. (Message oriented) middleware key requirements ● Heterogeneity ● Scalability ● Reliability
  13. 13. ● Message receiving subsystem – register and acknowledge ● A message routing system - filter and process ● Message delivery subsystem - deliver MOM key components
  14. 14. Looks familiar, doesn't it?
  15. 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. 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. 17. Transactional, procedural, object oriented middleware are not suitable for this kind of work: ● Not scalable enough ● Not reliable enough ● Poor coping with request variance
  18. 18. 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?
  19. 19. Probably not
  20. 20. 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
  21. 21. Queue everything and delight everyone with the Help of Message oriented middleware (MOM)
  22. 22. “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
  23. 23. Plenty of message brokers on the market:
  24. 24. 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
  25. 25. 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
  26. 26. ● 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
  27. 27. 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
  28. 28. 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
  29. 29. Types of messages: ● Persistent ● Non persistent
  30. 30. Types of message acknowledgement: ● Auto ● Explicit acknowledgement ● JMS transactions ● XA
  31. 31. Meet the Sloth
  32. 32. 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
  33. 33. 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
  34. 34. Thank you for listening! vklimovs [swirly thing] peermobile.se nicolae.paladi [swirly thing] peermobile.se

×