Saturday, March 16, 2013

Message Oriented Architecture / Enterprise Integration Patterns/MESSAGE-DRIVEN BEAN (MDB)

Message Oriented Architecture 

1. Point-to-Point Messaging
2. Publish-Subscribe Messaging


Database and Message Queue are Transactional. 
Transactional means once failed it can roll back. (using some log mechanism)



Message Headers

JMSType: Specifies the type of message you are sending. 

JMSMessageID: 
A JMSMessageID is a String value that functions as a unique key for identifying messages in a historical repository.

JMSCorrelationID
A client can use the JMSCorrelationID header field to link one message with another. A typical use is to link a response message with its request message.


JMSDestination
The JMSDestination header field contains the destination to which the message is being sent.

JMSRedelivered
Gets a boolean indication of whether this message is being redelivered (type bool).

JMSDeliveryMode
Gets the Constants.DeliveryMode value specified for this message.













 Enterprise Integration Patterns

http://www.eaipatterns.com/    以该结构为准,课件结构稍微有些乱

Message Construction

Command Message
An application needs to invoke functionality provided by other applications. It would typically use Remote Procedure Invocation, but would like to take advantage of the benefits of using Messaging.

How can messaging be used to invoke a procedure in another application?



Event Message
Several applications would like to use event-notification to coordinate their actions, and would like to use Messaging to communicate those events.
How can messaging be used to transmit events from one application to another?




Messaging Channels


eg. message bus channel

What is an architecture that enables separate applications to work together, but in a decoupled fashion such that applications can be easily added or removed without affecting the others?

Structure the connecting middleware between these applications as a Message Bus that enables them to work together using messaging.

Message Bus is a combination of a common data model, a common command set, and a messaging infrastructure to allow different systems to communicate through a shared set of interfaces. This is analogous to a communications bus in a computer system, which serves as the focal point for communication between the CPU, main memory, and peripherals. Just as in the hardware analogy, there are a number of pieces that come together to form the message bus:







What Is a Message-Driven Bean?



message-driven bean is an enterprise bean that allows Java EE applications to process messages asynchronously. This type of bean normally acts as a JMS message listener, which is similar to an event listener but receives JMS messages instead of events. The messages can be sent by any Java EE component (an application client, another enterprise bean, or a web component) or by a JMS application or system that does not use Java EE technology. Message-driven beans can process JMS messages or other kinds of messages.



http://www.onjava.com/pub/a/onjava/excerpt/ejb3_ch13/index.html?page=5#17
Message-driven beans (MDBs) are stateless, server-side, transaction-aware components for processing asynchronous JMS messages. Newly introduced in EJB 2.0, message-driven beans process messages delivered via the Java Message Service.

Message-Driven Bean (MDBs) is JMS message listener (a kind of EJB), they are stateless, server-side components.


Diagram


Sample application

The tutorial uses a sample application, StockTrader, to illustrate the writing of an MDB. The sample uses a simple message driven bean buyAgentMDB that is contacted by a client which wishes to buy shares. The client looks up the BuyQueue and implements the javax.jms.MessageListener. It provides a private method buy() that takes two arguments: a double value that holds the price and a string (stockSymbol) that holds the scrip symbol.

Sample application components

Client
StockServer.javaActs as a Server and displays fluctuations in stock prices.

Destinations
StockMarketA topic where stock price details are published to StockServer
BuyQueueA queue on which BuyAgent MDB listens for stocks under buy advise
SellQueueA queue on which SellAgent MDB listens for stocks under sell advise

Message Driven Beans
BuyAgentMDB.javaInvoked by messages received from BuyQueue and in turn updates the topic StockMarket
SellAgentMDB.javaInvoked by messages received from SellQueue and in turn updates the topic StockMarket
SubscriberBean.javasends client's buy/sell actions to BuyQueue or SellQueue on the message s



Q&A:
Q:
I went through some materials and tried to figure out the relation between MOA and SOAP. Professor, could you please help me to confirm my following conclusion towards those Architectures? 

The assignment 6 - SOAP web service is actually regular SOAP, which means it is SOAP over HTTP.

Alternatively, we could implement web service using SOAP over JMS, by adding middleware like IBM WebSphere MQ, to improve the asynchronous ability of the webservice. This is so call Message-Oriented Architecture. Am I right?

Another question:  
SOAP: 
   1. SOAP over HTTP    2. SOAP over JMS
REST: 
   3. REST totally over HTTP

 How NO.1 and NO. 3 realize asynchronous? 

Thank you.


A:
SOAP is agnostic about the message transfer and transport that it runs over.  SOAP over HTTP over TCP is de facto the standard one.  SOAP over JMS is another.  But in fact JMS is just a Java API for accessing message-passing transports, so you should really think of SOAP over MSMQ or MQSeries, for example.

The original idea of SOAP was basically RPC over the Web, so the tools like Java EE and WCF support an RPC-like API, which is antithetical with asynchronous message-passing.  I hope we will have the opportunity for a JMS assignment, so you will see this very different form of interaction, that is more suitable for cross-internet B2B communication.

Q:
Thank you very much, professor.  very clear, I got it.
So, I think MOA is more reliable since messages could be 'buffered' in queue. That is main reason why it is more suitable for cross-internet B2B communication.

I got new question though.
If the number of messages is large enough at a certain moment, what could happen on SOAP over HTTP/ REST Web Service? Overflow? lose messages?  


No comments:

Post a Comment