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 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. 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. Probably not 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. Queue everything and delight everyone with the Help of Message oriented middleware (MOM) 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. Plenty of message brokers on the market: 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. 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. 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. 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. 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. Types of messages: Persistent Non persistent 30. Types of message acknowledgement: Auto Explicit acknowledgement JMS transactions XA 31. Meet the Sloth 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. 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. Thank you for listening! vklimovs [swirly thing] peermobile.se nicolae.paladi [swirly thing] peermobile.se