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)