RestMS Introduction


Published on

A brief introduction to messaging for the web, and the new RestMS protocol specification. Presented at FOSDEM 2009.

Published in: Technology
  • :) restms is deliberately confined to the HTTP protocol, these ′scant few' options of POST, GET, DELETE, PUT, etc allows one to: * create feeds * create joins *configure joins * clip it all together then to your pipe * read it from a pipe. Imagine as if one used HTTP to configure yahoo pipes instead of a graphical user interface. Restms is simplifying 15 years worth of enterprise messaging technology and putting it over HTTP. Your opinion of too many features spoil the broth is true and i agree with you! Hopefully Restms is simple enough to be adopted! :)
    Are you sure you want to  Yes  No
    Your message goes here
  • Well I'm under the opinion features limit what something can offer. But I guess fair enough. Good luck!
    Are you sure you want to  Yes  No
    Your message goes here
  • Jeff, webhooks are cool, but restms encompasses so much more than intercepting a HTTP POST request. Webhooks can be introduced into restms as a nice to have. This presentation certainly doesn't need to make reference to webhooks - in my opinion webhooks and this pubsubhubbub features fall vastly short of what restms can offer.
    Are you sure you want to  Yes  No
    Your message goes here
  • Seems to be lacking any reference to the work being done in the realm of webhooks. :(
    Are you sure you want to  Yes  No
    Your message goes here
No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

RestMS Introduction

  1. 1. <ul><ul><li>RestMS </li></ul></ul><ul><ul><li>A new protocol for </li></ul></ul><ul><ul><li>web messaging </li></ul></ul><ul><ul><li>by Pieter Hintjens, iMatix Corporation </li></ul></ul><ul><ul><li>February, 2009 </li></ul></ul>
  2. 2. Why do we need Messaging? <ul><li>To connect the pieces together </li></ul><ul><ul><li>It's cheap to make applications </li></ul></ul><ul><ul><li>But how do they talk to each other? </li></ul></ul><ul><li>To create information feeds </li></ul><ul><ul><li>“I'm renting my apartment” </li></ul></ul><ul><li>To mine information feeds </li></ul><ul><ul><li>“I'm searching for an apartment” </li></ul></ul><ul><ul><li>Think: Yahoo! Pipes </li></ul></ul>
  3. 3. What Messaging should offer <ul><li>Easy to connect to from any application </li></ul><ul><li>Generic tools for creating & mining feeds </li></ul><ul><li>Early filtering vs. late filtering </li></ul><ul><ul><li>Don't send unwanted data over the network </li></ul></ul><ul><li>Scalability </li></ul><ul><ul><li>1, 10, 100, 1000, 10K, 100K messages/sec </li></ul></ul><ul><li>Loose coupling </li></ul><ul><ul><li>Hiding applications from each other </li></ul></ul>
  4. 4. Use cases <ul><li>“Server-side search of current events” </li></ul><ul><li>Watch IRC channels for interesting stuff </li></ul><ul><li>Monitor thousands of news channels </li></ul><ul><li>Track thousands of postings and uploads </li></ul><ul><li>Follow thousands of stock values </li></ul><ul><li>etc. </li></ul>
  5. 5. The State of the Art <ul><li>Web messaging </li></ul><ul><ul><li>Simple direct messaging </li></ul></ul><ul><ul><li>RSS, AtomPub, XMPP, SOAP </li></ul></ul><ul><li>Business messaging </li></ul><ul><ul><li>Java repackaging of legacy tools </li></ul></ul><ul><ul><li>Queues, pub-sub </li></ul></ul><ul><li>Enterprise messaging </li></ul><ul><ul><li>Mostly expensive closed products </li></ul></ul><ul><ul><li>Queues, pub-sub </li></ul></ul>
  6. 6. Challenges <ul><li>Routing model </li></ul><ul><ul><li>Hard-wired or dynamic? </li></ul></ul><ul><ul><li>Fixed algorithms or extensible? </li></ul></ul><ul><li>Protocol vs. product </li></ul><ul><ul><li>Real competition in the market? </li></ul></ul><ul><ul><li>Free and open digital standard? </li></ul></ul><ul><li>Complexity </li></ul><ul><ul><li>Simple to understand and use </li></ul></ul><ul><ul><li>Or, “enterprise technology”? </li></ul></ul>
  7. 7. Why is messaging unpopular? <ul><li>Too complex </li></ul><ul><ul><li>“Results 1 - 10 of about 264,000 for 'soap too complex'.” </li></ul></ul><ul><ul><li>Complexity means extra cost </li></ul></ul><ul><li>Not interoperable </li></ul><ul><ul><li>Products are not standards </li></ul></ul><ul><ul><li>Languages are not universal </li></ul></ul><ul><li>Still too few FOSS solutions </li></ul><ul><ul><li>Mainly due to lack of open standards </li></ul></ul>
  8. 8. In an Ideal World... <ul><li>Based on free and open standards </li></ul><ul><li>Generic & extensible routing </li></ul><ul><li>Easy to use in any language </li></ul><ul><li>Runs nicely on any operating system </li></ul><ul><li>Fast enough for real work </li></ul><ul><ul><li>Low latency (10usec to 1sec) </li></ul></ul><ul><ul><li>High volume (1/sec to 1M /sec) </li></ul></ul>
  9. 9. AMQP <ul><li>Free and open standard </li></ul><ul><li>Generic & extensible routing </li></ul><ul><li>Not easy to use in any language </li></ul><ul><ul><li>It's a complex binary protocol that needs an API stack for each language </li></ul></ul><ul><li>Runs nicely on any operating system </li></ul><ul><li>Fast enough for real work </li></ul><ul><li>AMQP is great except it's inaccessible </li></ul>
  10. 10. AtomPub <ul><li>Free and open standard </li></ul><ul><li>A single limited routing model </li></ul><ul><ul><li>Publish to feed, read from feed: no filtering or routing </li></ul></ul><ul><li>Easy to use in any language </li></ul><ul><li>Runs nicely on any operating system </li></ul><ul><li>Fast enough for real work </li></ul><ul><li>AtomPub is great except it's limited </li></ul>
  11. 11. So why RestMS? <ul><li>AMQP showed us something new </li></ul><ul><ul><li>Generic routing (“exchange-binding-queue”) </li></ul></ul><ul><ul><li>Portability (Linux, AIX, Solaris, win32) </li></ul></ul><ul><ul><li>Interoperability (C, C++, Java, .NET, Python) </li></ul></ul><ul><ul><li>Performance (~500k msg/sec in OpenAMQ) </li></ul></ul><ul><li>But it remains inaccessible </li></ul><ul><ul><li>How do I use AMQP from the web? </li></ul></ul><ul><ul><li>How do I use AMQP in language X? </li></ul></ul>
  12. 12. Magic potions <ul><li>Take the best of AMQP and AtomPub </li></ul><ul><li>Shake briskly, allow to cook: </li></ul><ul><li>AMQP's routing model (improved) </li></ul><ul><li>RESTful access over ordinary HTTP(S) </li></ul><ul><li>Portable & interoperable </li></ul><ul><li>Documented as free and open standard </li></ul><ul><li>Interoperate with AMQP networks </li></ul>
  13. 13. Architecture Public Internet Company Intranet RestMS Server HTTP network AMQP network RestMS Server
  14. 14. How RestMS works <ul><li>Publishers send messages to feeds </li></ul><ul><li>Subscribers create pipes </li></ul><ul><ul><li>And join their pipes to feeds </li></ul></ul><ul><li>Subscribers then read from their pipes </li></ul><ul><ul><li>Get message, process message, loop </li></ul></ul><ul><li>Joins specify the routing arguments </li></ul><ul><ul><li>By key, by expression, etc. </li></ul></ul>
  15. 15. RESTful access <ul><li>If you know HTTP, you know REST </li></ul><ul><li>Create/Read/Update/Delete resource </li></ul><ul><ul><li>POST creates a new resource </li></ul></ul><ul><ul><li>GET reads a resource </li></ul></ul><ul><ul><li>PUT updates a resource </li></ul></ul><ul><ul><li>DELETE spawns... just kidding, it deletes the resource </li></ul></ul><ul><li>Resources are mostly shown in XML </li></ul><ul><ul><li>But RestMS also supports JSON </li></ul></ul>
  16. 16. Why REST / HTTP is cool <ul><li>It is simple </li></ul><ul><li>It uses existing transports </li></ul><ul><li>It uses existing security </li></ul><ul><li>It uses existing libraries </li></ul><ul><li>It uses existing metaphors (CRUD) </li></ul><ul><li>It scales on a web infrastructure </li></ul><ul><ul><li>Proper attention to caching </li></ul></ul>
  17. 17. REST / HTTP gotchas <ul><li>Rather chatty </li></ul><ul><ul><li>Can be solved by batching writes and reads </li></ul></ul><ul><li>Polled vs. event driven </li></ul><ul><ul><li>Can be solved by using “long polls” </li></ul></ul><ul><li>Rather verbose (XML envelopes) </li></ul><ul><ul><li>Ignore the problem, it will go away </li></ul></ul><ul><li>Not an “enterprise technology” </li></ul><ul><ul><li>Wait, it will be </li></ul></ul>
  18. 18. What's available now? <ul><li> </li></ul><ul><ul><li>Draft RestMS specifications </li></ul></ul><ul><ul><li>Example client code (Perl, for now) </li></ul></ul><ul><li> </li></ul><ul><ul><li>Source code for OpenAMQ & Zyre </li></ul></ul><ul><li> </li></ul><ul><ul><li>All about Zyre </li></ul></ul><ul><li> </li></ul><ul><ul><li>Live RestMS server, running Zyre </li></ul></ul>
  19. 19. Conclusions <ul><li>Messaging is a great tool </li></ul><ul><li>But the good stuff is too complex </li></ul><ul><li>And the simple stuff is too limited </li></ul><ul><li>Time for a simple, capable option </li></ul><ul><li>Based on a free and open standard </li></ul><ul><li>With a solid implementation </li></ul>
  20. 20. Thank you <ul><li>For more information please contact the author at </li></ul><ul><li>Comment & discuss at </li></ul><ul><li>Email list, see </li></ul>