沉睡不醒的角落

昨天我和藍凝花了一下午時間把所有文檔再過了一遍，晚上再就把文檔全部轉換成pdf格式，打包壓縮，最后再一次檢查。看著作品被發出去，輕松了好多...終于忙完了，可以好好休息一下了。

對IBM的SOA大賽的了解是一次非常偶然的機會，四月中旬IBM在北航有一個SOA的技術講座，當時還并不知道有SOA這樣一個大賽，只是覺得講座內容跟自己的研究方向有很多相關之處，去聽一聽應該會有不少收獲。講座開始之前，我首先拿到了SOA大賽的宣傳單，當時便給藍凝和crazycy發短信，把他倆也召喚了過來，講座完后我們三人決定組隊參加SOA比賽。然而，團隊的成立，卻沒有我們想的那么快，之后，我被派去外地出差，接著，實驗室技術匯報，項目階段評審等等一系列的事情接踵而來，一直到5月中旬，大家才開始閑下來。2006年5月16日，這是一個特殊的日子，這一天，我們的SOA團隊正式成立。我和crazycy一致推舉藍凝為我們的組長，她是團隊里的唯一女生，也是我和crazycy平時經常所稱的“老大”。組長藍凝為團隊取名吉祥三寶，這是一個非常幸福的名字，希望能給我們帶來好運。在后面將近一個半月的日子，我們一起交流，共同探討。對SOA所涉及技術的廣博，都暗暗贊嘆，對參加這樣一個大賽，欣喜不已。

現在，我們只有靜靜的等待評審結果，同時好好整理前面學習的東西，SOA雖然只是一種思想，但其所牽涉到的技術是非常多的，只有善于總結，才能走得更遠。

這幾天光顧著在下面忙，好久沒來發帖了，上來匯報一下工作進度：在大家的通力合作，埋頭苦干之下，系統架構設計文檔、業務模型分析設計文檔、服務模型分析設計文檔、系統架構設計文檔、組件設計文檔已經大體確定下來，部分已經完成初稿。不過革命尚未成功，同志仍需努力，等忙完大家好好happy一下...

剛剛看了一下，有17個團隊提交了最后作品，還好，不是很多啊，竊喜:) ?估計很多團隊都跟我們一樣，在緊張地準備最后作品呢。這兩天突然發現，大賽初期看的很多文章現在回頭看看，頗有感覺啊，呵呵，溫故而知新，可以為師矣，這段時間還是學到了不少東西的。等有時間了，一定要把這一個半月學的東西好好整理一下，繼續工作了，相信我們能做的更好。

