2006年6月9日
#
JSP生成中使用了一般會使用表達式語言EL，語法和Freemarker是一致的，都是${...}，在模版中的<c:out value=$${subject.name}>這一類Jsp EL,很多時候這個${…}是不應該被FreeMarker解析的。但是正如
http://michael.nona.name/archives/75?中提到的，FreeMarker中又沒有比較好的轉義方法，我下午我也想了很久，突然想到一個方法，可以這樣：
<c:out value=${'$'}{subject.name}>
即可以完成轉義，解決這個沖突，還是比較好用的
由于yanghuan和shushu考試比較多，晚上我和小曹最終再次review了一下我們的作品，還真是發現了一個小細節的地方不妥，又修改了一下。把所有的word文檔轉成了PDF，相關文件打包成zip文件，通過email發送出去的一剎那，輕松了很多，兩個多月的緊張努力和忙碌，終于可以完美的告一段落了。??????
??????從4月中旬中間件課程上楊歡、澍澍說起IBM的SOA大賽，對此都有興趣的我們，當天去聽IBM的SOA宣講會，立即組織了現在的AccelerateSOA團隊，并邀請我們的中間件老師繞老師作為我們的指導老師，從最初對SOA幾乎僅僅停留在直覺地概念上，每周開一次會討論，然后各自去學習相應的SOA資料，到我們每個人都比較全面的明白了SOA的內在思想、整體架構 并嘆服IBM在架構上的廣博與精妙，并在這將近一個月三兩天開會，經常msn會議討論，email交流，到現在整整兩個多月了。這兩個多月的合作，我們付出了很多，學到了很多，收獲了很多，正如楊歡在我們團隊blog上總結的，不管如何，我們已經成功了！
??????6月26日23：18分，我們的作品正式email提交給了IBM組委會。明天我們應該可以得到IBM的確認吧
??????現在已經陸續考試了，我們比較慶幸，時間安排得還是很合理，在大規模的考試來臨之前，圓滿地完成了我們的預定計劃。接下來的一周，我們都該集中時間準備一下考試了；同時，在空余時間，我們還會繼續SOA的學習和積累，備戰復賽。
??????期待北京之行，五強之爭，期待現實中與我們的SOA友隊，同臺交流、暢談SOA！
在水木bbs上，都在討論服務規約具體指什么，這個我也是很疑惑，看了我們偉大的模版設計師小曹同學的服務模型設計文檔模版，豁然開朗，呵呵。鑒于很多團隊也不明朗，特共享小曹同學的英明發現
中文：?
http://www-128.ibm.com/developerworks/cn/rational/419_soa/原文：
http://www-128.ibm.com/developerworks/rational/library/05/419_soa/上面敘述得很詳細的，尤其是中英文對照，就可以很快理解啦，摘要如下：
用于軟件服務的 UML 2.0 Profile 概述
在IBM Rational Sofware Architect 上實現 profile 的目的是為描述服務提供一個共同語言，該 profile 包括了在開發生命周期內的很多活動并且為不同的涉眾提供了視圖。例如，該 profile 提供為架構師指定服務的能力――在生命周期的早期――使用邏輯劃分來描述整個企業范圍的服務組合。這個視圖再由設計師來細化，設計師開發服務規約說明――結構上的和行為上的――這個服務規約說明擔當服務的客戶和實現者之間契約的作用。消息視圖為設計師對于公共的服務數據定義提供重用信息模型的能力。
藍色字體部分對應的是
This view is further detailed by designers, who develop the service specifications -- both structural and behavioral -- that act as the contracts between the services' clients and implementers.
可見：
?????????服務規約應該是the service specifications ，也就是服務的契約、調用約定，擔當服務的客戶和實現者之間契約的作用，同時服務規約包括結構上的和行為上的，這個我的理解是結構上是指消息的類型，或者在SOA中，應該是SDO部分；行為上，就應該是調用接口了
??????這是我根據上面developerWorks上的理解
今天整理了一下架構設計概要文檔，總算基本上寫好了。天氣實在太熱了，上午出去了一會兒就熱得有些受不了了。不過還好明天據說要降溫。
??????然后看了一下原始的需求，發現我們到現在還有一個服務設計沒有做，前面也一直沒有提到。不過比較疑惑，其中的
l?????? 服務規約
l?????? 服務實現分析
這兩項分別是什么意思呢？
??????期待小曹的服務設計模版，呵呵，有模版可以參照的日子還是很愜意的。
??????終于發現計數器到1000勒，用SnagIt記錄下了這個時刻：
???
呵呵，上午去實驗室的時候，老板說要加強和IBM的合作，我就在想，如果我們最終幸運的進入復賽，那么老板會同意的吧?不管了，先把必要的文檔寫好，過了初賽，到北京玩一圈再說，呵呵
前一段我們因為很多都是通過email群發的方式，來相互傳閱文檔，同時每個文檔由一個負責人來具體控制，我覺得這樣很好，不過我們前面的通過ftp共享的方式，我覺得還是需要堅持，前兩次咱們總是需要文檔的時候，不知道是在具體那封email里面的，就是這個問題。
??????我看到小曹晚上已經建立了一個docs_release目錄了，我們的正式的文檔，就ftp上該目錄下吧。另外，每個人的文檔，還是放在各自的目錄下，同時email附件告知。
ps:這次搶到60了，不過看到我們的訪問次數馬上就要超過1000了。需要注意的是，我們的1000統計是比較精確的，同時沒有計算通過RSS訪問的，僅僅有Web訪問的計數，所以還是挺可喜的。恩，shushu和yanghuan同學，你們多寫寫心得哦
推薦兩篇文章：
介紹 IBM Rational Software Architect http://www-128.ibm.com/developerworks/cn/rational/524_rsa/?
基于RSA實現面向服務的體系架構 http://www-128.ibm.com/developerworks/cn/rational/r-rsa-soa/
我們的組件設計，我看了一下水木上的消息，使用一般的軟件畫出來也可以，要是可能的話，我們也可以考慮使用RSA來畫，或許要好看一些？
晚上又重新看了一下IBM的soa ppt，真的很欣賞一句中國古話了，叫“溫故而知新，可以為師也”，呵呵，每次看看，都有一些不同的收獲。陶潛曾言，“好讀書，不求甚解，每有會意，欣然若狂”，大概也是這種意境吧
WEB1.0是以數據為核心，WEB2.0是以人為出發點的互聯網
WEB2.0中的一些技術：
Blog：?用戶織網，發表新知識，和其他用戶內容鏈接，進而非常自然的組織這些內容。
RSS：?用戶產生內容自動分發，定閱
Podcasting：?個人視頻/聲頻的發布/定閱
SNS：?blog+人和人之間的鏈接
WIKI：?用戶共同建設一個大百科全書
WEB2.0中很多技術是為了使Web更加有序化，相互連接，有機組織起來
從知識生產的角度看，WEB1.0的任務，是將以前沒有放在網上的人類知識，通過商業的力量，放到網上去。WEB2.0的任務是，將這些知識，通過每個用戶的瀏覽求知的力量，協作工作，把知識有機的組織起來，在這個過程中繼續將知識深化，并產生新的思想火花；
從內容產生者角度看，WEB1.0是商業公司為主體把內容往網上搬，而WEB2.0則是以用戶為主，以簡便隨意方式，通過blog/podcasting?方式把新內容往網上搬；
從交互性看，WEB1.0是網站對用戶為主；WEB2.0是以P2P為主。
從技術上看，WEB客戶端化，工作效率越來越高。比如像Ajax技術,?GoogleMAP/Gmail里面用得出神入化。
摘自
http://blog.sina.com.cn/u/4951ae02010003ug
昨天收到的快件，一上午就去拿了，呵呵，原來又是一個光盤，這次包括了一個TurboCRM的實施方案，還有就是一些用友ERP的資料，好像這個和上次的一樣，奇怪。
??????仔細看了一下，TurboCRM的資料還是非常有用的，這次是完整的敘述了一個他們公司的一個案例，我覺得這個應該對我們的設計和架構影響比較大的吧，好好看看再說，正好晚上開會可以討論一下
??????仔細看了一下，比較可喜的發現，原來TurboCRM軟件是支持B/S模式的啊，原來一直以為不能支持的呢，呵呵。該文章詳細的介紹了CRM要解決的問題，以及相應的解決方案，然后就是TurboCRM的一些數據資料的結構和構成，仔細看了倒是發現原來很多理解上的不深入。
??????具體的資料，放在我們的ftp目錄SOA學習資料\用友&TurboCRM下了，大家抓緊時間看看，晚上我們看看可以根據這個把設計做什么改進。
我們已經忙碌了一個多月，現在就到最后的沖刺了，我們再加油一把，就可以到北京休息啦！
今天忙碌了一下，把部署視圖寫好了。前面大家一直討論的架構設計的事情，現在經過幾輪email討論，我想我們現在也該是基本上意見統一了，就看明天的組件設計，再把這個寫好，我們就可以來一個Review了。
下午收到了IBM寄過來的又一個快件，還沒有去看，不過比較好玩的是，這次的收件人是我們的隊名AccelerateSOA啦，明天去看看再說，好好奇的呢
加油，Accelerate！
摘要: 用友NC系統中外部數據交換平臺的簡單原理敘述，同時針對我們的soa大賽，做了一些介紹
閱讀全文
BlueDavy的
關于Plugin Framework的關鍵因素 提到了幾點
1、?? Plugin的編寫?
?????????一個好的Plugin System對Plugin沒有任何編碼上的要求，要求的只是其描述文件的編寫
2、?? Plugin的部署?
?????????如何更加方便的去部署一個Plugin，考慮中根據配置從相應的目錄或網站搜索Plugin并注冊到系統中
3、?? Plugin的調用?
?????????根據Plugin的描述采取相應的方式調用Plugin，例如webservice方式、socket方式等等
4、?? Plugin的交互?
?????????也許可以參考Maven的方式，比如需要調用其他的plugin，則采用類似這樣的配置或調用<attain plugin=”pluginname” function=”sendmail”/>抑或采用IoC容器注入依賴？？
5、?? Plugin的擴展?
?????????對于Plugin的擴展，這個Eclipse的擴展點完全值得參考
6、?? Plugin的依賴關系的分析?????????
?????????這是我構思中的一個東西，希望系統所有的模塊都基于此Plugin Framework，然后我們可以根據這些模塊Plugin來分析整個系統中各模塊的依賴關系等等，并進行監控，甚至在將來可以圖形化的進行配置，圖形化搭積木式的搭建自己的系統，^_^
我發現，這個插件體系結構，和SOA中的SCA體系結構，還有Spring中的Beans工廠，有很多相似之處的，如下：
1.???SCA的編寫：
?????????需要繼承SCA的接口。不過，我倒是更加喜歡spring的方式，使用bean來配置一套系統，對每個bean沒有編碼限制
2.???SCA的部署
?????????使用scdl.xml進行部署描述。如果scdl.xml存在于網絡中，是否能部署成功這個倒是不清楚。spring中直接使用xml描述，主要是各個Beans的配置
3.???SCA的調用
?????????使用binding進行組合調用，現在支持的有SCA Binding、WebService Binding等等。spring中使用屬性注入和構造器注入
4.???SCA的交互
??????使用import/export來暴露具體的接口，然后進行調用。直接使用IOC，注入依賴，相互交互是依靠使用預定義接口，實現契約。
5.???SCA的擴展
??????可以使用繼承來修改原來的模塊，并在運行時通過替換SCA模塊達到目的。Plugin的擴展點（Extension Point）的概念到時值得仔細考慮，非常靈活的。Spring中，通過修改配置文件，使用不同的beans來擴展原有系統。
6、?SCA的依賴關系
??????好像現在ESB中還沒有Service Register的實現，其實，分析SCA的配置文件，是可以找到這些依賴的。本來就是一個總線結構的啊。spring中beans工廠的配置文件現在倒是有很多基于eclipse的實現。
??????先寫這幾條，這幾天在仔細研究這些技術
由于參加soa比賽，才采用了WBM作為商業建模工具，真正見識了IBM的軟件有多么的不好用，聯想到以前使用微軟軟件的舒適經歷，突然明白了一點，這就是ibm整個軟件思路上的一個特點，好象IBM從來就沒有把軟件的易用性放到開發計劃的重要事項中去，從我上大三學習數據庫，使用DB2，我就有這種很深的印象了，就是IBM的軟件比較大和難于使用，一如它歷史上所推崇的大型機。
??????微軟公司的所有軟件，在開發的過程中，都有易用性測試和用戶反饋，效果也是非常明顯的，也因此建立起了今日的微軟帝國。同時，再看看google，令人稱頌的也是他的簡潔和高效。這些例子都說明，在我們今天的軟件開發中，用戶的需求和易用性是需要特別值得重視的，恰恰這種我們普通用戶都可以體會到的好壞，IBM沒有重視，也許還是在抱著它當年的大型機之夢在沾沾自喜吧，歷史將證明一切！！
??????今天發本文主要是實在被IBM的軟件氣死了，由于WBM的cvs協作設計有問題，我們不能使用cvs進行團隊開發，只能每個人都在自己的電腦上處理各自的部分。恰恰是這樣，讓我發現了WBM的又一個明顯的問題，那就是使用WBM的import來合并不同的開發結果的時候，超級難用，而且容易出錯。已經有無數次這種合并把我辛辛苦苦的成果覆蓋了，今天又一次出現這種事情，實在讓我氣憤難當，我不知道IBM到底使用過WBM來做一個完成得商業建模沒有，如果有，那這種顯而易見的問題早該發現了！！
??????想想一個導入合并其實很容易做到很人性化，比如微軟的word，合并文檔功能就設計的很好，很智能友好；同時，sybase的PowerDesigner的合并也是，使用圖形化的方式，一目了然；其實就是eclipse里面的cvs差異，也是顯示的很好的嘛，為什么事情一牽涉到IBM，味道就變了呢？
??????想到了以前看SharpDevelop的開發日記，決策使用SharpDevelop來進行SharpDevelop開發；在Eclipse的開發中，也使用到了這種思想。當你真正來使用的時候，很多問題是顯而易見的。
??????IBM真是想說愛你不容易啊，強烈建議IBM以后的軟件設計中更加重視易用性，重視用戶體驗，這樣才可以更好的發展