Cloud Message Queues AMQP Advanced Message Queuing Protocol

Cloud Message Queues

AMQP — Advanced Message Queuing Protocol, an application layer protocol for message-oriented middleware. 1 1

1 The 'Advanced Message Queuing Protocol' ('AMQP') is an open standard application layer protocol for message-oriented middleware. The defining features of AMQP are message orientation, queuing, routing (including point-topoint and Publish/subscribe|publish-and-subscribe), reliability and security. 1 1 Unlike JMS, which merely defines an API, AMQP is a Wire protocol|wire-level protocol

AMQP Motivation Page www. amqp. org

AMQP was born of frustration MOM needs to be everywhere to be useful n dominant solutions are proprietary n too expensive for everyday use (Cloud-scale) n they don’t interoperate n has resulted in lots of ad-hoc home-brew n how hard can middleware be? Middleware Hell n 100’s of applications n 10, 000’s of links n every connection different n massive waste of effort The Internet’s missing standard n Page Why has no one done this before? www. amqp. org

The AMQP Working Group Set up by JPMorgan in 2006 n Goal to make Message Oriented Middleware pervasive n Make it practical, useful, interoperable n 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. n AMQP aspires to define MOM Page Cisco Systems Credit Suisse Deutsche Börse Systems Envoy Technologies Goldman Sachs i. Matix IONA (a Progress company) JPMorgan Chase Microsoft Novell Rabbit Technologies Red Hat Solace Systems Tervela TWIST WSO 2 29 West www. amqp. org

Ubiquitous => Unencumbered AMQP Intellectual Property Policy n Unambiguous Right to Implement n The Authors each hereby grants to you a worldwide, perpetual, royaltyfree, 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. n "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. n The License is attached to the AMQP Specification itself n You get the rights when you download it! Page www. amqp. org

AMQP Functionality Page www. amqp. org

AMQP 1. 0 Covers… Publish/ Subscribe n Queuing with strong Delivery Assurances n Event distribution with Flexible Routing n Large Message capability (gigabytes) n Global Addressing Scheme (email-like) detect Messaging n Meet common requirements of mission-critical systems transact File Transfer report Page www. amqp. org

The AMQP Network An AMQP Network consists of Nodes and Links. A Node is a named source and/or sink of Messages travel between Nodes along named, unidirectional Links. Link Source Node Page Target Node www. amqp. org

Types of Links Destructive: the transfer along the link removes the message from the source Non- Destructive: the message remains at the source node, and is “copied” to the destination. A B C Page www. amqp. org

Messages consist of parseable Properties and an opaque Body. Messages may not be mutated by the AMQP Network. The network carries information about the Message in Headers and Footers. Header and Footer values may be modified in the Network. Page www. amqp. org

Message Identity A Message is assigned a globally unique identifier. Nodes which perform transformations are creating new Messages, with new ids. Only one “copy” of a Message can ever exist at a Node. Page www. amqp. org

Filters Each Link may have a Filter which evaluates which messages may travel along it. Filters are evaluated against immutable properties of the Message. Filter syntax determined by the Filter Type, e. g. SQL, XQuery color = 'red' color = 'yellow' Page www. amqp. org

AMQP is an Overlay Network Broker n Applications Connect to a Broker to participate in the AMQP network n The Connection is used to establish a Session n Sessions provide state between Connections, establish identity, ease failover n Connections are further subdivide into Channels n Multiple threads of control within an Application can share one Connection Queues n Applications logic interacts ONLY with Queues n Queues have well known Names == Addressable n Applications do not need to know how messages get in/out of Queues n Queues can be smart, they are an extension point n Applications will assign implied semantics to Queues (e. g. “Stock. Order. Queue”) Links Page n Links move Messages between Queues and/or Applications n Contain Routing and Predicate Evaluation Logic – similar to Complex Event Processing www. amqp. org

Inter-Network Connectivity Page www. amqp. org

