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