Your SlideShare is downloading. ×
XMPP For Cloud Computing
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

XMPP For Cloud Computing

6,333
views

Published on

With the increase of popularity of the Cloud Computing, we propose an XMPP-based approach for the development and implementation of Cloud services. …

With the increase of popularity of the Cloud Computing, we propose an XMPP-based approach for the development and implementation of Cloud services.
XMPP offers many advantages over a basic HTTP+REST approach, allowing easy access to distributed and federated environments, real asynchronous services and information push toward consumers without resorting to HTTP tricks like Comet or WebSocket.

Published in: Technology, Education

0 Comments
7 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
6,333
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
227
Comments
0
Likes
7
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. XMPP for Cloud Services Cloud Camp – Milan 10 september 2009 Alessandro Malgaroli (Bluendo) [email_address] Fabio Forno (Bluendo) [email_address] Salvatore Loreto (Ericsson Research) [email_address]
  • 2. What is Cloud Computing?
    • Resources are provided as a service over the Internet
      • Dynamic Scalability
      • High Availability
    • Exploding in popularity – a critical trend of software architectures
    • Started with simple services; now growing complex
      • Now predominately based on REST architectures, web applications, web services
  • 3. Cloud Architecture Problems
    • REST is exclusively based on the Request/Response pattern
      • No push and asynchronous interactions
      • Polling doesn’t scale and isn’t real-time;
      • Need of two-way data exchange
    • (Comet/Bosh/WebSocket could be used to make some improvements)
    • Web services (SOAP) are overly complicated when handling:
      • Presence (availability) and discovery of remote services
      • Federation with third party services, access behind NAT and firewalls
      • Many-to-Many distribution pattern, asynchronous or multi step calls
      • Binary data, data streaming
    • Thesis : web services are great for simple cloud services or direct p2p interactions; XMPP is better for complex cloud services
  • 4. XMPP & Cloud Computing
    • XMPP with its extensions is a powerful protocol for cloud services that demonstrate several adavantages over HTTP-based Web Services:
    • Realtime capabilities
      • Eg. Heartbeats, alarms, asynchronous webservices
    • Efficient distribution of data: publish/subscribe, direct push
      • Eg. Configuration distribution, push RSS/Atom, data collection, log processing, results delivery to clients
    • Federated services & discovery
      • Easy interdomain RPCs
      • Access control based on JIDS and JID domains
      • Advanced discovery capabilities
  • 5. XMPP Architecture
    • XMPP provides a technology for asynchronous, end-to-end exchange of structured data.
    • XMPP architectural style builds an overlay network having:
      • Global addresses (JIDs)
      • Network availability (presence)
      • Concurrent information transactions
      • Distributed, federated network
      • Structured Data with XML payloads
    • The architecture similar to that of the email network, but it introduces several modifications to facilitate near-real-time communication
    ” Availability for Concurrent Transactions”(ACT) Peter Saint-Andre https://stpeter.im/index.php/2009/09/01/active-architectures
  • 6. XMPP Architecture
    • Global Addresses:
      • As with email, XMPP uses globally-unique addresses.
      • All XMPP entities are addressable on the network:
    • clients
    • servers
    • additional services accessible by clients and servers.
    • Presence:
    • the ability for an entity to advertise its network availability or &quot;presence&quot; to other entities via dedicated communication primitives (the <presence/> stanza).
  • 7. XMPP Architecture
    • Distributed Network, comprising servers, clients and components (server extensions)
    • End-to-end communication in XMPP is logically peer-to-peer but physically client-to-server-to-server-to-client
    • Federation across different domains
    capulet.org montague.org balcony.capulet.org [email_address] [email_address] clients servers components
  • 8. XMPP Architecture
    • Data is sent through persistent XML streams
    • The basic unit of meaning in XMPP is an “ XML stanza ”:
      • a fragment of XML that is sent over a stream
      • the root element of a stanza includes routing attributes (such as &quot;from&quot; and &quot;to&quot; addresses),
      • there are three basic stanzas with different behavior
      • the child elements of the stanza contain an extensible payload for delivery to the intended recipient
  • 9. XMPP Stanzas Pattern Examples Presence Broadcast to subscribed JIDs <presence from=‘juliet@capulet.org’> <c xmlns='http://jabber.org/protocol/caps‘ …/> </presence> Message One way Asynchronous <message from=‘romeo@montague.org’ to=‘juliet@capulet.org'> <event xmlns='http://jabber.org/protocol/pubsub#event'> … </event> </message> IQ Request Response <iq from=‘romeo@montague.org’ to=‘balcony.capulet.org’ type=‘get’ id=‘123’> <query xmlns=‘jabber:iq:disco#items”/></iq> <iq from=‘balcony.capulet.org’ to=‘romeo@montague.org’ type=‘result’ id=‘123’> <query xmlns=‘jabber:iq:disco#items”><items>…<items> </query></iq>
  • 10. An example: Publish/Subscribe
    • Observer pattern:
      • Data is not directly sent to consumers
      • Producers publish data to an intermediate service, into topics or nodes
      • Consumers subscribe to intermediate nodes
      • Pubsub usually implemented as a dedicated component in servers, any JID can be subscriber or publisher
    • Applications
      • Log monitoring, data collection and processing, atom, wave style applications
    • Why not (only) JMS?
      • Global naming / Federation / Presence / Sophisticated access model
  • 11. PubSub & REST
    • Each node is a resource were it is possible to do actions and it is identified by URIs:
      • xmpp:pubsub.acme.org;/atom/sport
      • xmpp:user@example.org;/pep/location
    • Each node contains items, which are stateful representation of the resource
    • Each node support actions :
      • PUBLISH: publish (PUT) an item or update (POST) and item
      • DELETE: retract an item
      • GET: retrieve a published item
      • LIST: retrieve the available items
      • SUBSCRIBE: be notified of any change in node items
    • REST + Realtime notifications + many-to-many
      • Delivery of notifications is bound to presence (no messages lost)
  • 12. PubSub Applications
    • Implementations
      • Builtin in most servers: tigase, ejabberd, openfire
      • Separate components: idavoll (http://idavoll.ik.nu/)
      • Clients: psi, lampiro, iphone3g, buddycloud, …
      • Libs: wokkel (python), smack (limited support, java)
      • Application servers: DEM (http://freedem.sf.net/)
    pubsub. capulet.org svc_1 svc_n Alarms Logs DEM Anomaly LogEvents … …

×