終于收到IBM大賽的ERP和CRM資料了，看了一下郵戳，17號寄出來的，現在才收到...稍微抱怨一下，為什么外省參賽團隊的軟件和資料總是比我們收到的要早，郁悶:( 不過還好，ERP的資料我們早就通過其他方式得到了，CRM的資料也就一個文檔，對后期工作影響不大，繼續工作中...

WBI Modeler是IBM WebSphere Business Integration Modeler簡寫，主要用于對業務流程建模，其用戶角色是業務分析人員，對使用者不要求有編程經驗。說白了，只要是對業務熟悉的人都可以使用這個軟件。這樣，使得業務分析人員可以把重點放在業務的優化和流程本身上，而不用考慮后期的IT設計和實現。

WBI Modeler是基于Eclipse開發的建模工具，其界面也和Eclipse有很多相似之處，用過Eclipse的人上手應該更快，基于Eclipse開發使其可輕松地與其他一些架構集成。此外，WBI Modeler還提供了對visio的支持，可以很容易地將visio畫的流程圖轉換成WBI Modeler中的流程圖，前提是必須建立visio中的部件和WBI Modeler中部件的一一對應。總的來說，WBI Modeler功能很強大。WBI Modeler提供的建模方式能大大加快業務建模的速度，并且將各種業務流程以非常美觀的方式展現給用戶和后期設計以及開發人員。

關于WBI Modeler的好處不多說了，IBM做的宣傳已經夠多了，下面說一說WBI Modeler的不足之處：首先是快捷鍵，快捷鍵大部分集中在過程編輯器中，而其他一些地方卻沒有，我感覺在項目樹視圖中加入快捷鍵是很有必要的，使用頻率很高，如果今后能提供將大大提高開發效率；其次是目前沒有批量處理功能，比如說過程或者任務的導出導入，只能一個一個的導出或者導入，這樣效率太低了，浪費不必要的重復勞動時間；再次，有些細節感覺沒有考率到，比如在過程編輯器中缺少全部選擇的功能，此外，WBI Modeler提供的幫助太簡單了，這是個小問題，相信以后會增加的。最后，WBI Modeler存在一個比較嚴重的bug，當建立某個業務過程時出現錯誤時，如果你將這個過程直接刪除，可能會遇到刪完之后過程還存在的情況，這時整個項目都不能用了。我已經遇到過兩次這樣的情況了，解決辦法是重新建立一個項目，再把原來有用的東西導出再導入新項目。

注意：這周六有技術講座：

創新業務,拓展商機 - 為您打下堅實的SOA基礎

通過現場演示和技術討論，您將了解到 IBM WebSphere優于其他供應廠商的解決方案,以及如何更好地實現面向服務的架構。您還將了解到如何提高您當前的業務流程的速度、準確性和成本效益。同時,您將了解 IBM WebSphere 信息管理解決方案是如何支持提供準確的、一致的、及時而連貫的業務信息。在講座中，我們還將討論主數據管理，并說明如何對通常分散在整個企業范圍內的產品、位置、貿易合作伙伴、組織和貿易條款信息等數據進行鏈接。最后，您將了解到可用于構建、部署、運行和管理的 IBM WebSphere 應用程序的各種工具。

會議日程安排：
08:00 – 09:00 會議簽到
09:00 – 09:30 簡介——通過 SOA 進行創新
09:30 – 10:30 使用 SOA 創建新的業務流程
10:30 – 10:45 業務現狀如何？——企業現狀概況
10:45 – 11:00 休息
11:00 – 11:30 使用 WebSphere 的企業服務總線
11:30 – 12:00 使用 WebSphere 進行主數據管理
12:00 – 13:00 午餐
13:00 – 14:10 信息集成服務
14:10 – 15:00 開發新的服務
15:00 – 15:15 休息
15:15 – 16:10 WebSphere SOA Foundation——為何 IBM 軟件優于 NetWeaver 和 .NET
16:10 – 17:00 管理 SOA 環境
17:00 – 17:15 總結
時間及地點：
日期??? 時間??? 城市??? 酒店??? 地址??? 會議室
6月17日 09:00 - 17:15?? 北京??? 亮馬河大廈????? 朝陽區東三環北路8號???? 萬黛廳


感覺比較有用，不過需要到http://www-900.ibm.com/cn/promotion/software/dwlive/webshpere_soa.shtml注冊。地點不算太遠，從咱們學校有直達車過去。上次的講座咱們去晚了比較虧，沒有拿到資料，這次得早點啦。

花了一上午時間尋找WBI并安裝成功，正準備學習怎么使用，下午IBM的軟件終于也到了，意味著我上午的工作基本白費，郁悶。IBM的軟件來得有點晚，今天已經15號了，距離最后提交正式結果還有兩周時間，時間緊迫。

兩周時間雖然很緊，但如果充分利用也是足夠的，前一段時間剛好給了我們充足的時間分析業務，大家對SOA的思想和相關技術也了解的差不多了，抓緊時間，加油干吧。

?? 這兩天專門找一些在公司工作，比較熟悉企業業務流程的同學談過了，發現我們團隊在分析業務的時候，有很多地方的理解存在偏差，對有些業務流程的分析是想當然的，導致在一些無謂的問題上浪費了時間。
?? 發現問題總是好的，亡羊補牢，猶未晚也。前一段時間的彎路不能白走，這將變為我們寶貴的經驗，后面的工作將更堅定的從實際業務的分析出發。需要的時候，向在企業管理方面和銷售方面的朋友取取經，這些寶貴的人力資源可不能浪費^_^
?? 如果能進入下一輪，咱們團隊的優勢就能充分發揮出來，呵呵，咱們實驗室主要的方向就是Web Service、中間件技術，這兩年咱們沒少和XML、Web Service、J2EE打交道，這些都是SOA的主要技術。當然，闖過第一關再說，否則，一切都是白搭...
?? 業務分析咱們現在已經進行得差不多了，就等著進行業務建模了，現在業務建模最重要的工具WBI還沒有，今天花了不少時間也沒找到，郁悶中...實在不行，只有趕緊聯系IBM了。

不知道是IBM效率低，還是學校辦事效率低，都過去快三周了，IBM提供的軟件到今天還沒有收到，看著其他隊伍早用上了，急啊。上網找找看吧，功夫不負有心人，還真有人把IBM.Rational.Software.Architect6.0共享了，不過只有RSA，其他都沒有找到。沒關系了，就從RSA開始吧，再說RSA也是IBM提供的SOA的主要工具之一。RSA整整四張盤，折騰了一上午，終于下載并安裝完了，平時最煩這種安裝配置工作了，沒技術含量還挺費時間:(
粗略了解了一下RSA，發現功能非常強大，系統提供的幫助也挺詳細的，但是不知道是不是真的實用，不多說了，抓緊時間學習使用......

會議比原定計劃推遲了兩天，這段時間大家一直比較忙，各種事情接踵而來，希望這幾天忙完了，大家有更多的時間放到比賽中來。
討論集中在對用友的ERP軟件和TurboCRM軟件的分析上，在這幾天里，crazycy主要分析題目和ERP的物流部分，藍凝分析TurboCRM，我分析ERP。
無論是ERP還是CRM，比賽主辦方給的東西都很多，討論的時候每個人也都帶來了一大疊資料。會議開始初期，初步確定了討論進程，先是藍凝給大家講解CRM，然后我講解ERP，最后大家再對CRM和ERP進行綜合分析。
藍凝對CRM的準備很充分，CRM講得很具體，在她講CRM的過程中ERP的內容也時不時穿插進來，結果對CRM和ERP進行綜合分析也同時進行了。討論進行了大約三個小時，取得了不少結果，具體內容這里就不詳細說了。
最后，我們確定了下一步工作，三天之后，也就是周六晚上進行第七次討論，下次每個人必須把對業務模式的分析畫出來，再把三個人的分析進行綜合，業務模式分析和設計到那時候就應該差不多了。

這次討論crazycy又遲到了，我和藍凝在會議室等了半天，crazycy，下次再遲到，就該罰你做俯臥撐了:)。

現在我們討論的周期差不多是三天一次，看來第一次討論制定的兩天一次的計劃不夠現實，不過還好了，我們一直有一個固定的泡泡群，幾乎每天都有小討論，平時一些看法在群里面都很快能夠得到統一。

討論的主要內容還是對業務的分析，大家都覺得上次的討論有點偏了，討論了很多ERP和CRM中已經實現的功能，而不是兩個系統之間的交互功能，以后咱們對業務的分析都應該建立在對實際實現的分析之上，一切從實際出發嘛，咱們可都是唯物主義者啊。

之后，大家就具體的業務分析圖，進行了審核，每個人都給出了自己的意見。此外，我們還對使用到的技術、采用的軟件工程方法以及工具進行了交流，討論的內容比較豐富，效果也是顯著的。

最后，我們對下一步工作作了一下簡單的分工：我負責ERP的分析，藍凝負責CRM的分析，crazy負責對題目的整體分析以及ERP中物流的分析。

剛剛看了水木的統計，截止到今天，也是報名的最后一天，差不多有320左右支SOA隊伍了，呵呵，好有壓力哦。還看了一些兄弟團隊的BLOG，有些開始建模了，報名早的隊伍，已經使用上IBM提供的軟件了，看來咱們得加快進度了，呼呼的趕啊。

首先，需要明確的是，SCA還沒有成為正式的標準，盡管SCA目前已經有比較穩定的規范，有些文章錯誤地將SCA作為標準來看待。

SCA目標：基于組件的編程一直是軟件業簡化編程和提高效率和質量的一個重要方法，但是往往對于不同語言我們有不同的組件模型，比如在J2EE技術領域，就有EJB，POJO，JDBC，JMS等。這對于項目初期分析和設計人員來說，是一個很大的挑戰，導致在初期就需要選定具體的語言和技術。SCA的目的是使用戶在構建企業應用時有一個不再直接面對具體的技術細節的層次，而是通過服務組件的方式來構建應用。這種方式也使得客戶的企業應用具有良好的分層架構，能夠很好的分離應用的業務邏輯和IT邏輯，不但易于應用的構建，也易于應用的更改和部署。

SCA和WSDL
WSDL是Web服務描述語言，但它只定義了服務接口，并不提供描述一個服務所依賴的其它服務，以及這個服務所需要使用的配置策略和服務之間的依賴關系。單獨通過WSDL很難實現服務之間的組合調用。SCA比WSDL走的更遠，SCA定義了服務組件模型以及服務組裝模型。服務模型允許服務開發者不但定義服務的接口而且還定義了這個服務和其他服務的依賴關系，以及這些交互（事務，安全，以及可靠 傳輸）之間的策略，還有服務潛在的配置等功能。服務組件是SCA中的基本組成元素和基本構建單位，也是我們具體實現業務邏輯的地方。我們可以把它看成是構建我們應用的積木。

SCA和JBI
SCA和JBI其目的有很多相同之處：JBI在JSR 208中被定義，已經成為使用Java語言把服務容器組裝為合成應用的標準；SCA是被推薦標準，為在不同平臺不同語言解決組裝問題的提供了更廣泛的方法。SCA關注是的SOA開發者最初看到的和接觸到的，SCA并不關注SCA各個模塊最后是如何實現的。如果把SOA分成三個抽象層次的話：業務、服務、技術。那么SCA對應的就是服務層的規范。JBI提供了一系列的API，用來建立開放、可擴展和模塊化的企業服務總線。可以說，JBI已經觸及到具體的技術層面。SCA沒有局限于具體語言，而JBI僅限于用Java，因此JBI的應用范圍更嚴格，在SOA未來的標準體系結構中，可能成為其中的一部分Java實現標準。