今天繼續去參加了BEA開發者大會的第二天的會議，在上篇blog中有朋友留言說大會還不錯，但人比較多 ，外邊有點擁擠不堪，確實這次BEA大會參加的人比較多，今天從戴的胸卡上可以看到又有很多的學生朋友參加，但其實會議期間組織的還不錯，也不顯得擁擠，當然午餐的時候是可以說特別的擁擠了，兩個自助用餐的地方人擠人的，這也沒辦法，吃飯嘛，當然積極性都很高啦，呵呵。
好了，言歸正轉，說說技術方面的東西吧。我在昨天的blog的末尾提到了一個問題，就是我們在採用SOA架構進行系統的整合時，對於數據處理，業務邏輯我們都可以提煉出service來整合重用，那我們如何做到各個portal系統的web page的整合，今天一去，我當然第一個就去問這個問題，結果答案和我昨天的想法很相似，就是我們要想把一個portal的page拿到另一個系統上去，這些系統中的pages都不是普通的jsp,aspx或html(當然前兩者都是轉成html，讓瀏覽器去解析），都是比較特殊的頁面,例如weblogic protal 9.2要做到門戶聯合的話頁面要符合WSRP標準，雖然現在我不懂WSRP標準，但可以想象它肯定是一些對頁面的顯示的限制，比如標籤應該怎麼用等等這樣的，所以我們纔可以把頁面或頁面的一部分當成是一個component,來進行整合和重用，我感覺這個思想和velocity的思想很相似，都是把頁面組件化，來達到重用，只不過velocity一般用在單個系統的view中，而前者可以用在不同portal的view的整合。
對於SOA的架構，它除了能夠把各種不同技術的業務邏輯實現封裝成service ，來實現鬆散耦合外，對於這些services的調用者Client端而言，我們採用ESB，可以讓用戶不在去調用具體的某個service的實現，這樣就可以屏蔽掉Client端對某個具體service以及該service的某種具體實現技術的依賴，說白話點就是Client不用硬編碼去調用RPC 或是EJB或是web service，它是去訪問ESB，即使ESB提供的某個service的實現技術變l了，但Client端卻不用變化。這是採用ESB的一個好處（當然這些都是對比較大型的應用來說 ）。但在這裏我又產生了一個問題，就是這樣的話我的client會不會和你具體的ESB產品綁定起來，換句話說我要是在系統中換個ESB的實現產品，那我的客戶端的代碼要不要改變了?
這個問題我後來跟BEA的人交流了一下，自己也想了想，其實是不會的。因爲client去訪問ESB提供的一個接口，現在大多ESB都對某一個服務流提供一個專門的，它自己的web service做爲client調用的入口，那這個web service的定義和調用形式，包括參數傳遞的形式，都可以是我們自己定義的，並不是ESB產品預先定義好的，所以這樣的話客戶端的調用應該不會和某種ESB產品邦定起來。
現在的SOA中我感覺最難的實際上是對系統，對業務中服務的定義和提取，就是什麼需求我來封裝成一個服務，我感覺這方面確實是不好說，至少我目前是沒有什麼經驗，那反過來對於服務，我們又可以細分，分爲數據服務（專門和數據存儲之類交互的）和業務邏輯服務，相應的BEA有DSP,信息總線；ESB，服務總線；當然我們可以不用分這麼細，就形成一個層次的服務也是可以的。
另外BEA在今年的大會中還有個real-time java的概念，咋聽起來比較新穎，其實這就是基於BEA公司開發的一個JVM－－JRocket，可能它在性能方面較其它的JVM的實現要好一些吧，所以叫"real_time java"。
另外還有一個比較有意思的是虛擬化java應用，實際上就是虛擬一個JVM，也就是說我們在一個啓動的JVM上跑着程序了，這時候我能在另一臺機器上clone一個現在跑着的JVM和其中的程序，讓這個clone在另一臺機器上跑起來，相當於有兩個JVM在跑，只是這兩個JVM在剛開始跑得狀態完成一樣。
本次BEA大會還有一些比較好玩的東西，但總的主題是SOA，所以這兩天這方面的知識還是長了不少，在這非常感謝BEA舉辦這次的活動，當然也希望能有更多的公司在中國舉辦這樣的活動，這中間有中國的公司就更好了，到時候一定去捧場，不過希望在午餐時記得多提供幾個用餐的地點，哈哈！