工作流、soa以及esb

          最近公司項目經理派我研究工作流并考慮在項目中使用。很有一些心得。工作流應用我將之分為狹義工作流和廣義工作流。對狹義工作流而言,你可以將之理解為在工作流設計器里畫畫節點以及方向箭頭,設置好就節點數據,動作就差不多了。(具體可以參見jbpm的websale這個demo)。

          廣義的工作流是對服務之間的整合。核心問題是業務節點和工作流節點之間的映射,以及業務數據和工作流數據之間的映射,和普通工作流一樣還有流程判斷等等服務。實現了這些,各個業務模塊之間的數據就可以通過服務,以定好的方式(進行方向控制和格式轉化)在各個節點之間流通,達到了服務整合的目的。


           

            IBM為ESB定義了四個必備的功能:“路由器”——根據信息內容,在不同應用和服務之間進行信息傳輸和路由;“轉換器”——進行應用之間的通信協議轉換;“翻譯機”——進行應用之間的消息格式轉換;“收發室”——處理來自不同渠道的業務事件(同步傳輸,異步傳輸,發布/訂閱等方式)。

            其中“路由器”和“收發室”都是針對服務的重用而設計的,而“轉換器”和“翻譯機”則專門用來解決異構的通信問題。

            針對重用和異構這兩個難題,倪曉兵認為ESB提供了兩個核心的功能,服務的管理和數據的轉換。


          我們DEC項目的目標就是建立一個全能服務倉庫(暫時我在DEC設計人員zy哪里得到的信息),而服務之間如何路由,如何轉換,語義的協調都沒有考慮,而后者卻是成敗的關鍵。

          最關鍵的語義翻譯這一點,就現在的技術上來說還不能做到(需要很高的機器智能才能達到使得不同的系統的業務詞匯可以正確的映射,更何況是在所有的系統之間進行映射,同時應用在企業級的應用環境中)

          也許真的有這樣的幻想,但是真的能夠做到這一步么?我深深的懷疑。就目前的技術手段,如果要達到數據映射的高度正確性,必須由人不同系統之間需要協調的數據進行語義確認方能進行有效的映射。

          當考慮到還必須做到ESB系統對其接入的所有的服務數據的語義都這樣做時。我懷疑真的需要做到協調所有的服務么?

          也許ESB的應用范圍就是在公司內部或者有限范圍內的整合目標明確的業務節點之間業務的整合。
                  

          posted on 2008-04-11 17:11 wanglin 閱讀(685) 評論(1)  編輯  收藏

          評論

          # re: 工作流、soa以及esb 2008-04-11 17:22 wanglin

          而為了真正達到服務之間的松耦合。有一個很重要的問題需要解決:業務流程誰發起?還有一個比較次要的問題:開始服務節點和工作流之間的關系互動關系。其他的流程稍微簡單一點。

          初始我考慮使用定時器輪訓各個開始節點的服務。考慮到性能原因就放棄了。也許更可行的方案是ESB在應該有一個客戶端去配置監控各個服務節點,并主動向ESB提交服務,同時接受服務回饋。

          不存在一種對現有模塊零要求的整合,這也許是最少侵入性的方案了。  回復  更多評論   


          只有注冊用戶登錄后才能發表評論。


          網站導航:
           
          <2008年4月>
          303112345
          6789101112
          13141516171819
          20212223242526
          27282930123
          45678910

          導航

          統計

          常用鏈接

          留言簿(1)

          隨筆檔案

          搜索

          最新評論

          閱讀排行榜

          評論排行榜

          主站蜘蛛池模板: 长垣县| 大英县| 铜陵市| 连平县| 旺苍县| 即墨市| 锦州市| 大同县| 平塘县| 宁安市| 大名县| 昆山市| 镇赉县| 丘北县| 天津市| 宜君县| 云林县| 扎兰屯市| 屏东市| 澄江县| 榆林市| 剑阁县| 恩施市| 邳州市| 大连市| 赤水市| 永善县| 方正县| 谢通门县| 桐梓县| 连云港市| 乳源| 巨野县| 舒兰市| 镇原县| 友谊县| 濮阳市| 随州市| 江油市| 新巴尔虎左旗| 扬州市|