Some Typical Usage Patterns Page www. amqp. org

Point-to-point Queue Delivery AMQP Broker Client Producer Link Session Tail Entry 3 Entry 2 Entry 1 Queue (source) -Persistent Head Link Session Client Consumer Highlights: 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). Page www. amqp. org

Abstracted Point-to-point Queue AMQP Broker Client Producer Link Session Tail Entry 3 Entry 2 Entry 1 Queue (Source) -Persistent Link Head Entry 2 Entry 1 Head Queue (worker) -Persistent Highlights: 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) Page www. amqp. org

Load-Balanced Point-to-point Queue Delivery AMQP Broker Client Producer Link Session Tail Link Entry 3 Entry 2 Entry 1 Queue (source) -Persistent Head Session Head Link Session Page Client Consumer www. amqp. org

Dynamic (non-persistent) Pub/Sub Delivery AMQP Broker Link Session Client Publisher Link Session Tail Entry 3 Head Entry 2 Entry 1 Head Queue (Source) -Non-persistent Link Session Page Highlights: Highlights • Messages are “garbage collected” in an implementation specific manner after delivery. • AMQP makes some guarantees about how long messages are valid for. Client Subscriber www. amqp. org

Durable (persistent) Pub/Sub Delivery AMQP Broker Link Tail Client Publisher Link Session Tail Link Entry 3 Entry 2 Entry 1 Queue (Source) - persistent Entry 2 Entry 1 Session Client Subscriber Queue (Worker) - persistent Head Link Entry 1 Queue (Worker) - persistent Page Head Link Session Client Subscriber www. amqp. org

Sample Message Queues (a partial list…)

q Rabbit. MQ The most popular due to multiple operating system support (even Windows!) and a plethora of clients and tools that support Rabbit. MQ. • Rabbit. MQ is written in Erlang and implements a common standard: the Advanced Message Queuing Protocol (AMQP). • Rabbit. MQ queues messages on a central server, making it easy to deploy but a bit more interesting to scale. •

q Active. MQ Apache Active. MQ is a message broker written in Java together with a full Java Message Service (JMS) client. • Designed to communicate over a number of protocols such as AMQP, STOMP (a the Simple Text Orientated Messaging Protocol. ) and Open. Wire (native binary wire formant of Active. MQ) together with supporting a number of different language specific clients. •

q Zero. MQ • • • Typically deployed for clustered systems and/or supercomputing. It is a sockets library for messaging and is extremely fast. It gives you sockets that carry atomic messages across various transports like in-process, inter-process, TCP, and multicast. You can connect sockets N-to-N with patterns like fanout, pub-sub, task distribution, and request-reply. Zero. MQ does not follow a broker pattern like Rabbit. MQ or Active. MQ, meaning Zero. MQ does not run on a single server or cluster of servers (P 2 P) A wealth of information about Zero. MQ is available in “Code Connected Volume 1 - Professional Edition” by Pieter Hinjens, the CEO of i. Matrix.

q Zaqar (ex Marconi) Marconi is a new Open. Stack project to create a multi-tenant cloud queuing service. • The aim is to create an open alternative to Amazon’s SQS (producer-consumer) and SNS (pub-sub) services, for use in applications that run on Open. Stack clouds. • Marconi is currently in development. •

q Iron. MQ (“The Message Queue For the Modern Cloud“) • • • An easy-to-use highly available message queuing service. Iron. MQ is for the person that doesn’t want to manage their own queue servers. They provide an endpoint where you create queues and messages with a highly available backend. Iron. MQ uses HTTPS to transport messages instead of AMQP. Create a Queue, Post, Receive messages from your application to your named queue all via REST-based with JSON bodies and use OAuth 2 for authentication. http: //www. iron. io/mq

q Many more… Kafka – I recommend reading about it ! • Amazon Simple Queue Service (SQS) • Microsoft Azure Queues / Service. Bus -- next week ? (Pavel) • … •

