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

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

共同工作：
查找相關(guān)資料
分析題目
討論需求
業(yè)務(wù)流程分析
技術(shù)學(xué)習(xí)
個人分工
姓名?工作?備注
dubb?CRM相關(guān)資料及接口分析
1.??
crazycy??
liuli?1.ERP?
1.2.2 整體分工：
姓名?工作?備注
dubb?協(xié)調(diào)工作
會議的組織
進(jìn)度的安排
相關(guān)技術(shù)的學(xué)習(xí)?會議的紀(jì)要由每個人輪流整理
每次會議有一個主要的發(fā)言人
crazycy?相關(guān)團(tuán)隊消息的跟蹤
相關(guān)網(wǎng)站的跟蹤
相關(guān)技術(shù)的學(xué)習(xí)?相關(guān)技術(shù)的學(xué)習(xí)，liuli相對來說多一些
liuli?相關(guān)工具的掌握
相關(guān)會議的跟蹤
相關(guān)技術(shù)的學(xué)習(xí)?
1.2.3 文檔設(shè)計階段
時間?任務(wù)?負(fù)責(zé)人?備注
2006.6.10至2006.6.18?業(yè)務(wù)模型的分析設(shè)計?liuli?這是個迭代的過程，與服務(wù)建模交互
2006.6.13至2006.6.20?服務(wù)模型分析設(shè)計?dubb?,liuli幫助修改了文檔
2006.6.18至2006.6.23?系統(tǒng)架構(gòu)設(shè)計?liuli，crazycy?用例模型分析和數(shù)據(jù)模型分析由liuli完成
2006.6.23至2006.6.27?組件設(shè)計?crazycy?以上過程均是迭代的過程
2006.6.23?項目綜述?dubb?
2006.6.25?設(shè)計實施計劃?dubb?
2006.6.27至
2006.6.28?整體文檔的檢查?全體成員?每個文檔都是經(jīng)過了數(shù)次迭代與修改，在所有文檔完成后，大家由一起將所有的文檔進(jìn)行了檢查，包括：
格式，內(nèi)容，標(biāo)點符號，圖形等。

SOA相關(guān)資料查找分析
TurboCRM分析完畢
用友ERP分析完畢
題目要求的業(yè)務(wù)流程分析完畢
需求分析完畢
業(yè)務(wù)流程圖分析討論完畢
需要工具安裝完畢
業(yè)務(wù)建模完畢 ? 聽說周六有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)容是將已有的功能包裝成服務(wù)并發(fā)布，兩位博士一個負(fù)責(zé)用IBM的產(chǎn)品，另一個用的是微軟的產(chǎn)品，同時進(jìn)行。在大屏幕上可以清晰的看見IBM的執(zhí)行過程全部是圖形界面，其間并沒有涉及到具體的代碼；而微軟的產(chǎn)品并沒有圖形界面，所有的操作看來就是一個程序員在寫程序一樣，結(jié)果可想而之，速度當(dāng)然比不上IBM而且其復(fù)雜程度也對程序員有很高的要求，即必須知道底層代碼及所有的環(huán)節(jié)才行。
? 不過，我在想，如果微軟也把同一套流程做成了圖形界面，同時添加了代碼自動生成的功能，那么那時候，兩者再比較，結(jié)果會是什么樣呢？
? ps：liuli在用WBI的時候，發(fā)現(xiàn)了不少的bug。

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

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

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

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

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

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

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

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

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

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