Lecture 7 HO 7 -1- Publish/Subscribe ECSE 6780- Software Engineering 1I © HY 2012 Lecture 7 HO 7 -2- Messaging Pattern • Publish/subscribe (or pub/sub) is a messaging pattern where senders (publishers) of messages are not programmed to send their messages to specific receivers (subscribers) • Published messages are characterized into classes, without knowledge of what, if any, subscribers there may be • Subscribers express interest in one or more classes, and only receive messages that are of interest, without knowledge of what, if any, publishers there are • Many-to-many relationships • Decoupling of publishers and subscribers can allow for greater scalability and a more dynamic network topology ECSE 6780- Software Engineering 1I © HY 2012 Lecture 7 HO 7 -3- Message Filtering • Subscribers typically receive only a subset of the total messages published • Topic-based: messages are published to "topics“, “subjects”, or named logical channels - subscribers in a topic-based system will receive all messages published to the topics to which they subscribe, and all subscribers to a topic will receive the same messages • Content-based: messages are only delivered to a subscriber if the attributes or content of those messages match constraints defined by the subscriber – Filters may be strings consist ing of logical combinations of name-value pairs, comparison operators, wildcards – Or may be template objects (type-based) or executable code • Some systems support a hybrid where publishers post messages to a topic while subscribers register content-based subscriptions to one or more topics ECSE 6780- Software Engineering 1I © HY 2012 Lecture 7 HO 7 -4- Topology • Publishers post messages to an intermediary message broker (aka event notification service) and subscribers register subscriptions with that broker • The broker performs a store and forward function to route messages from publishers to subscribers • Publishers are not blocked while producing events • Subscribers can get asynchronous notification of events ECSE 6780- Software Engineering 1I © HY 2012 Lecture 7 HO 7 -5- Event Services ECSE 6780- Software Engineering 1I © HY 2012 Lecture 7 HO 7 -6- COM Events (Request-Reply) ECSE 6780- Software Engineering 1I © HY 2012 Lecture 7 HO 7 -7- Original COM Events • Choice between two techniques – Interface callback mechanism – Connectable Objects ECSE 6780- Software Engineering 1I © HY 2012 Lecture 7 HO 7 -8- Interface Callbacks • Client implements a COM interface defined by the event publisher component, and passes to the component a pointer to this interface • Client then receives notifications (i.e., callbacks) when the component calls a method through the interface implemented by the client code ECSE 6780- Software Engineering 1I © HY 2012 Lecture 7 HO 7 -9- Connectable Objects • Also known as connection points • Client implements a COM interface defined by COM’s standard IConnectionPoint interface (and other related interfaces), and passes a pointer to this interface – Connect (Advise) and disconnect (Unadvise) – Enumerate connections (EnumConnections) • Client then receives notifications (i.e., callbacks) when the component calls a method through the interface implemented by the client code ECSE 6780- Software Engineering 1I © HY 2012 HO 7 Lecture 7 - 10 - Example ECSE 6780- Software Engineering 1I © HY 2012 Lecture 7 HO 7 - 11 - COM Events Limitations • Only a series of interfaces - developers still have to write all the code to implement these interfaces (no infrastructure) • Implementing a complex application making heavy use of events may require complex coding to handle multiplexing events to multiple connected clients, circular references, deadlock situations, etc. • Client and component lifetimes are tightly coupled through the exchanged interface pointer - the client must be running and connected to receive events • It is difficult to get between a component instance and its clients to monitor the connection, provide trace information, etc. ECSE 6780- Software Engineering 1I © HY 2012 Lecture 7 HO 7 - 12 - COM+ Events • Publish-subscribe model rather than request-reply • An intermediary object manages communication between a publisher and its subscribers – Publishers and subscribers are not tightly bound – Asynchronous: Publishers do not block when firing an event and subscribers do not wait to receive ECSE 6780- Software Engineering 1I © HY 2012 Lecture 7 HO 7 - 13 - Event Class • An event class component sits between a publisher of information and any potential subscribers • COM+ Events system provides the actual implementation of this intermediate object • Eliminates the need to directly pass an interface pointer ECSE 6780- Software Engineering 1I © HY 2012 Lecture 7 HO 7 - 14 - Publisher • The event class looks like a subscriber to the publisher • When a publisher wants to “fire” an event, it creates an instance of the event class, calls the appropriate method, and then releases the interface (as in queued components) • The runtime then determines how and when to notify any subscribers ECSE 6780- Software Engineering 1I © HY 2012 Lecture 7 HO 7 - 15 - Subscriber • To receive events, need only implement the event interface • Registers with the COM+ Events service by creating a subscription object, through the IEventSubscription interface • The component will be (activated and) notified as events are published • Either persistent or transient subscriptions ECSE 6780- Software Engineering 1I © HY 2012 HO 7 Lecture 7 - 16 - Example ECSE 6780- Software Engineering 1I © HY 2012 HO 7 Lecture 7 - 17 - Example ECSE 6780- Software Engineering 1I © HY 2012 Lecture 7 HO 7 - 18 - Improved COM+ Events • Provides a “third-party” publish-subscribe environment: Once an event class is created, anyone can become a publisher or subscriber of the events • Supports a rich filter mechanism: one can filter at the publisher method level – IPublisherFilter allows the event class object to decide which subscribers receive a particular event, or at the method parameter level – ISubscribeControl supports a complex criteria string per subscriber ECSE 6780- Software Engineering 1I © HY 2012 Lecture 7 HO 7 - 19 - Filtering Example ECSE 6780- Software Engineering 1I © HY 2012 Lecture 7 HO 7 - 20 - EJB Events Message-Driven Beans ECSE 6780- Software Engineering 1I © HY 2012 Lecture 7 HO 7 - 21 - Messaging • Messaging enables distributed communication that is loosely coupled • A component sends a message to a destination, and the recipient retrieves the message from the destination • The sender and the receiver do not have to be available at the same time • The sender does not need to know anything about the receiver, nor vice versa • Both only need to know which message format and which destination to use • Differs from tightly coupled technologies, such as Remote Method Invocation (RMI), which require an application to know a remote application’s methods ECSE 6780- Software Engineering 1I © HY 2012 Lecture 7 HO 7 - 22 - Message Consumption • Synchronous (pull): A subscriber explicitly fetches the message from the destination by calling the receive method the receive method can block until a message arrives or can time out if a message does not arrive within a specified time limit • Asynchronous (push): A client can register a message listener with a consumer - Whenever a message arrives at the destination, the provider delivers the message by calling the listener’s onMessage method, which acts on the contents of the message ECSE 6780- Software Engineering 1I © HY 2012 Lecture 7 HO 7 - 23 - Message-Driven Beans • Allows Java Enterprise Edition applications to process messages asynchronously (session beans can only receive synchronous messages) • Acts as a JMS (Java Message Service) message listener • Messages can be sent by an application client, another enterprise bean, a web component, or a JMS system that does not use Java EE technology ECSE 6780- Software Engineering 1I © HY 2012 Lecture 7 HO 7 - 24 - JMS API • Common set of interfaces and associated semantics that allow programs written in Java to communicate with other messaging implementations • The JMS API can ensure that a message is delivered once and only once (PERSISTENT) • Lower reliability, at most once (NON_PERSISTENT), is available for applications that can afford to miss messages ECSE 6780- Software Engineering 1I © HY 2012 Lecture 7 HO 7 - 25 - JMS API Architecture • A JMS provider is a messaging system that implements the JMS interfaces and provides administrative and control features (included in Java EE) • JMS clients are the programs or components that produce and consume messages • Messages are the objects that communicate information between JMS clients • Administered objects are preconfigured JMS objects (destinations and connection factories) created by an administrator for the use of clients via Java Naming and Directory Interface (JNDI) ECSE 6780- Software Engineering 1I © HY 2012 Lecture 7 HO 7 - 26 - JMS API Architecture ECSE 6780- Software Engineering 1I © HY 2012 Lecture 7 HO 7 - 27 - Messaging Domains • Either point-to-point or publish/subscribe • JMS API provides common interfaces not specific to either model ECSE 6780- Software Engineering 1I © HY 2012 Lecture 7 HO 7 - 28 - Point-to-Point • Built on the concept of message queues, senders and receivers • Each message is addressed to a specific queue, and receiving clients extract messages from the queues established to hold their messages • Queues retain all messages sent to them until the messages are consumed or until the messages expire ECSE 6780- Software Engineering 1I © HY 2012 Lecture 7 HO 7 - 29 - Point-to-Point • Each message has only one consumer • A sender and a receiver of a message have no timing dependencies - the receiver can fetch the message whether or not it was running when the client sent the message • The receiver acknowledges the successful processing of a message ECSE 6780- Software Engineering 1I © HY 2012 Lecture 7 HO 7 - 30 - Publish/Subscribe • Clients address messages to a topic • Each message can have multiple consumers • Publishers and subscribers are anonymous and can dynamically publish or subscribe to the content hierarchy • The system distributes the messages arriving from a topic’s multiple publishers to its multiple subscribers • Topics retain messages only as long as it takes to distribute them to current subscribers ECSE 6780- Software Engineering 1I © HY 2012 Lecture 7 HO 7 - 31 - Publish/Subscribe • Publishers and subscribers have a timing dependency – a client that subscribes to a topic can consume only messages published after the client has created a subscription, and normally the subscriber must continue to be active in order for it to consume messages • JMS relaxes this timing dependency by allowing durable subscriptions, which receive messages sent while the subscribers are not active ECSE 6780- Software Engineering 1I © HY 2012 Lecture 7 HO 7 - 32 - How do Message-Driven Beans and Session Beans differ? • Developer does not define any interfaces, only a bean class that implements the MessageListener interface • Otherwise resembles a stateless session bean: – Retains no data or conversational state for a specific client – All instances equivalent, allowing EJB container to assign a message to any bean instance in a pool – Can process messages from multiple clients (one at a time) – Client-independent state can be retained across messages (e.g., JMS API connection, open database connection, object reference to an enterprise bean) ECSE 6780- Software Engineering 1I © HY 2012 Lecture 7 HO 7 - 33 - Lifecycle of a Message-Driven Bean • The container usually creates a pool of message-driven bean instances • For each, the container calls the @PostConstruct method, if any ECSE 6780- Software Engineering 1I © HY 2012 Lecture 7 HO 7 - 34 - Lifecycle of a Message-Driven Bean • A message-driven bean is never passivated, and it has only two states: nonexistent and ready to receive messages • At the end of the life cycle, the container calls the @PreDestroy method, if any ECSE 6780- Software Engineering 1I © HY 2012