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

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

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

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

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

??????? ·功能需求——定義了開發(fā)人員必須實現(xiàn)的軟件功能，使用戶利用系統(tǒng)能夠完成他們的任務，從而滿足了業(yè)務需求。

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

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

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

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

????????????
這里有一個很好的關(guān)于SOA的過去，現(xiàn)在，將來的比喻。
SOA------〉城市的發(fā)展
初期：一個小村落，兩個小村落，一些小村落
現(xiàn)在：城市，要規(guī)劃哪些是商業(yè)區(qū)，哪些是政府，哪些是居民區(qū)等等，要有一個全局的規(guī)劃
將來：虛擬的社區(qū)，在家里即可購物，等等。即虛擬化，動態(tài)的劃分。
未完，待續(xù)。。。。。

??? 在IT行業(yè)有兩個越來越普遍的發(fā)展方向，一個是架構(gòu)方面的，一個是方法學方面的，面向服務的架構(gòu)設計師可以從中有所收獲。第一個就是MDA（模型驅(qū)動架構(gòu)），由提出CORBA的OMG模型提出。MDA認為架構(gòu)設計師首先要對待創(chuàng)建的系統(tǒng)有一個形式化的UML（也是由OMG提出）的模型。MDA首先給出一個平臺無關(guān)的模型來表示系統(tǒng)的功能需求和Use Cases，根據(jù)系統(tǒng)搭建的平臺，架構(gòu)設計師可以由這個平臺無關(guān)的模型得到平臺相關(guān)的模型，這些平臺相關(guān)模型足夠詳細，以至于可以用來直接生成需要的代碼。
????? SOA的另一個基礎是敏捷方法（AM），其中非常有名的方法是極限編程（XP）。AM的目標是僅僅創(chuàng)建用戶想要的,AM的核心思想就在于其敏捷性－處理需求變更的敏捷性.
????? 那么，如何開始SOA呢？經(jīng)過了幾次討論，大家已經(jīng)度過了盲人摸象的階段，實質(zhì)性的進展是從5.30號晚上的那次討論開始的。從那次后，已經(jīng)逐漸的看清了方向。
????? 最佳的方法時開始構(gòu)建較小的SOA，側(cè)重于提高當前缺乏效率的交互性。例如，假設使用一個系統(tǒng)上需要重新鍵入到另一個系統(tǒng)的打印報告，將兩個計算機系統(tǒng)緊密聯(lián)系在一起，這會消耗時間、浪費成本，導致出錯，而且數(shù)據(jù)無法保持罪行。可以設計一個簡單的基于Web服務SOA項目，直接鏈接信息，將含更新的SOAP消息發(fā)送到合作伙伴系統(tǒng)，而不是打印報告。

　　開始簡單的SOA使我們可以在作出大的決定前之前先衡量，并在出現(xiàn)大的問題之前獲得小改善的經(jīng)驗。
??? 所以，再次看到SOA的的第一條準則：“業(yè)務驅(qū)動服務、服務驅(qū)動技術(shù)”的時候，深有感觸。這才是問題的本源，原來的幾次討論和想法，其實都偏離了軌道。

? 最近發(fā)現(xiàn)大家好像很久都沒去水木了，覺得還是建議大家經(jīng)常去看看。一方面，即使的了解相關(guān)的信息，另一方面，看看各兄弟隊伍的情況，是否有些可借鑒的東西。可以參與一些討論，廣開言路很重要啊。
? 同時，也歡迎個兄弟隊伍來我們的blog做客，多提寶貴意見，共同進步嘛。

?????決定參加比賽了，第一步當然是制定計劃，三個人，例會。?
?每人手里拿了一份打印的參賽題目要求，雖然之前已經(jīng)看過了，但是三個人還是坐在一起，又重新的細讀了一遍
? 然后，經(jīng)過討論，初步的確定了題目的要求以及我們自己的想法。
? 題目總體要求：ERP與CRM的信息同步
???????????????????業(yè)務機會和銷售訂單的有效整合
??題目的擴展要求 ：這部分需要創(chuàng)造性和創(chuàng)新點，優(yōu)先級稍微靠后
??????先抓主要矛盾，次要矛盾的解決貫穿在整個的過程中。努力攻克主要矛盾，在完成前者的基礎上，完成次要矛盾的解決。做到重點突出，張弛有道。
?????由于本次會議只是大家碰個頭，之前大家沒怎么準備，所以，決定，兩天后進行第二次討論。在以后的兩天里，大家自由發(fā)揮，可以采用不同的方法，
關(guān)注不同的東西，對本次大賽及SOA相關(guān)的東西做一個概括性的了解。
????? ? 我對自己的情況還是比較了解的，我不是一個很抽象的人，換句話說，當學一個新的東西的時候，我并不喜歡先看它的理論，相反，通常我會找一些實際
應用的小例子，對它有個整體和感性的把握后，再去探尋它的理論部分。這也是為什么我在學一樣東西的時候會先去找Tutorial等東西的緣故。而且，我覺得這個方法非常的適合我。所以，很自然的，我把這兩天安排成看網(wǎng)站上的相關(guān)案例及分析，來實實在在的感覺一下soa的具體應用。