? 再出色的女人，如果身邊空空，就使人覺得凄涼。比如張愛玲，她的感情生活就像李碧華所說，是一口古井，任由后人來淘出的都是一地清冷月光。
夫唱婦隨，才能交相輝映，。
? 同樣再出色的人（這次不分男女了哈），如果孤軍奮戰的話，也會使人覺得凄涼。不過我們就不一樣了，我們是一個小家庭，不論是感情生活還是技術
生活都是一片汪洋，隨你怎么淘，淘出的都是金色的陽光。
? 呵呵，漂起來了。。。。。。
? 提交作品了，心里的石頭也放下了一塊，回頭看看這一個多月的時間，真的是成長了許多，無論是技術上的，還是團隊合作和管理上的。技術上，
雖然寫的文章總被人批評，不過至少有人對我的文章有興趣，也算是另一種安慰啦。團隊合作上，平時不覺得，真到了在一起做項目的時候，才發現每個人都和以前
不太一樣啊。也是通過這次大賽，讓我發現了每個人的另一面。團隊管理上，呵呵，說來慚愧啊，沒為大家做什么事，而且雖然只有3個人，不過這個隊伍也不好帶啊。雖然有爭執，雖然有困難，可是我們還是堅持下來了，不是嗎？
? 怎么說呢，在這段日子里，雖然有一些事讓我生氣，但是，也有很多事情令我感動。是大家的堅持，我們才會走到今天，才會完成作品。
? 所以，無論我是要哭泣著，還是微笑著與你道別
? 人生本就是一場難分悲喜的演出，
? 而當燈光照過來，
? 我就要必須唱出那最最艱難的一幕，
? 曲終人散后，
? 無論我是要哭泣著，
? 還是微笑著與你們道別，
? 我都會慶幸曾與你們同臺。

搞笑啊，因為每次都是默認的用戶名，結果，前幾天把用戶名給忘了，怎么也上不來了，把我急的啊~~~
看著那么多批評我文章的話，我有話沒地方說，更急~~~~
結果牙也腫了，眼睛還長東西，~~~~~~
現在好啦，事基本都忙得差不多啦，晚上提交附件，而且也把用戶名給想起來啦，上來喊兩聲，嘿嘿，兄弟們，我又回來啦

共同工作：
查找相關資料
分析題目
討論需求
業務流程分析
技術學習
個人分工
姓名?工作?備注
dubb?CRM相關資料及接口分析
1.??
crazycy??
liuli?1.ERP?
1.2.2 整體分工：
姓名?工作?備注
dubb?協調工作
會議的組織
進度的安排
相關技術的學習?會議的紀要由每個人輪流整理
每次會議有一個主要的發言人
crazycy?相關團隊消息的跟蹤
相關網站的跟蹤
相關技術的學習?相關技術的學習，liuli相對來說多一些
liuli?相關工具的掌握
相關會議的跟蹤
相關技術的學習?
1.2.3 文檔設計階段
時間?任務?負責人?備注
2006.6.10至2006.6.18?業務模型的分析設計?liuli?這是個迭代的過程，與服務建模交互
2006.6.13至2006.6.20?服務模型分析設計?dubb?,liuli幫助修改了文檔
2006.6.18至2006.6.23?系統架構設計?liuli，crazycy?用例模型分析和數據模型分析由liuli完成
2006.6.23至2006.6.27?組件設計?crazycy?以上過程均是迭代的過程
2006.6.23?項目綜述?dubb?
2006.6.25?設計實施計劃?dubb?
2006.6.27至
2006.6.28?整體文檔的檢查?全體成員?每個文檔都是經過了數次迭代與修改，在所有文檔完成后，大家由一起將所有的文檔進行了檢查，包括：
格式，內容，標點符號，圖形等。
SOA相關資料查找分析
TurboCRM分析完畢
用友ERP分析完畢
題目要求的業務流程分析完畢
需求分析完畢
業務流程圖分析討論完畢
需要工具安裝完畢
業務建模完畢 ? 聽說周六有IBM的技術講座，哪能錯過，趕緊注冊。。。。?
? 周六早上起了個大早，和liuli一起到體育館門口等IBM的車，到了體育館才發現，已經有n多xdjm在等了。看來同志們對soa還是很感興趣的啊。不過，讓人ft的是等了好久都不見車來，已經9點鐘了，人群開始散去，這時候，我和liuli立刻做出了一個決定，不能再等了，自己做車去。于是我們倆跑到了知春路去做公交車。
?? 好不容易到了，會議已經開始40多分鐘了，門口的IBM工作人員問了我們班車的情況，我們宣泄了一下不滿，因為有好多人因為車沒來就放棄參加了，如果不是之前IBM發信說有班車來接的話，然后早上等了一個多小時車沒來，他們肯定會來的。
? 聽了一天，就IBM的產品來說總體感覺就是比較人性化，我指的是提供了圖形界面的工具已經自動的代碼生成工具。因為，在下午有個環節是拿微軟和IBM比較，比較的內容是將已有的功能包裝成服務并發布，兩位博士一個負責用IBM的產品，另一個用的是微軟的產品，同時進行。在大屏幕上可以清晰的看見IBM的執行過程全部是圖形界面，其間并沒有涉及到具體的代碼；而微軟的產品并沒有圖形界面，所有的操作看來就是一個程序員在寫程序一樣，結果可想而之，速度當然比不上IBM而且其復雜程度也對程序員有很高的要求，即必須知道底層代碼及所有的環節才行。
? 不過，我在想，如果微軟也把同一套流程做成了圖形界面，同時添加了代碼自動生成的功能，那么那時候，兩者再比較，結果會是什么樣呢？
? ps：liuli在用WBI的時候，發現了不少的bug。

