EJB学习笔记(4)

     工作的事情终于基本上定下来了，这里先把ejb学习笔记的最后一个部分，关于Message Driven Bean的内容补上（其实是早就看完了，只不过工作不定下来，没心情写blog）。之后我会写一些非技术blog包括这次的找工作经历，心得，以及一些影评。

      在说mdb之前先要谈到jms（java message system）因为这个才是最原始的需求。顾名思义，jms其实就是提供消息服务的一组api接口，于是自然而然的想到了RMI-IIOP，因为RMI-IIOP是现在java远程通信的一个最常用的方式，既然已经有了RMI-IIOP，为什么还要有jms呢？

      RMI-IIOP在实际的企业级应用中，有许多问题是不能解决的，比如，在服务器完成对rmi的请求之前会一支处于阻塞状态，另外如果服务器瘫痪了，客户再也找不到请求了等等。

      显而易见的，要解决这些问题必须有一个中间服务器来专门调度，处理，存储消息，这就是jms服务器他本质上也是一种中间件服务。

      再jms的消息处理机制中有两种消息处理类型，我们称之为消息域(message domain)，一种domain叫做发布/订阅（pub/sub)模式，另一种时点对点模式(PTP)。对于前者多个消息生产者同事对多个消息消费者交互有点类似于网络的多播概念。而对于后者多个生产者能同时把消息发送到一个队列种，但是每个消息只能被消费者消费一次！

      事实上再ejb种，mdb（message driven bean）就是负责处理来自jms的消息的！当然了ejb2.0后的mdb补仅仅能够接受jms消息。mdb和其他两种bean不同，没有home接口，本地home接口，远程接口和本地接口。它是无状态的，也不会返回异常给用户，因为有了jms就存在异步交互过程，所以客户那里不可能等待是否有异常抛出。

      当然了，由消息传递本身会引发出袭夺问题，这就是基于jms的mdb的陷阱，比如有坏消息的概念，何为坏消息？如果mdb未确认消息已经消费，jms会不断向目的地发消息。这种情况很容易发生，再cmt（container management transaction)的情况下，消息的消耗和确认属于事物范围内，若事物有错，会一支回滚，也就一支没确认消费消息，这样jms就会一直发送消息。

      另外由于ejb规范里没有定义mdb要返回给客户返回值，所以我们也可以采取一些变通的方法来给客户传送一些回应，比如回应也当作一个jms。

       当然了，具体的关于mdb的经验还是要在不断的项目中学习到的！

       这篇是ejb的最后一篇学习笔记 mastering ejb这本书的第三部分，涉及到的诸如事物和负载均衡的一些列高级主题，我现在阅读也没意义，应为这些只有在真正的项目种才能完全领悟！