隨筆 - 11, 文章 - 1, 評論 - 20, 引用 - 0
          數據加載中……

          基于攔截器的企業應用構造

              在上一篇文章里,我們使用了基于事件傳遞的機制來對企業應用的子系統進行解耦,但是由于需要強制地繼承或者實現一個廣播事件的接口EventBrocast,實際上,就職責分離和功能單一的角度來看,前篇文章中的例子中,這個機制對OrderService侵入太大了,我們必須尋找更為有效的方法,不需要程序實現某個接口或繼承某個超類來完成這個工作,這一切必須對具體程序完全透明,這個責任誰能承擔呢,毫無疑問,歷史的重擔就落在了AOP身上 ;) 。下面我們來看看具體的實現:
              OrderService已經實現,除了訂單的處理,沒有任何的職責,為了完成事件的廣播,必須要有一個途徑能夠攔截到OrderService的所有方法調用,然后分析調用的語義(參數),并根據這些內容給廣播出去。而恰好,AOP組織統一的接口MethodInterceptor可以完成這個功能。于是上篇文章的程序可以這樣修改:

             // 訂單服務只負責做好自己的事
            

           public class OrderService {
               
          public Order saveOrder(Order order){
               。。。。處理訂單
               。。。保存
               }
            }

           

            而為了攔截任何的方法調用,則實現了攔截器EventBrocaster:
           

          public class EventBrocaster extends LifeEventBrocast implements MethodInterceptor  {
              
          private List eventListeners;
              
          public void setEventListener(List list){
               
          this.eventListeners=list;
              }
              
          public List geteEventListeners(){
               
          return eventListeners;
              }
              
          public Object invoke(MethodInvocation invoke) {
                obj 
          = invoke.proceed();// 執行被攔截的方法完成業務操作
                Object[] params = invoke.getArguments();
               Object param 
          = params.length > 1 ? params : params[0];
               Event le 
          = new Event(param, eventType);
               brocast(le);
          // 廣播
              }
            }

           

            事件偵聽器:
           

           public OrderEventListener implements EventListener{
            
          private FinancialService  financialService;
             
          public void setFinancialService(FinancialService fs){
               
          this.financialService=fs;
             }
            
          public void performed(Event e){
             Order order 
          =(Order) e.getObject();
              financialService.createRequestOfMoney(order.getAmount());
            }
           }

           


            然后,在Spring配置里將這些組件全部連接起來:

           1.OrderService實現:
           <bean id="orderServiceImpl" class="OrderService" autowire="byName">
           </bean>

           2. 聲明OrderService代理:

           <bean id="orderService" class="org.springframework.aop.framework.ProxyFactoryBean">
            <property name="target">
             <ref local="orderServiceImpl"/>
            </property>
            <property name="interceptorNames"> <!--攔截器列表-->
             <list>
              <value>eventBrocaster</value>
             </list>
            </property>
            <property name="singleton">
             <value>true</value>
            </property>
           </bean>
            3.事件廣播攔截器
           <bean id="eventBrocaster" class="com.wolfsquare.core.service.EventBrocaster" singleton="true">
            <property name="lifecycleListeners">
                <list>
                 <ref bean="orderEventListener"/>
                </list>
               </property>
           </bean>
            4.具體的財務子系統的偵聽器實現與財務系統的通訊:
            <bean id="orderEventListener" class="OrderEventListener" autowire="byName">
             <propety name="financialService"><ref bean="financialService"/></property>
           </bean>

              這樣,我們與具體實現無關的事件廣播就做到了,聰明的朋友看到這里,肯定想到了攔截器方式不僅僅適用與事件廣播,還可以實現事務的統一管理,事實上Spring的事務管理就是這樣完成的,還可以實現權限的控制例如Acegi,簡直有點象萬能的膠水,呵呵。

              從兩篇文章的逐步探討下,同一個機器,同一個虛擬機之內的數據通訊都可以實現了,那么異構系統和多虛擬機間的通訊又如何處理呢,于是ESB(企業服務總線)的概念就慢慢浮現出來了,不過這個不在本文探討的范疇了,也許在不久的將來,我會補上這一篇。

          (全文完)

           

           

          posted on 2005-12-06 20:49 wolfsquare 閱讀(2821) 評論(6)  編輯  收藏 所屬分類: 企業應用

          評論

          # re: 基于攔截器的企業應用構造  回復  更多評論   

          這樣的好文章還要讓我等多久呢?
          期待高手再度亮劍!
          2005-12-26 12:38 | 胡子魚

          # re: 基于攔截器的企業應用構造  回復  更多評論   

          在流程方面看看這遍文章再審視自己的代碼`````只覺得自己惡心了!
          2006-01-19 23:51 | JavaXP

          # re: 基于攔截器的企業應用構造  回復  更多評論   

          因為自己也在思考AOP、事件驅動、組件容器之間的關系。在我的想法中,AOP、特別是動態AOP的攔截點和事件的觸發點是很相似的,比如也可以定義 before事件和after事件(只是around定義起來比較別扭)。實際上,我也找到了以事件驅動的觀點來認識AOP的學術文章("Towards Event-Based Aspect-Oriented Runtime Environments")。從事件驅動的觀點出發,我思考了事件的路由、狀態/上下文、存儲/轉發、同步/異步等機制,也逐漸發現按這個思路發展下去很自然地就拓展到了工作流、BPEL和ESB這些領域。我試圖把在現有IoC組件容器解決了組件靜態依賴關系如何裝配的基礎上,將AOP/事件驅動來作為組件之間的交互機制,把事件路由作為業務邏輯控制的核心,然后,就可以很容易地整合工作流這類概念。所以,我看到這篇文章非常驚喜,能和你用 mail/msn等方式直接聯系嗎?

          忘了,我的MSN和email都是suntoech@sh163.net
          2006-01-23 09:48 | qiangyt

          # re: 基于攔截器的企業應用構造  回復  更多評論   

          文章不錯! 向你學習
          2006-04-26 14:07 | pc

          # re: 基于攔截器的企業應用構造  回復  更多評論   

          挺有深度,我喜歡
          2007-03-08 16:46 | cljspn

          # re: 基于攔截器的企業應用構造  回復  更多評論   

          時至今日才想到這個問題,差距好大啊
          2008-04-07 10:05 | lexus
          主站蜘蛛池模板: 改则县| 冀州市| 勐海县| 山阳县| 资阳市| 宁晋县| 平邑县| 田东县| 肥城市| 班玛县| 化德县| 长宁区| 满洲里市| 常德市| 霍山县| 建水县| 江城| 弥勒县| 丰镇市| 平山县| 绵阳市| 深泽县| 樟树市| 册亨县| 南平市| 柳河县| 呈贡县| 台中市| 长垣县| 交口县| 台山市| 彰化县| 台中县| 广南县| 高要市| 重庆市| 会东县| 巴塘县| 台中县| 织金县| 安仁县|