1. Common Transport Rafael Schloming

2. Objectives

3. Scaling Engineering Time ● N experts in protocol & language -> 1 protocol expert & N language experts ● Protocol features implemented in 1 place rather than N – flow control, transports, addressing, etc ● Simplified interop ● Support Clients, Brokers, & Others ● Leverage 3 rd party contributions

4. Adoption ● Simple and useful Abstraction ● Broad platform support – Windows, Solaris, Posix, Mobile Devices,... ● Broad environment support – C, C++, Python, Perl, Ruby, Java,.Net, Lua,... ● Embedability ● Narrow & Stable ABI ● Minimal Dependencies

5. Architecture

6. Ubiquitous Block Diagram

7. Message Transport ● Send & Receive high level messages – includes data binding into the host environment ● structured headers ● structured messages (map message) ● Must not constrain the programming model – blocking, non blocking, threaded,... ● Transport, not monolithic client/server – proxies, concentrators, services,...

8. Message Transport ● Symmetric – used producer to broker & broker to consumer ● Point to point – direct vs brokered vs federated is a deploy time decision ● depends on global addressing ● Acknowledgment ● Flow Control

9. Ubiquitous Block Diagram ● Useful high level illustration ● Naive translation into call stack yields undesirable dependencies

10. Core Components ● Arrows depict formal dependencies ● Event Driver serves as Nexus of Dependencies – allows protocol, I/O and app to be decoupled

11. Event Driver ● Feeds protocol engine with events from: – I/O modules – Timers – Application ● Depends on well defined value objects – Message & Data abstractions ● Different threading models might use different drivers

12. Component Detail

13. Protocol Engine ● Interface is subdivided into top and bottom half ● Top half – defined in terms of links and messages – non blocking form of the messaging API ● Bottom half – defined in terms of bytes, frames & ticks

14. Protocol Engine ● Pure state machine – state is strictly characterized by inputs & outputs – allows driver to know when things may have changed ● Protocol implementation doesn't interact with I/O code

15. I/O Module ● Provides Byte/Frame Transport ● Decoupled from protocol entirely ● Easy to define narrow & stable plugin API

16. Module Diagram

17. Multi Protocol ● Public protocol plugin API ● Supports multiple versions of AMQP ● Could support other messaging protocols – XMPP, Stomp, SMTP

18. Multiple I/O Modules ● Decoupling allows – easy 3 rd party contributions – public plugin API

19. C Stack ● Enables Binding – Swig, JNI ● Easily integrated into standard libraries

20. Parallel Java Stack ● Java as a Platform vs Java as an Environment ● Java as a Platform requires pure Java Stack ● Java as a Language can make do with JNI

21. Testing Strategy ● Drive both stack implementations from a single python test suite ● Jython for Java Stack ● Swig for C Stack

22. Build Requirements ● Support bindings for multiple environments ● Support multiple platforms ● Transport and/or Clients available as independent artifacts