• If you are citizen of an European Union member nation, you may not use this service unless you are at least 16 years old.

  • You already know Dokkio is an AI-powered assistant to organize & manage your digital files & messages. Very soon, Dokkio will support Outlook as well as One Drive. Check it out today!

View
 

EugsterPublishSubscribe

Page history last edited by PBworks 17 years, 1 month ago

Paper

  • pubsub allows decoupling of time, space, and synchonization
  • schemes: topic, content, type
  • relies on an event notification services which tracks subscriptions and handles delivery
  • subscribers use 'subscribe' 'unsubscribe', publishers use 'publish' 'advertise'
  • messages are not guaranteed delivered (msg may be dropped)
  • message passing
    • ancestor of pubsub: one message is sent directly to another
    • ansynchonous for proudcer, but not consumer
    • coupled in time and space
  • RPC
    • makes programming very easy: same model
    • more types of failures that need to be handled by the application
    • strong time and space coupling
    • alternative: fire and forget, wait-by-necessity (return value can be accessed later, asynchonously)
  • notifications
    • like callbacks, client registers interest with server
    • observer design pattern
    • communication can become complex
  • shared spaces
    • tuple space provides medium for message passing
    • comsumers read tuples synchonously (they do? oh, they have to loop to find tuples: no notification)
  • message queuing
    • which element is pulled by consumer is not based on content, but on ordering of queue
  • topic based pubsub
    • producers publish to keyword identified topics
    • improvements: heiarchies, wildcards,
  • content based pubsub
    • instead of assigning static topics, use content
    • content can be data structures, or use logical combinations like = > <, or even series of events
  • type based
    • can be used to model event kinds
    • allows better language integration (type checking)
  • events vs. messages
    • messages are simply delivered, notifications can also trigger events so the clients takes certain actions
    • messages are usually looked at as records, but can be opaque or highly ordered
  • central architecture: producers send message to coordinator, which then eventually sends them to consumers
  • distributed: tibco sends messages all over
  • compromise: have centralized arch with more than one server
  • persistance: some offer persistance guarantees, but most do not
  • priorities: different queue types can be used for high priority messages
  • transactions: mostly used by actual database systems
  • reliable: most do not offer quarantees, TIBCO offers a mix

 

Lecture

  •  publishers don't care who care, subscribes don't know where the messages come from
  • decoupling dimensions
    • space: single reference to event service instead of direct links to many partites
    • time: interactions can be delayed (long periods OK)
    • synchonization: operation to publish or recieve is asynchronous wrt the other end
      • my T is not extended by the existance of subscribers
      • Q: multicast, then, may not be synch nor time decoupled?
  • topic based:
    • publish events
    • subscribe to topics
    • topic IDed by keyword
    • similar to a channel
    • simple model, but you can generalize with heirarchies
    • similar problem for all unstructured data, how do you know what to subscribe to? how do you know how it's formed? you need external documentation
  • content based:
    • use sql, xpath, xquery, etc.
    • topic based means many people running lots of code all the time, but this could route thing more effeciently
    • go even further: complex events (state machines)

Comments (0)

You don't have permission to comment on this page.