Device Notification Via Message Queues

Accessing Data in Cloud r A typical design pattern is that a device updates/receives data in the cloud m Cloud as a rendezvous point r Challenge: How do you keep data on a device fresh? 31

Solution Space r Mobile poll r Cloud push r Each app push r Shared (infrastructure) push 32

Shared Push Service r A single persistent connection from device to a cloud push service provider r Multiple application providers push to the service provider r Service provider pushes to a device using the persistent connection r Two examples m Apple Push Notification Service (APNS) m Google Cloud Messaging (GCM) 33

Design Requirements of a Shared Push Service r Security/Authorization m Do not allow arbitrary app to push to a device r Scalability m A large scale system may have millions of clients r Fault tolerance m Client/device, push servers all can fail r Generality m Can be used by diverse applications 34

Design Point: Authorization Design 1: App does not know registered devices. Broadcast to all. A pp Design 2: App query registered devices; Multicast Registration(DEV_ID, App_ID) Device Design 3: Device notifies registration ID to its server; 35

Design Point: What to Push? r Option 1: Just push signal (data available) to devices and then devices fetch from app servers r Option 2: push app data A pp Device 36

Design Point: Reliability (What Can Go Wrong) A pp App sends to reg. IDs Reg. ID=Registration(DEV_ID, App_ID) Device notifies reg. ID to its server; 37

Apple Push Notification Service r i. OS device maintains a persistent TCP connection to an Apple Push Notification Server(APNS) A push notification from a provider to a client application Multi-providers to multiple devices 38

APNS Authorization: Device Token r Device token Contains information that enables APNs to locate the device m Client app needs to provide the token to its app provider m Device token should be requested and passed to providers every time your application launches 39

Apple Push Notification Data r Each push notification carries a payload m 256 bytes maximum m Best effort delivery r App provider provides a JSON dictionary object, which contains another dictionary identified by the key aps r aps specifies the following actions • An alert message to display to the user • A number to badge the application icon with • A sound to play 40