? 經過以前的數次討論，方案終于定了下來，在接下來的日子里，每個人負責不同的部分，開始進入各種文檔的實現階段。
? 我負責寫總體的需求文檔，雖然以前寫過類似的什么需求分析啊，概要設計啊，相信設計等等，但是，這次的需求文檔還是花了我很多的心思。
在寫之前特別又看了一遍《需求分析黃金法則》那20條，寫了一個晚上，一氣呵成，不過不知道是因為文筆退步還是別的原因，寫出的文檔，大家不是很滿意，
咳，嚴重郁悶中。
??????? ·業務需求——反映了組織機構或客戶對系統、產品高層次的目標要求，通常在項目定義與范圍文檔中予以說明。

??????? ·用戶需求——描述了用戶使用產品必須要完成的任務，這在使用實例或方案腳本中予以說明。

??????? ·功能需求——定義了開發人員必須實現的軟件功能，使用戶利用系統能夠完成他們的任務，從而滿足了業務需求。

??????? ·非功能性的需求——描述了系統展現給用戶的行為和執行的操作等，它包括產品必須遵從的標準、規范和約束，操作界面的具體細節和構造上的限制。
這幾項都有包括啊，回頭問問差在哪里了。
? 雖然大賽并沒有要求提供需求分析文檔，但是需求在開發、測試、質量保證、項目管理以及相關項目功能中起著重要作用，所以，就像軟件工程的流程一樣，一切從需求開始，一切文檔化。
???????? 接著修改。。。。。。。

評價成熟度后，建設SOA模型的2個方法學：
1.CBM業務組件建模，從企業整體，metrics結構
2.業務（組件）劃分，核心價值鏈，組件如何對不同組件，不同業務目標進行劃分
三.服務緘默，架構企業價值鏈業務流程------〉服務模型
1.服務發現（找到可能成為服務的幾個候選者），包括三個方法：
? （1）頂級流程分解（粗粒度）
? （2）業務目標的建模（目標-----〉服務）
? （3）分析現有系統，劃分，類比 （接口，形式。。。）
以上可以引出服務目錄的概念。
服務目錄：就是潛在的服務的集合
2.服務的規約
? 從服務目錄入手，分解屬性，跟現有哪些業務關連在一起，決定哪些成為服務-----〉模型，書面specification
3.服務的實現決策
? 哪些需要包裝，哪些需要新方法
? 與傳統架構結合（用例等）
4.如何從服務模型映射到參考架構
? 要與企業架構隔離開
? 業務功能-----〉服務
? 服務中介-----〉ESB
? 非功能------〉服務監管
? 可參考流程引擎
5.*服務監管
SOA靈活性{
????????? 服務模型
????????? 復雜性-----〉ESB
????????? }
監管方法：{
?????????? 服務模型
?????????? 參考架構
????????? }
方法學：{
???????? 角色
???????? 職責
???????? }
柔性架構快速適應變化
服務注冊庫------企業IT的生命周期管理
?????????
????????????

