Enterprise Bean / Message Driven Bean

JAVAEE 6 Tutorial 

Part IV
Enterprise Beans

Part IV explores Enterprise JavaBeans components. This part contains the following chapters:

• Chapter 22, Enterprise Beans
• Chapter 23, Getting Started with Enterprise Beans
• Chapter 24, Running the Enterprise Bean Examples
• Chapter 25, A Message-Driven Bean Example
• Chapter 26, Using the Embedded Enterprise Bean Container
  Chapter 27, Using Asynchronous Method Invocation in Session Beans

Chapter 22
Enterprise Beans

Enterprise beans are Java EE components that implement Enterprise JavaBeans (EJB) technology. Enterprise beans run in the EJB container, a runtime environment within the GlassFish Server (see Container Types). Although transparent to the application developer, the EJB container provides system-level services, such as transactions and security, to its enterprise beans. These services enable you to quickly build and deploy enterprise beans, which form the core of transactional Java EE applications.

Java EE Server and Containers

What Is an Enterprise Bean?

Written in the Java programming language, an enterprise bean is a server-side component that encapsulates the business logic of an application. 

Benefits of Enterprise Beans

For several reasons, enterprise beans simplify the development of large, distributed applications. First, because the EJB container provides system-level services to enterprise beans, the bean developer can concentrate on solving business problems. The EJB container, rather than the bean developer, is responsible for system-level services, such as transaction management and security authorization.

Types of Enterprise Beans

Table 22-1 summarizes the two types of enterprise beans. The following sections discuss each type in more detail.

Table 22-1 Enterprise Bean Types

Enterprise Bean Type	Purpose
Session	Performs a task for a client; optionally, may implement a web service
Message-driven	Acts as a listener for a particular messaging type, such as the Java Message Service API

Message Driven Bean

http://docs.oracle.com/javaee/6/api/javax/ejb/MessageDriven.html

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.

A 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?

http://docs.oracle.com/javaee/6/tutorial/doc/gipko.html

A 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.

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.java Acts as a Server and displays fluctuations in stock prices. Destinations StockMarket A topic where stock price details are published to StockServer BuyQueue A queue on which BuyAgent MDB listens for stocks under buy advise SellQueue A queue on which SellAgent MDB listens for stocks under sell advise Message Driven Beans BuyAgentMDB.java Invoked by messages received from BuyQueue and in turn updates the topic StockMarket SellAgentMDB.java Invoked by messages received from SellQueue and in turn updates the topic StockMarket SubscriberBean.java sends 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?  

The Architecture of Open Source Applications

http://www.aosabook.org/en/distsys.html

from

http://www.aosabook.org/en/distsys.html

Repository Pattern

Repository Pattern

Objectives

Use the Repository pattern to achieve one or more of the following objectives:

• You want to maximize the amount of code that can be tested with automation and to isolate the data layer to support unit testing.
• You access the data source from many locations and want to apply centrally managed, consistent access rules and logic.
• You want to implement and centralize a caching strategy for the data source.
• You want to improve the code's maintainability and readability by separating business logic from data or service access logic.
• You want to use business entities that are strongly typed so that you can identify problems at compile time instead of at run time.
• You want to associate a behavior with the related data. For example, you want to calculate fields or enforce complex relationships or business rules between the data elements within an entity.
• You want to apply a domain model to simplify complex business logic.

Repository means storage location for safety and preservation.  Its a single place where you can find related items. This terminology is used by some frameworks like Spring. But whats the need of repository?

Example
Lets take an example. There is a big basket of toys. Toys contain Soft toys, wooden toys, miniature toys. If a kid wants miniature toys, he has to spill all the toys from the basket and separate the needed ones. Kid’s dad doesn’t want him to do that. He separates the miniature toys, that becomes a miniature toy repository, and gives it to child. Goal is never allow the kid to put hands on the basket.
 
Kid’s dad does the job of maintaining toy basket. Once the kid is done playing, he puts the toys back into the basket. When kid wants to play he gives the kid whatever toy he wants.  When dad brings a new toy for the kid, he is going to put that in the toy bag. In general, dad maintains the toy repository.

Implementation
Repository pattern, as described in Domain Driven Design, in a typical java environment backed by frameworks like Hibernate and Spring.

Child.java

public class Child   {
     public void Play(ToyRepositoryBase toyRespository) {     
         //Gets all the toys seperated by Dad
         List<Toy> toys = toyRespository.GetToys();
         //Now child starts playing
         System.out.println("Child is playing with " + toyRespository.GetType());
          //Child is done playing. Now dad puts back the toy into the bag
          toyRespository.PutToysBackIntoBasket(toys);
     }
}

Get all the toys

//Toy is a abstraction of miniature toy or soft toy or wooden toy
public abstract class Toy
{

}

//Miniature toy is concrete class.
public class MiniatureToy extends Toy
{

}

Similarly we can have wooden toys, metallic toys and so on.
Get the toy repository 

//This toy repository is abstract of miniature toy repository, wooden toy repository or soft toy repository
public abstract class ToyRepositoryBase  {
//Child calls this to get toys before starting to play
    public abstract List<Toy> GetToys();

     //One child is done playing, dad puts the toys back into the basket
    public abstract void PutToysBackIntoBasket(List<Toy> toys);
}

//Concrete class of miniature toy repository
public class MiniatureToyRepository : ToyRepositoryBase  {
 //Consider this as action performed by dad, 
//who gives the miniature toys to child
    @Override
    public List<Toy> GetToys()
    {
        List<Toy> miniatureToys = new ArrayList<Toy>();
        return miniatureToys;
    }

    //This is action performed by dad. Once child is done playing,
    // he puts back the toys into bag
    @Override
    public void PutToysBackIntoBasket(List<Toy> toys)
    {
         //Here you can use cache or database
    }
}

I have omitted other sub classes like WoodenToyRepository for brevity here.
We are not allowing the kid to put hands on the toy bag. Same way, business logic has no knowledge of database and  related implementation logic. All that business logic knows is how it can get the needed entity from repository, and how it can give the entity back to repository. It is the responsibility of repository to interact with the data source.
Advantage
This pattern has several advantages.

1. No duplicate codes needed. If you got another child who wants wooden toys, same logic works.
2. Business logic is simplified, since its interactions is only with repository and repository entities.
3. Less scope for errors
4. Strong typing, since Miniature toy repository gives miniature toys.
5. Easy to test.

同步和异步的区别

同步Synchronous和异步Asynchronous的区别
同步是指：发送方发出数据后，等接收方发回响应以后才发下一个数据包的通讯方式。  
异步是指：发送方发出数据后，不等接收方发回响应，接着发送下个数据包的通讯方式。  

 举个例子：普通B/S模式（同步）AJAX技术（异步）
同步：提交请求->等待服务器处理->处理完毕返回 这个期间客户端浏览器不能干任何事
异步: 请求通过事件触发->服务器处理（这是浏览器仍然可以作其他事情）->处理完毕
--------------------------------------------------------------------------------------------------------------------
同步就是你叫我去吃饭，我听到了就和你去吃饭；如果没有听到，你就不停的叫，直到我告诉你听到了，才一起去吃饭。
异步就是你叫我，然后自己去吃饭，我得到消息后可能立即走，也可能等到下班才去吃饭。

所以，要我请你吃饭就用同步的方法，要请我吃饭就用异步的方法，这样你可以省钱。
--------------------------------------------------------------------------------------------------------------------
举个例子 打电话时同步 发消息是异步