APNS Example: Client 1. 2. 3. 4. 5. 6. 7. 8. (BOOL)application: (UIApplication *)application did. Finish. Launching. With. Options: (NSDictionary *)launch. Options { // Let the device know we want to receive push notifications [[UIApplication shared. Application] register. For. Remote. Notification. Types: (UIRemote. Notification. Type. Badge | UIRemote. Notification. Type. Sound | UIRemote. Notification. Type. Alert)]; 9. 10. 11. 12. (void)application: (UIApplication*)application did. Receive. Remote. Notification: (NSDictionary*)user. Info { //user. Info contains the notification NSLog(@"Received notification: %@", user. Info); } 13. (void)application: (UIApplication*)application did. Register. For. Remote. Notifications. With. Device. Token: (NSData*)device. Token { NSLog(@"My token is: %@", device. Token); } 14. 15. 16. return YES; } 41

APNS Example: Server 1. 2. 3. 4. 5. 6. 7. $devicetoken ='f 05571 e 4 be 60 a 4 e 11524 d 76 e 4366862128 f 430522 fb 470 c 46 fc 6810 fffb 07 af 7’; // Put your private key's passphrase here: $passphrase = 'Push. Chat'; // Put your alert message here: $message = ’Yaron. Phone. Push. Test: yaron push notification!'; $ctx = stream_context_create(); Stream_context_set_option($ctx, 'ssl', 'local_cert', 'ck. pem'); stream_context_set_option($ctx, 'ssl', 'passphrase', $passphrase); // Open a connection to the APNS server $fp = stream_socket_client( 'ssl: //gateway. sandbox. push. apple. com: 2195', $errstr, 60, STREAM_CLIENT_CONNECT|STREAM_CLIENT_PERSISTENT, $ctx); 9. if (!$fp) exit("Failed to connect: $errstr". PHP_EOL); 10. echo 'Connected to APNS'. PHP_EOL; 8. 42

APNS Example: Server (cont’) 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. // Create the payload body $body['aps'] = array( 'alert' => $message, 'sound' => 'default' ); // Encode the payload as JSON $payload = json_encode($body); // Build the binary notification $msg = chr(0). pack('n', 32). pack('H*', $device. Token). pack('n', strlen($payload)). $payload; // Send it to the server $result = fwrite($fp, $msg, strlen($msg)); if (!$result) echo 'Message not delivered'. PHP_EOL; else echo 'Message successfully delivered'. PHP_EOL; // Close the connection to the server fclose($fp); 43

Google Cloud Messaging r Very similar to APNS GCM Servers See http: //developer. android. com/guide/google/gcm/gs. html for detailed steps 44

GCM Flow: App Developer Registration r App developer registers a project at Google r Open API console: https: //code. google. com/apis/console/ Project ID; Sender ID r After Create project 45

GCM Flow: Device App Registration r Enable cloud to device messaging in your app m Add permissions in Manifest m App (on device) registers with Google to get registration ID public class My. Activity extends Activity { public void on. Create(Bundle saved. Instance. State) { super. on. Create(saved. Instance. State); set. Content. View(R. layout. activity_main); GCMRegistrar. check. Device(this); GCMRegistrar. check. Manifest(this); final String reg. Id = GCMRegistrar. get. Registration. Id(this); if (reg. Id. equals("")) { GCMRegistrar. register(this, SENDER_ID); } else { Log. v(TAG, "Already registered"); } … } 46

Device App Handle Events <receiver android: name="com. google. android. gcm. GCMBroadcast. Receiver" android: permission="com. google. android. c 2 dm. permission. SEND" > <intent-filter> <action android: name="com. google. android. c 2 dm. intent. RECEIVE" /> <action android: name="com. google. android. c 2 dm. intent. REGISTRATION" /> <category android: name="my_app_package" /> </intent-filter> </receiver> r The GCMBroadcast. Receiver (defined in GCM library) handles the broadcast messages, and calls methods defined in. GCMIntent. Service, if you define this service 47

GCMIntent. Service // called after GCM library finishes registration // you need to send reg. Id to your server on. Registered(Context context, String reg. Id); on. Unregistered(Context context, String reg. Id); // called after your server sends a msg to GCM, and // GCM sends to this device on. Message(Context context, Intent intent); on. Error(Context context, String error. Id); on. Recoverable. Error(Context context, String error. Id) 48

App Server r If you use GCM server library import com. google. android. gcm. server. *; Sender sender = new Sender(my. Api. Key); Message message = new Message. Builder(). build(); Multicast. Result result = sender. send(message, devices, 5); 49

App Server r Using python (pip install python-gcm) from gcm import * gcm = GCM("AIza. Sy. Ccj 6 Kqf 6 j 8 Gh. SAR 3 o. Bw. Hr. Fw 6 y. Eoe 48 g. A") data = {'message': 'Yaron send you a message', 'id': '29617117'} reg_id = 'dj. S 067 hqz. Cw: AP 091 b. HD 7 vx. LSGuobcby. Jugj. JKp 5 Dt. ZQKg. Vxde Jce. UZkpa 0 Qx 0 u. JA 31 s 6 j-6 gtn. Lqd 9 t. E 9_Uh. Os. Mqu. EKt. Sn. Daxi 53 d 06 on. Y 0 dddr. Zhljbw. J 4 Xx 0 e. Vb. C 0 VRs 6 v. CFbc. JBu 4 Zzdo 4 g 0 sv. H' gcm. plaintext_request(registration_id=reg_id, data=data) 50

Summary: GCM Flow r Enabling cloud to device messaging m App (on device) registers with Google to get registration ID m App sends registration ID to its App Server r Per message m App Server sends (authenticated) message to Google m Google sends message to device, which sends to app r Disabling cloud to device messaging m App can unregister ID, e. g. , when user no longer wants push 51