f2f-overview12.ppt
- 1. Cisco Systems Credit Suisse Deutsche Börse Systems Envoy Technologies Goldman Sachs iMatix IONA (a Progress company) JPMorgan Chase Microsoft Novell Rabbit Technologies Red Hat Solace Systems Tervela TWIST WSO2 29West AMQP 1.0 Public Review San Diego, April 2009 By members of the AMQP Working Group Internet Protocol for Business Messaging
- 2. Page 1 www.amqp.org Agenda Time Activity Who Welcome John Orcutt (Director OOI Cyberinfrastructure) 1:15 Introduction to AMQP Motivations and real world use cases AMQP John O'Hara (JPMorgan) User SIG findings Mark Blair (Credit Suisse) Overview of the MOM capability 2:15 Refreshment Break 2:30 AMQP in detail Detail of the peer-to-peer model Rafi Schloming (RedHat) Detail of the organisation-to-organisation model Robert Godfrey (JPMorgan) Security Roadmap Management Roadmap 4:45 Refreshment Break 5:00 Break Out Interactive Sessions Facilitator: Tell us what you think, ask the unaskable! Matthew Arrott 5:30 AMQP in Action Implementers present real customer stories iMatix, Rabbit MQ, Red Hat 6:00 Drinks Reception All
- 3. Page 2 www.amqp.org What’s Happening Today? Launching AMQP1.0 Public Review Present the outcome of 4 years evolution and experience Invite input from the outside world — Refine & Correct, but not Redefine — Check that we are not wearing the Emperor’s New Clothes AMQP 1.0 will only be advanced to Final when there are multiple implementations of the Committee Draft that play nicely together Academic Setting NOT a commercial dog and pony show (mostly!) We come to the public with humility seeking input and validation A Short Time to cover a Lot Ask questions as we go along, bit issues may be parked Feedback session to capture feedback at 5pm Working Group Members should save issues for the private sessions
- 4. Page 3 www.amqp.org AMQP Motivation
- 5. Page 4 www.amqp.org AMQP was born of frustration MOM needs to be everywhere to be useful dominant solutions are proprietary too expensive for everyday use (Cloud-scale) they don’t interoperate has resulted in lots of ad-hoc home-brew how hard can middleware be? Middleware Hell 100’s of applications 10,000’s of links every connection different massive waste of effort The Internet’s missing standard Why has no one done this before?
- 6. Page 5 www.amqp.org The AMQP Working Group Set up by JPMorgan in 2006 Goal to make Message Oriented Middleware pervasive Make it practical, useful, interoperable Bring together users and vendors to solve the problem We say AMQP is an “Internet Protocol for Business Messaging” so end users feel a connection to the technology. AMQP aspires to define MOM
- 7. Page 6 www.amqp.org AMQP Vision AMQP “Message Bus” Enterprise Branch Offices AMQP Aware Infrastructure Business Partners treasury@fundmanager.com orders@supplier.com AMQP Global Addressing Internet AMQP Aware Clients Devices & workstations AMQP Aware Services C/C++, Java JMS, Microsoft WCF and Business Applications
- 8. Page 7 www.amqp.org Ubiquitous => Unencumbered AMQP Intellectual Property Policy Unambiguous Right to Implement The Authors each hereby grants to you a worldwide, perpetual, royalty- free, non-transferable, nonexclusive license to (i) copy, display, distribute and implement the Advanced Messaging Queue Protocol ("AMQP") Specification and (ii) the Licensed Claims that are held by the Authors, all for the purpose of implementing the Advanced Messaging Queue Protocol Specification. "Licensed Claims" means those claims of a patent or patent application, throughout the world, excluding design patents and design registrations, owned or controlled, or that can be sublicensed without fee and in compliance with the requirements of this Agreement, by an Author or its affiliates now or at any future time and which would necessarily be infringed by implementation of the Advanced Messaging Queue Protocol Specification. The License is attached to the AMQP Specification itself You get the rights when you download it!
- 9. Page 8 www.amqp.org AMQP Working Group – Strong Governance Credit-Suisse, JPMorgan, Deutsche Borse Systems, Goldman Sachs, TWIST, 29West, Envoy, Novell, Tervela, WSO2,.. iMatix Apache Red Hat iMatix OpenAMQ Cisco Protocol Products Red Hat MRG Cisco AON AMQP Working Group controls the standard Diverse products implement the standard Community Feedback Rabbit Rabbit MQ Apache Qpid End Users
- 10. Page 9 www.amqp.org AMQP Requirements
- 11. Page 10 www.amqp.org Agreed User Requirements (User SIG) UBIQUITOUS AND PERVASIVE Open internet protocol standard Binary WIRE protocol so that it can be ubiquitous, fast, embedded Unambiguous core functionality for business message routing and delivery within Internet infrastructure Scalable, so that it can be a basis for high performance fault-tolerant lossless messaging infrastructure, i.e without requiring other messaging technology Fits into existing enterprise messaging applications environments in a practical way
- 12. Page 11 www.amqp.org Agreed User Requirements UBIQUITOUS AND PERVASIVE SAFETY Infrastructure for a secure and trusted global transaction network — Consisting of business messages that are tamper proof — Supporting message durability independent of receivers being connected Transport business transactions of any financial value Sender and Receiver are mutually agreed upon counter parties — No possibility for injection of Spam
- 13. Page 12 www.amqp.org Agreed User Requirements UBIQUITOUS AND PERVASIVE SAFETY FIDELITY Well-stated message queuing and delivery semantics covering — at-most-once — at-least-once — and once-and-only-once (e.g. 'reliable’, ‘assured’, ‘guaranteed’) Well-stated message ordering semantics describing what a sender can expect — a receiver to observe — a queue manager to observe Well-stated reliable failure semantics — so exceptions can be managed
- 14. Page 13 www.amqp.org Agreed User Requirements UBIQUITOUS AND PERVASIVE SAFETY FIDELITY UNIFIED AMQP aspires to be the sole business messaging tool for organizations Global addressing standardizing end-to-end delivery across any network scope Any AMQP client can initiate communication with, and then communicate with, any AMQP broker over TCP/IP Optionally, extendable to alternate transports via negotiation Provide a core set of messaging patterns via a single manageable protocol: — asynchronous directed messaging — request/reply, publish/subscribe — store-and-forward Provide for Hub-and-Spoke messaging topology within and across business boundaries Provide for Hub-to-Hub message relay across business boundaries through enactment of explicit agreements between broker authorities
- 15. Page 14 www.amqp.org Agreed User Requirements UBIQUITOUS AND PERVASIVE SAFETY FIDELITY UNIFIED INTEROPERABILITY Multiple stable and interoperating broker implementations — Each with a completely independent provenance (min. 2 to move to Final) — Each broker implementation is conformant with the specification, for all mandatory functionality, including fidelity semantics Stable core (client-broker) wire protocol so that brokers do not require upgrade during 1.x feature evolution: Any 1.x client will work with any 1.y broker if y >= x Stable extended (broker-broker) wire protocol so that brokers do not require upgrade during 1.x feature evolution: Any two brokers versions 1.x, 1.y can communicate using protocol 1.x if x<y Layered architecture, so features & network transports can be independently extended by separated communities of use
- 16. Page 15 www.amqp.org Agreed User Requirements UBIQUITOUS AND PERVASIVE SAFETY FIDELITY UNIFIED INTEROPERABILITY MANAGEABLE Decentralized deployment with independent local governance Intermediated: supports routing and relay management, traffic flow management and quality of service management Interaction with the message delivery system is possible, sufficient to integrate with prevailing business operations that administer messaging systems using management standards.
- 17. Page 16 www.amqp.org Banking Security Requirements SSL support Service Context (incl. Security Context): A standard Message property for for propagation of Security Tokens Support for carrying Security Tokens: Principal-ID, SAML, Kerberos ticket, etc. Carried within the Service Context in the Message Unique Security Token per Message: Enables multiplexing of different Security Contexts on a given messaging session (e.g. for proxying) Hash and sign of Message (including Security Context) Assure authenticity of the contents in addition to encryption (content verified by final-destination). Full-path privacy for business transactions that might pass through a number of hubs enroute to the final destination, where you would not want to have the exposed content of the message sitting in some queue and disk along the way. Chains of trust within trust realms - optional
- 18. Page 17 www.amqp.org AMQP 1.0 Functionality
- 19. Page 18 www.amqp.org AMQP 1.0 Scope AMQP is Message Oriented Middleware (MOM) Transfers application data units from senders to receivers – layer 7 An expectation that the message transfer is via trusted intermediaries An expectation that messages will be delivered unchanged An expectation of security Applications can be separated by (large amounts) of space and time Abstract from the underlying technology Physical network limits should be hidden (message size, node location) Technology concerns should be hidden (platform, language, OS) The intermediaries offer various delivery options, as defined by either the sender or the receiver (s) The intermediaries provided various defined qualities of service for the sender and the receiver (s) Provide stability and backwards compatibility (10yrs+)
- 20. Page 19 www.amqp.org AMQP 1.0 Covers… Queuing with strong Delivery Assurances Event distribution with Flexible Routing Large Message capability (gigabytes) Global Addressing Scheme (email-like) Meet common requirements of mission-critical systems Implications Candidate for a common information infrastructure A foundation for other protocols and products E.g. In finance alone: FIX 5, FpML, ISO20022 File Transfer report Messaging transact Publish/ Subscribe detect
- 21. Page 20 www.amqp.org AMQP 1.0 is an Overlay Network Broker Applications Connect to a Broker to participate in the AMQP network The Connection is used to establish a Session Sessions provide state between Connections, establish identity, ease failover Connections are further subdivide into Channels Multiple threads of control within an Application can share one Connection Queues Applications logic interacts ONLY with Queues Queues have well known Names == Addressable Applications do not need to know how messages get in/out of Queues Queues can be smart, they are an extension point Applications will assign implied semantics to Queues (e.g. “StockOrderQueue”) Links Links move Messages between Queues and/or Applications Contain Routing and Predicate Evaluation Logic – similar to Complex Event Processing
- 22. Page 21 www.amqp.org AMQP 1.0 Model Entities The following entities are discoverable in any full AMQP 1.0 implementation: There will be many more entitles in an implementation which a portable application must not depend on! Link Message Queue Predicate source target evaluate Message enqueue Zero or More Zero or One Exactly One Legend: move or copy messages Queue Entry contains
- 23. Page 22 www.amqp.org What Happened to Exchanges? Exchange provided the core routing concept previously Upon reflection, exchanges were redundant Global Addressing drove the change Need one abstract name to route, need to hide implementation details Exchanges/Exchange Instance/Exchange type were “leaky abstractions” Exchange == Queue -> Links -> Queues Input Queue provide an abstract Address Links contain a Function to evaluate Messages Function parameterised by the Link predicates Output Queue = Link( message, predicates) New approach is more abstract and more flexible Moves complexity from Clients to Brokers — Simpler to implement and use — Lots of opportunity to differentiate
- 24. Page 23 www.amqp.org Inter-Network Connectivity Internet Client Broker Broker Broker Client Client Client Client Client Client Client Client Firewalls
- 25. Page 24 www.amqp.org Inter-Company Firewalls
- 26. Page 25 www.amqp.org AMQP 1.0 Data Flow Overview (read) 1 6 Work Queue “appWork” <tail> Link Queue->Queue Address Queue “publicName” Sending Client Receiving Client Logical store-and-forward transmission path Link Queue->Session Message AMQP Broker Session Session Transport Transfer Agent Admin Agent Model Transport to other Brokers Transport 6 <tail> Transmission Queue(s)
- 27. Page 26 www.amqp.org Traditional Topologies Built from Parts Queues are used both for Persistent stores and transient buffers. Link model unifies point-to-point and publish/subscribe Finance example shows client messages being routed to various Queues Example mixes traditional Store & Forward and Transient Pub/Sub Queue1 link/transfer Client A Session Client B Session Queue: “StockTicker” Queue: “US-Payments” Queue: “ServiceBus” Subject REGEXP “stocks.ny.*” PREDICATE Subject REGEXP “stocks.uk.*” Subject REGEXP “stocks.tk.*” BusEvt=“Pay” and Ccy!=“USD” BusEvt = “Unwind” usaQ Queue1 worldQ Queue1 usPayQ link/transfer link/transfer link/transfer BusEvt=“Pay” and Ccy=“USD” Queue1 wrldPayQ Queue1 unwindQ Well-Known Queue In-Broker Links Work Queue Session StockTicker worldQ StockTicker StockTicker SOURCE TARGET worldQ usaQ Subject REGEXP “stocks.ny.*” PREDICATE StockTicker SOURCE TARGET usaQ StockTicker StockTicker StockTicker PREDICATE SOURCE TARGET unwindQ worldPayQ usPayQ
- 28. Page 27 www.amqp.org Global Addressing Queues have abstract names, but when routing between organisations a convention is required. AMQP follows many RFC822 email convention for Queue names Queue_Name @ example.org Domain names are only required for relaying to remote Brokers The Address is opaque to the sending Client, but behind that Address, the owner of the Broker creates Links (either administratively or dynamically) to deliver Messages sent to that Address to one or more Message Queues on the same or different Brokers. Broker is autonomous; no privileged access is required on a remote Broker to deliver messages. The targets topology must be hidden except for the Queue name and authentication credentials. In later versions of AMQP we will standardise subscription propagation between entities
- 29. Page 28 www.amqp.org Management Standardising AMQP Management and Administration too Management is a MOM application! Therefore commands can be secured and routed at the MOM level Seen control Messages to a well known service Queue Responses come back to private response Queues Questions as to whether management is fully transacted/async Decided to do like most RDBMS’s Management commands are not transacted When you get the response, you know it has taken effect Features Queue management, queue depth/alerts, top talkers, slow consumers, kill clients, etc. Vendors free to implement Bridges to additional management standards Additional features beyond the core
- 30. Page 29 www.amqp.org AMQP1.0 Typical Usage Patterns
- 31. Page 30 www.amqp.org Client Producer AMQP Broker Client Consumer Entry 1 Entry 2 Entry 3 Session Link Session Link Queue (source) -Persistent Head Tail Highlights: • Only “Source” queue is required and can be read directly by consumer over Link (i.e. dedicated consumer Worker queue and bridging between Source and Worker unnecessary). Point-to-point Queue Delivery
- 32. Page 31 www.amqp.org Client Producer AMQP Broker Entry 1 Entry 2 Entry 3 Session Link Queue (Source) -Persistent Head Tail Entry 1 Entry 2 Head Link Tail Queue (worker) -Persistent Abstracted Point-to-point Queue Highlights: • One Queue performs the role of holding the “Well Known” name for the outside world. • All messages are automatically forward on to the real worker queue. • Allows internal topology to change without the outside world seeing (this PO Box)
- 33. Page 32 www.amqp.org Client Producer AMQP Broker Client Consumer Entry 1 Entry 2 Entry 3 Session Link Session Link Queue (source) -Persistent 1 Head or 2 ? Tail Client Consumer Session Link Load-Balanced Point-to-point Queue Delivery
- 34. Page 33 www.amqp.org Client Publisher AMQP Broker Client Subscriber Entry 1 Entry 2 Entry 3 Session Link Session Link Queue (Source) -Non-persistent Head Tail Client Subscriber Session Link Client Subscriber Session Link Head Head Dynamic (non-persistent) Pub/Sub Delivery Highlights: • Messages are “garbage collected” in an implementation specific manner after delivery. • AMQP makes some guarantees about how long messages are valid for.
- 35. Page 34 www.amqp.org Client Publisher AMQP Broker Entry 1 Entry 2 Entry 3 Session Link Queue (Source) - persistent Head Tail Client Subscriber Session Link Client Subscriber Session Link Head Entry 1 Entry 2 Head Head Entry 1 Tail Queue (Worker) - persistent Queue (Worker) - persistent Durable (persistent) Pub/Sub Delivery
- 36. Page 35 www.amqp.org Technical Details Follow… Robert Godfrey – JPMorgan Rafi Schloming – Red Hat
Editor's Notes
- #6: You are accepting something in your network you wouldn’t accept anywhere else. You maybe can’t even see the wood for the trees. Why is there no RJ45 for communication between business systems? Imagine If: your laptop could only connect to a same brand network your email client could only send email to people with the same email client your JMS could only send messages to the same vendors JMS ?!?? Those are problems you expect not to put up with. FIX for everything else.
- #10: Parallels to FIX, FPML We’re fixing the bit we forgot first time round.