最近大家比較忙（實驗室的項目要出新版本，論文快要截至了），再加上天氣的原因，團隊出現了一些不良的情緒。
但是我覺得既然參加比賽，每個人都要出力，不能指望別人看。當大家都沒看的時候，要有緊迫感而不是互相指責。如果有人看的好，那就給大家說說，并不是你看得好，就要炫耀，就要鄙視別人。大家情緒都不好，在這種情況下更不能把個人的情緒帶到團隊里來。
為了更好的跟蹤進度以及避免上面的情況再發生，我提議，每天大家報告一下自己的進度。無論做什么，剛開始都是有熱情的，但是過了一個階段，就會出現疲憊的心理，剩下的就是當熱情散去的枯燥的工作。所以，同志們，做好打持久戰的準備，調整好自己的心態，堅持下去，肯定沒問題的。

IT面臨的問題：架構的復雜性，具體表現在
????? 1.程序臃腫，據統計，70%的經費都用在了對已有系統的改造等方面，只有不到30%的用在了增加新功能上。
????? 2.脆弱性：
????? 3.遲鈍：
企業架構：應用與應用之間的業務邏輯有重復
問題來源：接口問題
????? 第一家開發商對系統會對原有接口進行改造，隨著時間的推進，又來了第二家，第三家，第四家開發商，每個開發商都對系統進行改造，結果原來的接口已經面目全非。
根源：沒有人從全局對業務邏輯，實現，接口的定義等統一的考慮。
SOA可以很好的解決以上問題。
SOA原理：接口在現在應用之上構建抽象業務服務模型。由服務推出新的需求？構建應用有規范，標準？
由垂直應用到水平應用，公共平臺上的服務串接，接口由服務模型解決。
架構：基于ESB柔性架構：
????? 優點：1.不需要了解別人的協議等細節，反問外部的信息都用自己本地協議來訪問。技術依賴較小。
??????????? 2.業務流程與IT耦合度小。
?????? ESB起到服務虛擬化作用。服務在不同地區實現不一樣，ESB通過服務中間隔離不相關因素，使上層業務看到的相對一致。
??????????? 3.數據模型。使應用訪問數據時，不用考慮地域區別如北京，上海；不用考慮數據的格式如ORACAL，SQLSEVER等差異。
??????????? -----〉企業數據模型+數據即成=一致的服務
認證模塊剝離開企業架構------〉無序世界變成了有序的世界
思路：關于服務建模方法學，幫助企業構建SOA
????? 5個步驟：
????? 1.SOA成熟度模型定位企業現在，未來的成熟度，對比它們之間的明顯差異，幫助實施轉型。SOA更多的從業務角度討論問題。
??????? 分6個層面討論
??????? （1）服務模型指導開發（業務改變，不單獨，要全局）
??????? （2）監管
??????? （3）方法學
??????? （4）應用：越來越面向業務。組裝，松架構，安全，性能，數據，集成，管理隔離開。
??????? （5）虛擬基礎設施遷移
???????????? 現有SOA成熟度{service
?????????????????????????? component}
???????????? 公共服務模型引起組裝。

????????????
這里有一個很好的關于SOA的過去，現在，將來的比喻。
SOA------〉城市的發展
初期：一個小村落，兩個小村落，一些小村落
現在：城市，要規劃哪些是商業區，哪些是政府，哪些是居民區等等，要有一個全局的規劃
將來：虛擬的社區，在家里即可購物，等等。即虛擬化，動態的劃分。
未完，待續。。。。。