兩個(gè)半小時(shí)之后，我和BlueDavy大叔回到了杭州，一個(gè)忙碌而充實(shí)的周末就這么過(guò)去了。回到家已經(jīng)1點(diǎn)多了，洗了個(gè)澡，精神又來(lái)了，想把這個(gè)充實(shí)的周末寫下來(lái)，做個(gè)紀(jì)念。

緣起

       幾周前，受到了普元的邀請(qǐng)，去三亞參加一個(gè)SOA的技術(shù)交流會(huì)，原本以為是因?yàn)樵谒麄兊恼搲瑫r(shí)更新了一些文章所以被邀請(qǐng)一起去參加產(chǎn)品部活動(dòng)，開始不是很想去，畢竟廠商出錢多半就是讓你去聽聽他們的產(chǎn)品，一個(gè)周末飛來(lái)飛去的也累，但淘寶的BlueDavy大叔要去，順便也叫我一起去熱鬧熱鬧，那么就決定去湊這個(gè)熱鬧。周五下班以后背了個(gè)包就直奔機(jī)場(chǎng)了，結(jié)果到了機(jī)場(chǎng)才發(fā)現(xiàn)辦護(hù)照的時(shí)候身份證放在家里了，幸好機(jī)場(chǎng)還有個(gè)臨時(shí)身份證明辦理的便民業(yè)務(wù)，總算順利的上了飛機(jī)。

人物

       第一天到場(chǎng)，第一個(gè)環(huán)節(jié)就是自我介紹，江湖中人就悉數(shù)登場(chǎng)了。Robbin,白衣，俞黎敏，小剛，楊戈，InfoQ中文站的主編霍泰穩(wěn)和其他幾個(gè)編輯，灰狐的主創(chuàng)：銀狐999，程勇，普元的老大Chris以及普元的很多技術(shù)架構(gòu)師牛人。陳勇的一句話就把我們這批人概括了一下，其實(shí)大家都是江湖中人，平時(shí)混各個(gè)堂口的，今天在普元召集的這么一次活動(dòng)，有機(jī)會(huì)能夠匯聚一起，談天說(shuō)地。

活動(dòng)

       第一天上午有兩個(gè)Topic關(guān)于SOA的市場(chǎng)價(jià)值，下午也有兩個(gè)Topic關(guān)于SOA的企業(yè)架構(gòu)，主講的都是我們這些外部請(qǐng)來(lái)的人。上午下午有很多時(shí)間是自由討論，每個(gè)人都有機(jī)會(huì)發(fā)表自己的意見，應(yīng)該是算圓桌會(huì)議，所以你要發(fā)言隨時(shí)隨地都可以直接說(shuō)，不需要顧忌什么，只要覺得要說(shuō)，該說(shuō)，就能說(shuō)。這一天碰撞出不少火花。晚上邊吃燒烤邊聊，后面去沙灘上繼續(xù)討論技術(shù)圈的構(gòu)建（不過(guò)這個(gè)到了最后也沒有一個(gè)很好的解決方案）。

       第二天主要是普元分享了他們對(duì)于SOA技術(shù)的理解和具體的實(shí)現(xiàn)，從實(shí)際角度去展示了一個(gè)SOA的實(shí)實(shí)在在的成果。

收獲

       其實(shí)這部分才是我要寫得重點(diǎn)。一部分一部分來(lái)說(shuō)吧。

首先是識(shí)人，這次在會(huì)上看到了很多都是自己曾經(jīng)蠻佩服的國(guó)內(nèi)開源技術(shù)論壇或者社區(qū)的創(chuàng)辦者，其實(shí)從他們身上除了看到技術(shù)人員本身所特有的對(duì)于技術(shù)的追求更多的是對(duì)于新事物的理性的學(xué)習(xí)和分析。其實(shí)我一直覺得有一點(diǎn)對(duì)于一個(gè)架構(gòu)師或者一個(gè)優(yōu)秀的開發(fā)人員來(lái)說(shuō)很重要的特質(zhì)就是開放的去學(xué)習(xí)和接受新事物，有一個(gè)包容的心態(tài)去看待每一個(gè)陌生的新生事物，那么才能不斷地進(jìn)步。而排斥和固步自封，只能最后束縛了自己的腳步，慢慢的落后與他人。SOA這個(gè)概念提出來(lái)很多年了，炒作到實(shí)質(zhì)性的轉(zhuǎn)變也就在這一兩年，具體的實(shí)踐還需要后面幾年的實(shí)施和驗(yàn)證。所以到場(chǎng)的每一位沒有一個(gè)敢說(shuō)自己完全了解SOA是什么，絕大部分都是抱著希望了解SOA實(shí)際上究竟是什么的想法而來(lái)。在討論的過(guò)程中大家就很直白的說(shuō)出了SOA是否還是一個(gè)虛概念，過(guò)去的EAI,BPM以及現(xiàn)在的EBI的區(qū)別。沒有絕對(duì)的否定，只有探討，學(xué)習(xí)和交流。我是第一認(rèn)識(shí)他們，而他們之間已經(jīng)相互很熟悉，但是和他們交流并不存在任何障礙，沒有說(shuō)牛人就是一個(gè)圈子，基本很難接觸的那種感覺。我想也正是一種Open的心態(tài)才能讓人進(jìn)步得更快。

再則談?wù)劷佑|普元的朋友。和普元的朋友交流的機(jī)會(huì)不算很多，不過(guò)在第一天的休息的時(shí)候和幾個(gè)主要的技術(shù)人員作了交流。因?yàn)槠鋵?shí)我做SCA也還算比較早，所以對(duì)于SCA還是比較熟悉的，同時(shí)普元又是SCA中國(guó)區(qū)的推廣者，所以和他們的架構(gòu)師交流SCA很容易，不像在單位里面基本就是寫好使用文檔給開發(fā)者看，如果要談具體的原理，基本沒有人看過(guò)SCA規(guī)范，我是在SCA0.96版本上作了穩(wěn)定版本的，現(xiàn)在解析使用Tuscany，再次組裝是自己做的，一來(lái)早期的Tuscany對(duì)于兩個(gè)級(jí)別的Service和Reference沒有做級(jí)別控制，二來(lái)包括WS模塊以及其他模塊有很多的Bug，所以作了再次的開發(fā)和封裝以適應(yīng)業(yè)務(wù)開發(fā)的需求，其實(shí)在我們的研討會(huì)上也說(shuō)了，開源的缺點(diǎn)就是不穩(wěn)定，不一定適應(yīng)商業(yè)開發(fā)，如果商業(yè)開發(fā)的話，一般是需要穩(wěn)定在某一個(gè)版本上。同時(shí)由于SCA本身的模塊化特點(diǎn)，所以部分升級(jí)和開發(fā)十分方便。這些思想和概念以及遇到的問(wèn)題和普元的開發(fā)團(tuán)隊(duì)遇到的一些問(wèn)題都十分相似，特別是在WS上面，我一度也應(yīng)為搞不定某些特殊的類型想去使用SDO，不過(guò)最后還是直接修復(fù)SCA的WS組件搞定了，也就沒有使用SDO。不過(guò)第二天的普元的服務(wù)管理和監(jiān)控讓我還是眼前一亮，這個(gè)對(duì)我來(lái)說(shuō)可能也是后續(xù)在服務(wù)框架中需要考慮和搭建的，因?yàn)槿绻扇?/span>Service API Mashup Platform,那么這部分內(nèi)容勢(shì)必是必須的。同時(shí)，普元的很多高手都是SCA組織的成員，這也是我蠻羨慕的，有機(jī)會(huì)還是要和他們多多學(xué)習(xí)和交流，雖然后續(xù)我的工作重點(diǎn)不是在SCA上了，不過(guò)ASF的工作以及SCA的持續(xù)學(xué)習(xí)也是自己“私活”之一?？偟母杏X來(lái)說(shuō)，普元的技術(shù)人員雖然話不多，但是內(nèi)功深厚，有很多可以去學(xué)習(xí)和切磋的。

最后就是關(guān)于SOA的一些感觸。第二天中午最后一點(diǎn)時(shí)間是給大家講關(guān)于這一天半的討論和交流以后對(duì)于SOA的收獲，由于時(shí)間關(guān)系，到我們的時(shí)候大家盡量簡(jiǎn)短發(fā)言，我也就說(shuō)了自己的兩點(diǎn)想法：1．先學(xué)在干在學(xué)在干。2．開發(fā)人員是我們的客戶，不要讓我們的客戶因?yàn)槭褂梦覀兊漠a(chǎn)品而痛苦不堪，應(yīng)該讓我們的客戶在使用了產(chǎn)品以后提高了生產(chǎn)效率。第一點(diǎn)什么意思呢？在我做服務(wù)框架以前，先去研究過(guò)OSGI，然后又接觸了SOA，最后接觸到了SCA。花了1個(gè)多禮拜把SCA規(guī)范啃了幾遍以后，找到了使用SCA實(shí)現(xiàn)服務(wù)框架的優(yōu)勢(shì)以后，就開始搞服務(wù)框架了，看了Tuscany的源碼與設(shè)計(jì)思想，做了修改和封裝，第一階段的SCA服務(wù)框架就這么出來(lái)了。曾一度寫了關(guān)于SCA如何讓SOA落地的一些感想文章，但是后來(lái)自己都開始有些迷惑，究竟SOA是什么，僅僅就是用SCA去實(shí)現(xiàn)WS來(lái)互聯(lián)互通么？這時(shí)候去看了很多關(guān)于SCA和SOA的資料和文章，突然發(fā)現(xiàn)又陷入到了一個(gè)開發(fā)者的角度去審視SOA的陷阱。很多人說(shuō)SOA只是一種概念，沒錯(cuò)，其實(shí)就是概念，那么這個(gè)概念有什么價(jià)值？其實(shí)這就是一個(gè)思考的過(guò)程。參加了BEA2007大會(huì)，雖然沒有實(shí)質(zhì)性的一些Topic讓我有所收獲，但是在主題演講的時(shí)候讓我突然開了竅。其實(shí)任何技術(shù)都是有延續(xù)性的EAI和SOA有什么區(qū)別，可能很快有人站出來(lái)給你一大堆的技術(shù)變革，告訴你區(qū)別大了去了，但其實(shí)SOA的真正價(jià)值不是在于說(shuō)和過(guò)去的技術(shù)有什么區(qū)別，而是它的一種開放，協(xié)同的思想，這種思想其實(shí)更具各個(gè)行業(yè)來(lái)說(shuō)都是不同的。這次去普元的交流會(huì)上，很明顯的可以看出普元是定位在企業(yè)級(jí)應(yīng)用的開放協(xié)同角度去考慮SOA的價(jià)值以及解決方案和實(shí)現(xiàn)手段。而我從大會(huì)回來(lái)，從新考慮了在阿里軟件SAAS平臺(tái)模式下我所關(guān)注的SOA的價(jià)值以及解決方案，就好比現(xiàn)在我一直在考慮的Service Mashup Platform，這是基于互聯(lián)網(wǎng)應(yīng)用的一種角度的思考。同樣不同行業(yè)的人可能都會(huì)有不同的一種思考，但都是基于SOA的一種開放，協(xié)同的思想來(lái)更具具體的使用場(chǎng)景來(lái)考慮。所以如果你拋開業(yè)務(wù)場(chǎng)景去空想SOA，那么結(jié)果就會(huì)讓自己陷入技術(shù)陷阱，用技術(shù)的不同來(lái)生硬的解釋SOA，這種就好比過(guò)去講的笑話，盲人摸象。第二點(diǎn)是我自己在推廣我的ASF的一點(diǎn)經(jīng)驗(yàn)，在普元演示產(chǎn)品的時(shí)候看到了他們的studio作的很好，但是對(duì)于單元測(cè)試以及部分組件的集成測(cè)試卻做得還不是很夠，同時(shí)studio是否能夠讓程序員有便利感（我們很多在場(chǎng)的寫慣了程序的人都覺得程序員不寫幾行代碼，就會(huì)沒有創(chuàng)造感），這些可能會(huì)影響客戶（開發(fā)人員）。其實(shí)在我推廣ASF的時(shí)候有很多的架構(gòu)師都反對(duì)，頂著壓力死推，最后救了我的是那些開發(fā)人員，一份匿名使用反饋加上性能測(cè)試，功能測(cè)試，最終還是堅(jiān)持了下來(lái)，并被逐步接受。那么對(duì)我來(lái)說(shuō)我能夠繼續(xù)做好的就是加強(qiáng)文檔的豐富性，測(cè)試的簡(jiǎn)單性，部屬的方便性，以及開發(fā)配置的簡(jiǎn)便性（由于很多是配置型的文件，因此采用schema來(lái)做提示和交驗(yàn)我就覺得夠了，至于studio是否需要，如果能夠做得很完美當(dāng)然最好了）。

最后其實(shí)對(duì)于這次活動(dòng)來(lái)說(shuō)其實(shí)我覺得就是一次技術(shù)人員的SOA，不同的公司，不同的職業(yè)，不同的職位，協(xié)同，開放的在一起發(fā)表自己的意見來(lái)互相學(xué)習(xí)和交流，本來(lái)也就是一種SOA。這兒感謝一下普元，活動(dòng)本身來(lái)說(shuō)雖然沒有對(duì)SOA做出很明確的定義，但是其實(shí)讓每一個(gè)人能夠去思考，其實(shí)問(wèn)題只有一個(gè)答案卻可以有千千萬(wàn)萬(wàn)，每個(gè)人的角度不同看到的就有不同的內(nèi)涵。就好比InfoQ主編說(shuō)的每一個(gè)海灘上的沙子都有自己一個(gè)唯一標(biāo)識(shí)，我們每一個(gè)江湖人士都有自己一個(gè)堂口，一個(gè)觀點(diǎn)一個(gè)看法。

開放的心態(tài)去學(xué)習(xí)和交流，我要走路還有很長(zhǎng)一段。

花絮：

       白衣不小心摔了一跤，眼鏡掉到海里了，我們說(shuō)是觀音大士讓他把眼鏡作為紀(jì)念留在了海南。

       畢玄同學(xué)在上岸之前換鞋子的時(shí)候，由于不買一個(gè)小MM的貝殼，被小MM一直稱作大叔，因此我們笑說(shuō)畢玄就是到了大叔的年紀(jì)了。

歡迎訪問(wèn)我的blog：http://blog.csdn.net/cenwenchu79/
msn:cenwenchu_1979@hotmail.com

       在SOA的基礎(chǔ)技術(shù)實(shí)現(xiàn)方式中WebService占據(jù)了很重要的地位，通常我們提到WebService第一想法就是SOAP消息在各種傳輸協(xié)議上交互。近幾年REST的思想伴隨著SOA逐漸被大家接受，同時(shí)各大網(wǎng)站不斷開放API提供給開發(fā)者，也激起了REST風(fēng)格WebService的熱潮。

       在收到新需求Email之前，我對(duì)REST的理解僅僅是通過(guò)半懂不懂的看了Fielding的REST博士論文，說(shuō)實(shí)話當(dāng)時(shí)也就是希望了解這么一個(gè)新概念，對(duì)于其內(nèi)部的思想只是很膚淺的了解了一下。

       ASF的最新需求就是可能需要實(shí)現(xiàn)REST風(fēng)格的WebService集成，因此不得不好好的去看看REST的真正思想含義以及當(dāng)前各大網(wǎng)站的設(shè)計(jì)方式。后面所要表述的也是我這個(gè)初學(xué)者的一些看法和觀點(diǎn)，拋磚引玉，希望在我將REST融入到ASF之前能夠獲得更多的反饋和意見。

SOAP

       什么是SOAP，我想不用多說(shuō)，google一把滿眼都是。其實(shí)SOAP最早是針對(duì)RPC的一種解決方案，簡(jiǎn)單對(duì)象訪問(wèn)協(xié)議，很輕量，同時(shí)作為應(yīng)用協(xié)議可以基于多種傳輸協(xié)議來(lái)傳遞消息（Http,SMTP等）。但是隨著SOAP作為WebService的廣泛應(yīng)用，不斷地增加附加的內(nèi)容，使得現(xiàn)在開發(fā)人員覺得SOAP很重，使用門檻很高。在SOAP后續(xù)的發(fā)展過(guò)程中，WS-*一系列協(xié)議的制定，增加了SOAP的成熟度，也給SOAP增加了負(fù)擔(dān)。

REST

       REST其實(shí)并不是什么協(xié)議也不是什么標(biāo)準(zhǔn)，而是將Http協(xié)議的設(shè)計(jì)初衷作了詮釋，在Http協(xié)議被廣泛利用的今天，越來(lái)越多的是將其作為傳輸協(xié)議，而非原先設(shè)計(jì)者所考慮的應(yīng)用協(xié)議。SOAP類型的WebService就是最好的例子，SOAP消息完全就是將Http協(xié)議作為消息承載，以至于對(duì)于Http協(xié)議中的各種參數(shù)（例如編碼，錯(cuò)誤碼等）都置之不顧。其實(shí)，最輕量級(jí)的應(yīng)用協(xié)議就是Http協(xié)議。Http協(xié)議所抽象的get,post,put,delete就好比數(shù)據(jù)庫(kù)中最基本的增刪改查，而互聯(lián)網(wǎng)上的各種資源就好比數(shù)據(jù)庫(kù)中的記錄（可能這么比喻不是很好），對(duì)于各種資源的操作最后總是能抽象成為這四種基本操作，在定義了定位資源的規(guī)則以后，對(duì)于資源的操作通過(guò)標(biāo)準(zhǔn)的Http協(xié)議就可以實(shí)現(xiàn)，開發(fā)者也會(huì)受益于這種輕量級(jí)的協(xié)議。

       自己理解的將REST的思想歸結(jié)以下有如下幾個(gè)關(guān)鍵點(diǎn)：

1．面向資源的接口設(shè)計(jì)

所有的接口設(shè)計(jì)都是針對(duì)資源來(lái)設(shè)計(jì)的，也就很類似于我們的面向?qū)ο蠛兔嫦蜻^(guò)程的設(shè)計(jì)區(qū)別，只不過(guò)現(xiàn)在將網(wǎng)絡(luò)上的操作實(shí)體都作為資源來(lái)看待，同時(shí)URI的設(shè)計(jì)也是體現(xiàn)了對(duì)于資源的定位設(shè)計(jì)。后面會(huì)提到有一些網(wǎng)站的API設(shè)計(jì)說(shuō)是REST設(shè)計(jì)，其實(shí)是RPC-REST的混合體，并非是REST的思想。

       2．抽象操作為基礎(chǔ)的CRUD

       這點(diǎn)很簡(jiǎn)單，Http中的get,put,post,delete分別對(duì)應(yīng)了read,update,create,delete四種操作，如果僅僅是作為對(duì)于資源的操作，抽象成為這四種已經(jīng)足夠了，但是對(duì)于現(xiàn)在的一些復(fù)雜的業(yè)務(wù)服務(wù)接口設(shè)計(jì)，可能這樣的抽象未必能夠滿足。其實(shí)這也在后面的幾個(gè)網(wǎng)站的API設(shè)計(jì)中暴露了這樣的問(wèn)題，如果要完全按照REST的思想來(lái)設(shè)計(jì)，那么適用的環(huán)境將會(huì)有限制，而非放之四海皆準(zhǔn)的。      

       3．Http是應(yīng)用協(xié)議而非傳輸協(xié)議

       這點(diǎn)在后面各大網(wǎng)站的API分析中有很明顯的體現(xiàn)，其實(shí)有些網(wǎng)站已經(jīng)走到了SOAP的老路上，說(shuō)是REST的理念設(shè)計(jì)，其實(shí)是作了一套私有的SOAP協(xié)議，因此稱之為REST風(fēng)格的自定義SOAP協(xié)議。

4．無(wú)狀態(tài)，自包含

這點(diǎn)其實(shí)不僅僅是對(duì)于REST來(lái)說(shuō)的，作為接口設(shè)計(jì)都需要能夠做到這點(diǎn)，也是作為可擴(kuò)展和高效性的最基本的保證，就算是使用SOAP的WebService也是一樣。

REST vs SOAP

成熟度：

SOAP雖然發(fā)展到現(xiàn)在已經(jīng)脫離了初衷，但是對(duì)于異構(gòu)環(huán)境服務(wù)發(fā)布和調(diào)用，以及廠商的支持都已經(jīng)達(dá)到了較為成熟的情況。不同平臺(tái)，開發(fā)語(yǔ)言之間通過(guò)SOAP來(lái)交互的web service都能夠較好的互通（在部分復(fù)雜和特殊的參數(shù)和返回對(duì)象解析上，協(xié)議沒有作很細(xì)致的規(guī)定，導(dǎo)致還是需要作部分修正）

REST國(guó)外很多大網(wǎng)站都發(fā)布了自己的開發(fā)API，很多都提供了SOAP和REST兩種Web Service，根據(jù)調(diào)查部分網(wǎng)站的REST風(fēng)格的使用情況要高于SOAP。但是由于REST只是一種基于Http協(xié)議實(shí)現(xiàn)資源操作的思想，因此各個(gè)網(wǎng)站的REST實(shí)現(xiàn)都自有一套，在后面會(huì)講訴各個(gè)大網(wǎng)站的REST API的風(fēng)格。也正是因?yàn)檫@種各自實(shí)現(xiàn)的情況，在性能和可用性上會(huì)大大高于SOAP發(fā)布的web service，但統(tǒng)一通用方面遠(yuǎn)遠(yuǎn)不及SOAP。由于這些大網(wǎng)站的SP往往專注于此網(wǎng)站的API開發(fā)，因此通用性要求不高。

ASF上考慮發(fā)布REST風(fēng)格的Web Service，可以參考幾大網(wǎng)站的設(shè)計(jì)（兄弟公司的方案就是參考了類似于flickr的設(shè)計(jì)模式），但是由于沒有類似于SOAP的權(quán)威性協(xié)議作為規(guī)范，REST實(shí)現(xiàn)的各種協(xié)議僅僅只能算是私有協(xié)議，當(dāng)然需要遵循REST的思想，但是這樣細(xì)節(jié)方面有太多沒有約束的地方。REST日后的發(fā)展所走向規(guī)范也會(huì)直接影響到這部分的設(shè)計(jì)是否能夠有很好的生命力。

總的來(lái)說(shuō)SOAP在成熟度上優(yōu)于REST。

效率和易用性：

       SOAP協(xié)議對(duì)于消息體和消息頭都有定義，同時(shí)消息頭的可擴(kuò)展性為各種互聯(lián)網(wǎng)的標(biāo)準(zhǔn)提供了擴(kuò)展的基礎(chǔ)，WS-*系列就是較為成功的規(guī)范。但是也由于SOAP由于各種需求不斷擴(kuò)充其本身協(xié)議的內(nèi)容，導(dǎo)致在SOAP處理方面的性能有所下降。同時(shí)在易用性方面以及學(xué)習(xí)成本上也有所增加。

       REST被人們的重視，其實(shí)很大一方面也是因?yàn)槠涓咝б约昂?jiǎn)潔易用的特性。這種高效一方面源于其面向資源接口設(shè)計(jì)以及操作抽象簡(jiǎn)化了開發(fā)者的不良設(shè)計(jì)，同時(shí)也最大限度的利用了Http最初的應(yīng)用協(xié)議設(shè)計(jì)理念。同時(shí)，在我看來(lái)REST還有一個(gè)很吸引開發(fā)者的就是能夠很好的融合當(dāng)前Web2.0的很多前端技術(shù)來(lái)提高開發(fā)效率。例如很多大型網(wǎng)站開放的REST風(fēng)格的API都會(huì)有多種返回形式，除了傳統(tǒng)的xml作為數(shù)據(jù)承載，還有（JSON,RSS,ATOM）等形式，這對(duì)很多網(wǎng)站前端開發(fā)人員來(lái)說(shuō)就能夠很好的mashup各種資源信息。

       因此在效率和易用性上來(lái)說(shuō)，REST更勝一籌。

安全性：

       這點(diǎn)其實(shí)可以放入到成熟度中，不過(guò)在當(dāng)前的互聯(lián)網(wǎng)應(yīng)用和平臺(tái)開發(fā)設(shè)計(jì)過(guò)程中，安全已經(jīng)被提到了很高的高度，特別是作為外部接口給第三方調(diào)用，安全性可能會(huì)高過(guò)業(yè)務(wù)邏輯本身。

       SOAP在安全方面是通過(guò)使用XML-Security和XML-Signature兩個(gè)規(guī)范組成了WS-Security來(lái)實(shí)現(xiàn)安全控制的，當(dāng)前已經(jīng)得到了各個(gè)廠商的支持，.net ，php ，java 都已經(jīng)對(duì)其有了很好的支持（雖然在一些細(xì)節(jié)上還是有不兼容的問(wèn)題，但是互通基本上是可以的）。

       REST沒有任何規(guī)范對(duì)于安全方面作說(shuō)明，同時(shí)現(xiàn)在開放REST風(fēng)格API的網(wǎng)站主要分成兩種，一種是自定義了安全信息封裝在消息中（其實(shí)這和SOAP沒有什么區(qū)別），另外一種就是靠硬件SSL來(lái)保障,但是這只能夠保證點(diǎn)到點(diǎn)的安全，如果是需要多點(diǎn)傳輸?shù)脑?/span>SSL就無(wú)能為力了。安全這塊其實(shí)也是一個(gè)很大的問(wèn)題，今年在BEA峰會(huì)上看到有演示采用SAML2實(shí)現(xiàn)的網(wǎng)站間SSO，其實(shí)是直接采用了XML-Security和XML-Signature，效率看起來(lái)也不是很高。未來(lái)REST規(guī)范化和通用化過(guò)程中的安全是否也會(huì)采用這兩種規(guī)范，是未知的，但是加入的越多，REST失去它高效性的優(yōu)勢(shì)越多。

應(yīng)用設(shè)計(jì)與改造：

       我們的系統(tǒng)要么就是已經(jīng)有了那些需要被發(fā)布出去的服務(wù)，要么就是剛剛設(shè)計(jì)好的服務(wù)，但是開發(fā)人員的傳統(tǒng)設(shè)計(jì)思想讓REST的形式被接受還需要一點(diǎn)時(shí)間。同時(shí)在資源型數(shù)據(jù)服務(wù)接口設(shè)計(jì)上來(lái)說(shuō)按照REST的思想來(lái)設(shè)計(jì)相對(duì)來(lái)說(shuō)要容易一些，而對(duì)于一些復(fù)雜的服務(wù)接口來(lái)說(shuō)，可能強(qiáng)要去按照REST的風(fēng)格來(lái)設(shè)計(jì)會(huì)有些牽強(qiáng)。這一點(diǎn)其實(shí)可以看看各大網(wǎng)站的接口就可以知道，很多網(wǎng)站還要傳入function的名稱作為參數(shù)，這就明顯已經(jīng)違背了REST本身的設(shè)計(jì)思路。

       而SOAP本身就是面向RPC來(lái)設(shè)計(jì)的，開發(fā)人員十分容易接受，所以不存在什么適應(yīng)的過(guò)程。

總的來(lái)說(shuō)，其實(shí)還是一個(gè)老觀念，適合的才是最好的

       技術(shù)沒有好壞，只有是不是合適，一種好的技術(shù)和思想被誤用了，那么就會(huì)得到反效果。REST和SOAP各自都有自己的優(yōu)點(diǎn)，同時(shí)如果在一些場(chǎng)景下如果去改造REST，其實(shí)就會(huì)走向SOAP（例如安全）。

       REST對(duì)于資源型服務(wù)接口來(lái)說(shuō)很合適，同時(shí)特別適合對(duì)于效率要求很高，但是對(duì)于安全要求不高的場(chǎng)景。而SOAP的成熟性可以給需要提供給多開發(fā)語(yǔ)言的，對(duì)于安全性要求較高的接口設(shè)計(jì)帶來(lái)便利。所以我覺得純粹說(shuō)什么設(shè)計(jì)模式將會(huì)占據(jù)主導(dǎo)地位沒有什么意義，關(guān)鍵還是看應(yīng)用場(chǎng)景。

       同時(shí)很重要一點(diǎn)就是不要扭曲了REST現(xiàn)在很多網(wǎng)站都跟風(fēng)去開發(fā)REST風(fēng)格的接口，其實(shí)都是在學(xué)其形，不知其心，最后弄得不倫不類，性能上不去，安全又保證不了，徒有一個(gè)看似象摸象樣的皮囊。

REST設(shè)計(jì)的幾種形式

參看了幾個(gè)大型網(wǎng)站的REST風(fēng)格的API設(shè)計(jì)，這里做一下大致的說(shuō)明：

FaceBook:

請(qǐng)求消息：

       在URI設(shè)計(jì)上采取了類似于REST的風(fēng)格。例如對(duì)于friends的獲取，就定義為friends.get，前面部分作為資源定義，后面是具體的操作，其他的API也是類似，資源+操作，因此就算使用http的get方法都可能作了update的操作，其實(shí)已經(jīng)違背了REST的思想，但是說(shuō)到，其實(shí)那么復(fù)雜的業(yè)務(wù)接口設(shè)計(jì)下，要通過(guò)RUCD來(lái)抽象所有的接口基本是不實(shí)際的。在URI定義好以后，還有詳細(xì)的參數(shù)定義，包括類型以及是否必選。

響應(yīng)消息：

       有多種方式，XML,JSON。XML有XSD作為參考。有點(diǎn)類似于沒有Head的SOAP，只不過(guò)這里將原來(lái)可以定義在WSDL中的XSD抽取出來(lái)了。

Flickr:

       請(qǐng)求消息：

       http://api.flickr.com/services/rest/?method=flickr.test.echo&name=value

       這里就可以很明顯看出它所定制的REST請(qǐng)求其實(shí)和RPC沒有什么太大的區(qū)別。

       消息返回：

正確處理返回

<?xml version="1.0" encoding="utf-8" ?>

<rsp stat="ok">

         [xml-payload-here]

</rsp>

錯(cuò)誤處理返回

<?xml version="1.0" encoding="utf-8" ?>

<rsp stat="fail">

         <err code="[error-code]" msg="[error-message]" />

</rsp>

       根據(jù)返回可以看出已經(jīng)違背了REST的思想，還是把Http協(xié)議作為傳輸承載協(xié)議，并沒有真正意義上使用Http協(xié)議作為資源訪問(wèn)和操作協(xié)議。

       總的來(lái)說(shuō)，只是形式上去模仿REST，自己搞了一套私有協(xié)議。

Ebay：

       請(qǐng)求消息：

       采用xml作為承載，類似于SOAP，不過(guò)去除SOAP消息的封裝和包頭，同時(shí)在請(qǐng)求中附加了認(rèn)證和警告級(jí)別等附加信息。

       消息返回：

       類似于SOAP消息，不過(guò)刪除了SOAP的封裝和包頭，同時(shí)在返回結(jié)構(gòu)中增加了消息處理結(jié)果以及版本等附加信息。

       這個(gè)很類似于當(dāng)前Axis2框架的做法，將SOAP精簡(jiǎn)，同時(shí)根據(jù)自身需求豐富了安全，事務(wù)等協(xié)議內(nèi)容。

Yahoo Maps：

       請(qǐng)求消息：

       http://local.yahooapis.com/MapsService/V1/geocode?appid=YahooDemo&street=701+First+Ave&city=Sunnyvale&state=CA

       采用REST推薦的方式，URI+Parameters。

       返回消息：

<?xml version="1.0" encoding="UTF-8"?>

<ResultSet xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

xmlns="urn:yahoo:maps"

xsi:schemaLocation="urn:yahoo:maps http://local.yahooapis.com/MapsService/V1/GeocodeResponse.xsd">

 <Result precision="address">

    <Latitude>37.416384</Latitude>

    <Longitude>-122.024853</Longitude>

    <Address>701 FIRST AVE</Address>

    <City>SUNNYVALE</City>

    <State>CA</State>

    <Zip>94089-1019</Zip>

    <Country>US</Country>

 </Result>

</ResultSet>

SOAP的精簡(jiǎn)xml返回，其他信息，例如出錯(cuò)碼等信息由Http協(xié)議頭來(lái)承載。

YouTube：

請(qǐng)求消息：

http://www.youtube.com/api2_rest?method=youtube.users.get_profile&dev_id=YOUR_DEV_ID&user=YOUTUBE_USER_NAME

可以看到對(duì)于資源操作的URI定義也是參數(shù)的一部分。

返回消息：

<?xml version="1.0" encoding="utf-8"?>

<ut_response status="ok">

    <user_profile>

        <first_name>YouTube</first_name>

        <last_name>User</last_name>

        <about_me>YouTube rocks!!</about_me>

        <age>30</age>

        <video_upload_count>7</video_upload_count>

    </user_profile>

</ut_response>

       自定義的類SOAP消息。

Amazon：

       請(qǐng)求消息：

       https://Amazon FPS web service end point/?AWSAccessKeyId=Your AWSAccessKeyId

      &Timestamp=[Current timestamp] &Signature=[Signature calculated from hash of Action and Timestamp]

      &SignatureVersion=[Signature calculated from hash of Action and Timestamp]

      &Version=[Version of the WSDL specified in YYYY-MM-DD format] &Action=[Name of the API]

      &parameter1=[Value of the API parameter1] &parameter2=[Value of the API parameter2]

      &...[API parameters and their values]

       返回消息：

       類似于SOAP的自有協(xié)議，消息體中包含了消息狀態(tài)等附加信息。

總結(jié)：

       看了上面那么多網(wǎng)站的設(shè)計(jì)，總結(jié)一下主要有這么幾種設(shè)計(jì)方式。

請(qǐng)求消息設(shè)計(jì)：

1． 基本符合REST標(biāo)準(zhǔn)方式：資源URI定義（資源．操作）+參數(shù)。這類設(shè)計(jì)如果濫用get去處理其他類型的操作，那么和2無(wú)異。

2． REST風(fēng)格非REST思想：資源URI定義+參數(shù)（包含操作方法名）。其實(shí)就是RPC的REST跟風(fēng)。

3． 類似于SOAP消息，自定義協(xié)議，以xml作為承載。（可擴(kuò)展，例如鑒權(quán)，訪問(wèn)控制等），不過(guò)那就好比自己定義了一套SOAP和SOAP extends。大型的有實(shí)力的網(wǎng)站有的采取此種做法。

響應(yīng)消息設(shè)計(jì)：

1.       REST標(biāo)準(zhǔn)方式，將Resource State傳輸返回給客戶端，Http消息作為應(yīng)用協(xié)議而非傳輸協(xié)議

2.       以XML作為消息承載體，Http作為消息傳輸協(xié)議，處理狀態(tài)自包含。

3.       自定義消息格式，類似于SOAP，提供可擴(kuò)展部分。

作為遵循REST的理念來(lái)看我的選擇是響應(yīng)1和請(qǐng)求1的設(shè)計(jì)。

REST和ASF的集成

ASF要集成REST就現(xiàn)在來(lái)看有兩種比較合適的方法。

一．就是采用Axis2的REST實(shí)現(xiàn)，這種方式的好處就是開發(fā)周期短，容易集成，但是請(qǐng)求和響應(yīng)的格式無(wú)法改變，資源URI設(shè)計(jì)受限，Axis2的REST其實(shí)就是將SOAP消息精簡(jiǎn)，請(qǐng)求的時(shí)候刪除了SOAP的頭，響應(yīng)的時(shí)候僅僅返回資源信息，如果提供xsd就可以被各種客戶端所解析。并非真正的REST。

二．就是采用Restlet開源框架，將Restlet開源框架集成到ASF中，由于Restlet本身就是可內(nèi)嵌的應(yīng)用框架，因此集成不成問(wèn)題，同時(shí)Restlet框架只是API結(jié)構(gòu)框架，因此實(shí)現(xiàn)和定義完全分開，集成Restlet以后可以自己實(shí)現(xiàn)其中的解析引擎也可以采用默認(rèn)提供的引擎，同時(shí)對(duì)于內(nèi)嵌Jetty等多種開源項(xiàng)目的支持，將更多優(yōu)勢(shì)融入到了Rest中?？戳艘幌聡?guó)內(nèi)也有很多朋友已經(jīng)關(guān)注Restlet開源項(xiàng)目，看了它的架構(gòu)設(shè)計(jì)，個(gè)人覺得還是比較靈活和緊湊的。

題外話

       在寫這篇文章以前寫了一篇調(diào)研報(bào)告群發(fā)給各個(gè)架構(gòu)師們參考，期待反饋。下午正好和我們的首席架構(gòu)師聊了一會(huì)兒。其實(shí)我和他的感覺是一樣的，REST是否真的在我們現(xiàn)有的服務(wù)框架中需要集成，理解了REST的思想再去看應(yīng)用場(chǎng)景，那么可以發(fā)現(xiàn)如果要完全遵循REST的設(shè)計(jì)理念來(lái)設(shè)計(jì)接口的話，那么強(qiáng)要去改變現(xiàn)有已經(jīng)存在的或者還未開發(fā)的接口就會(huì)落入為了技術(shù)而技術(shù)，為了潮流而跟風(fēng)的近地。當(dāng)然并不否認(rèn)REST的好，其實(shí)我們兄弟公司的一些業(yè)務(wù)場(chǎng)景有部分的接口十分合適這類設(shè)計(jì)，面向資源，高效，簡(jiǎn)潔，易用都能夠體現(xiàn)出它的價(jià)值。我們將會(huì)和我們的兄弟公司合作，也會(huì)參考他們的設(shè)計(jì)理念，在參考當(dāng)前各個(gè)網(wǎng)站的實(shí)現(xiàn)情況下，部分的采用這類形式的發(fā)布，提供給第三方的ISV，無(wú)疑是我現(xiàn)在把REST融入到ASF中最好的理由。

       有了需求去做才不會(huì)陷入為了技術(shù)而技術(shù)，畢竟技術(shù)是由商業(yè)價(jià)值驅(qū)動(dòng)的，同樣社會(huì)上充斥著各種技術(shù)的鼓吹，如果稍不留神就會(huì)陷入跟風(fēng)的潮流中。

歡迎訪問(wèn)我csdn的blog：http://blog.csdn.net/cenwenchu79/,也歡迎和我做交流,msn:cenwenchu_1979@hotmail.com，關(guān)于SOA,REST,SAAS。

 

JVM優(yōu)化配置

       這里首先要說(shuō)明的是這里提到的JVM是Sun的HotSpot JVM 5和以上的版本。性能優(yōu)化在應(yīng)用方面可以有很多手段，包括Cache，多線程，各種算法等等。通常情況下是不建議在沒有任何統(tǒng)計(jì)和分析的情況下去手動(dòng)配置JVM的參數(shù)來(lái)調(diào)整性能，因?yàn)樵?/span>JVM 5以上已經(jīng)作了根據(jù)機(jī)器和OS的情況自動(dòng)配置合適參數(shù)的算法，基本能夠滿足大部分的情況，當(dāng)然這種自動(dòng)適配只是一種通用的方式，如果說(shuō)真的要達(dá)到最優(yōu)，那么還是需要根據(jù)實(shí)際的使用情況來(lái)手動(dòng)的配置各種參數(shù)設(shè)置，提高性能。

       JVM能夠?qū)π阅墚a(chǎn)生影響的最大部分就是對(duì)于內(nèi)存的管理。從jdk 1.5以后內(nèi)存管理和分配有了很多的改善和提高。

內(nèi)存分配以及管理的幾個(gè)基本概念和參數(shù)說(shuō)明：

Java Hotspot Mode：

server 和 client兩種模式，如果不配置，JVM會(huì)根據(jù)應(yīng)用服務(wù)器硬件配置自動(dòng)選擇模式，server模式啟動(dòng)比較慢，但是運(yùn)行期速度得到了優(yōu)化，client啟動(dòng)比較快，但是運(yùn)行期響應(yīng)沒有server模式的優(yōu)化，適合于個(gè)人PC的服務(wù)開發(fā)和測(cè)試。

Garbage Collector Policy：

       在Jdk 1.5的時(shí)候已經(jīng)提供了三種GC，除了原來(lái)提供的串行GC（SerialGC）以外，還提供了兩種新的GC：ParallelGC和ConcMarkSweepGC。ParallelGC采用了多線程并行管理和回收垃圾對(duì)象，提高了回收效率，提高了服務(wù)器的吞吐量，適合于多處理器的服務(wù)器。ConcMarkSweepGC采用的是并發(fā)方式來(lái)管理和回收垃圾對(duì)象，降低垃圾回收產(chǎn)生的響應(yīng)暫停時(shí)間。這里說(shuō)一下并發(fā)和并行的區(qū)別，并發(fā)指的是多個(gè)進(jìn)程并行執(zhí)行垃圾回收，那么可以很好的利用多處理器，而并行指的是應(yīng)用程序不需要暫?？梢院屠厥站€程并發(fā)工作。串行GC適合小型應(yīng)用和單處理器系統(tǒng)（無(wú)需多線程交互，效率比較高），后兩者適合大型系統(tǒng)。

       使用方式就是在參數(shù)配置中增加-XX:+UseParallelGC等方式來(lái)設(shè)置。

       對(duì)于這部分的配置在網(wǎng)上有很多的實(shí)例可以參考，不過(guò)最終采用哪一種GC還是要根據(jù)具體的情況來(lái)分析和選擇。

Heap：

       OOM的各種經(jīng)歷已經(jīng)讓每一個(gè)架構(gòu)師開發(fā)人員看到了了解Heap的重要性。OOM已經(jīng)是Heap的臨界點(diǎn)，不得不引起注意，然而Heap對(duì)于性能的潛在影響并未被引起重視，不過(guò)和GC配置一樣，在沒有對(duì)使用情況作仔細(xì)分析和研究的情況下，貿(mào)然的去修改Heap配置，可能適得其反，這里就來(lái)看一下Heap的一些概念和對(duì)于性能的影響。

       我們的應(yīng)用所能夠得到的最大的Heap受三部分因素的制約：數(shù)據(jù)處理模型（32位或者64位操作系統(tǒng)），系統(tǒng)地虛擬內(nèi)存總數(shù)和系統(tǒng)的物理內(nèi)存總數(shù)。首先Heap的大小不能超過(guò)不同操作系統(tǒng)的進(jìn)程尋址范圍，當(dāng)前大部分系統(tǒng)最高限度是4G，Windows通常是2G，Linux通常是3G。系統(tǒng)的虛擬內(nèi)存也是分配的依據(jù)，首先是不能超過(guò)，然后由于操作系統(tǒng)支持硬盤來(lái)做部分的虛擬內(nèi)存，如果設(shè)置過(guò)大，那么對(duì)于應(yīng)用響應(yīng)來(lái)說(shuō)勢(shì)必有影響。再則就是要考慮同一臺(tái)服務(wù)器上運(yùn)行多個(gè)Java虛擬機(jī)所消耗的資源總合也不能超過(guò)可用資源。就和前面OOM分析中的一樣，其實(shí)由于OS的數(shù)據(jù)處理模型的限制，機(jī)器本身的硬件內(nèi)存資源和虛擬內(nèi)存資源并不一定會(huì)匹配，那么在有限的資源下如何調(diào)整好資源分配，對(duì)于應(yīng)用來(lái)說(shuō)尤為重要。

關(guān)于Heap的幾個(gè)參數(shù)設(shè)置：

       說(shuō)了Heap的有限資源問(wèn)題以后，就來(lái)看看如何通過(guò)配置去改變JVM對(duì)于Heap的分配。下面所說(shuō)的主要是對(duì)于Java Heap的分配，那么在申請(qǐng)了Java Heap以后，剩下的可用資源就會(huì)被使用到Native Heap。

       Xms: java heap初始化時(shí)的大小。默認(rèn)情況是機(jī)器物理內(nèi)存的1/64。這個(gè)主要是根據(jù)應(yīng)用啟動(dòng)時(shí)消耗的資源決定，分配少了申請(qǐng)起來(lái)會(huì)降低啟動(dòng)速度，分配多了也浪費(fèi)。

       Xmx:java heap的最大值，默認(rèn)是機(jī)器物理內(nèi)存的1/4，最大也就到1G。這個(gè)值決定了最多可用的Java Heap Memory，分配過(guò)少就會(huì)在應(yīng)用需要大量?jī)?nèi)存作緩存或者零時(shí)對(duì)象時(shí)出現(xiàn)OOM的問(wèn)題，如果分配過(guò)大，那么就會(huì)產(chǎn)生上文提到的第二類OOM。所以如何配置還是根據(jù)運(yùn)行過(guò)程中的分析和計(jì)算來(lái)確定，如果不能確定還是采用默認(rèn)的配置。

       Xmn:java heap新生代的空間大小。在GC模型中，根據(jù)對(duì)象的生命周期的長(zhǎng)短，產(chǎn)生了內(nèi)存分代的設(shè)計(jì)：青年代（內(nèi)部也分成三部分，類似于整體劃分的作用，可以通過(guò)配置來(lái)設(shè)置比例），老年代，持久代。每一代的管理和回收策略都不相同，最為活躍的就是青年代，同時(shí)這部分的內(nèi)存分配和管理效率也是最高。通常情況下，對(duì)于內(nèi)存的申請(qǐng)優(yōu)先在新生代中申請(qǐng)，當(dāng)內(nèi)存不夠時(shí)會(huì)整理新生代，當(dāng)整理以后還是不能滿足申請(qǐng)的內(nèi)存，就會(huì)向老年代移動(dòng)一些生命周期較長(zhǎng)的對(duì)象。這種整理和移動(dòng)會(huì)消耗資源，同時(shí)降低系統(tǒng)運(yùn)行響應(yīng)能力，因此如果青年代設(shè)置的過(guò)小，就會(huì)頻繁的整理和移動(dòng)，對(duì)性能造成影響。那是否把年青代設(shè)置的越大越好，其實(shí)不然，年青代采用的是復(fù)制搜集算法，這種算法必須停止所有應(yīng)用程序線程，服務(wù)器線程切換時(shí)間就會(huì)成為應(yīng)用響應(yīng)的瓶頸（當(dāng)然永遠(yuǎn)不用收集那么就不存在這個(gè)問(wèn)題）。老年代采用的是串行標(biāo)記收集的方式，并發(fā)收集可以減少對(duì)于應(yīng)用的影響。

       Xss:線程堆棧最大值。允許更多的虛擬內(nèi)存空間地址被Java Heap使用。

以下是sun公司的性能優(yōu)化白皮書中提到的幾個(gè)例子：

1．對(duì)于吞吐量的調(diào)優(yōu)。機(jī)器配置：4G的內(nèi)存，32個(gè)線程并發(fā)能力。

java -Xmx3800m -Xms3800m -Xmn2g -Xss128k -XX:+UseParallelGC -XX:ParallelGCThreads=20

       -Xmx3800m -Xms3800m 配置了最大Java Heap來(lái)充分利用系統(tǒng)內(nèi)存。

       -Xmn2g 創(chuàng)建足夠大的青年代（可以并行被回收）充分利用系統(tǒng)內(nèi)存，防止將短期對(duì)象復(fù)制到老年代。

    -Xss128 減少默認(rèn)最大的線程棧大小，提供更多的處理虛擬內(nèi)存地址空間被進(jìn)程使用。

    -XX:+UseParallelGC 采用并行垃圾收集器對(duì)年青代的內(nèi)存進(jìn)行收集，提高效率。

    -XX:ParallelGCThreads=20 減少垃圾收集線程，默認(rèn)是和服務(wù)器可支持的線程最大并發(fā)數(shù)相同，往往不需要配置到最大值。

 

2．嘗試采用對(duì)老年代并行收集

java -Xmx3550m -Xms3550m -Xmn2g -Xss128k -XX:+UseParallelGC -XX:ParallelGCThreads=20 -XX:+UseParallelOldGC

-Xmx3550m -Xms3550m 內(nèi)存分配被減小，因?yàn)镻arallelOldGC會(huì)增加對(duì)于Native Heap的需求，因此需要減小Java Heap來(lái)滿足需求。

-XX:+UseParallelOldGC 采用對(duì)于老年代并發(fā)收集的策略，可以提高收集效率。

 

3．提高吞吐量，減少應(yīng)用停頓時(shí)間

java -Xmx3550m -Xms3550m -Xmn2g -Xss128k -XX:ParallelGCThreads=20 -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -XX:SurvivorRatio=8 -XX:TargetSurvivorRatio=90 -XX:MaxTenuringThreshold=31

 

-XX:+UseConcMarkSweepGC -XX:+UseParNewGC 選擇了并發(fā)標(biāo)記交換收集器，它可以并發(fā)執(zhí)行收集操作，降低應(yīng)用停止時(shí)間，同時(shí)它也是并行處理模式，可以有效地利用多處理器的系統(tǒng)的多進(jìn)程處理。

-XX:SurvivorRatio=8 -XX:MaxTenuringThreshold=31 表示在青年代中Eden和Survivor比例，設(shè)置增加了Survivor的大小，越大的survivor空間可以允許短期對(duì)象盡量在年青代消亡。

 

-XX:TargetSurvivorRatio=90 允許90%的空間被占用，超過(guò)默認(rèn)的50%，提高對(duì)于survivor的使用率。

 

類似的例子網(wǎng)上很多，這兒就不在列下來(lái)了，最終是否采取自己配置來(lái)替換默認(rèn)配置還是要根據(jù)虛擬機(jī)的使用情況來(lái)分析和配置。

       OOM這個(gè)縮寫就是Java程序開發(fā)過(guò)程中讓人最頭痛的問(wèn)題：Out of Memory。在很多開發(fā)人員的開發(fā)過(guò)程中，或多或少的都會(huì)遇到這類問(wèn)題，這類問(wèn)題定位比較困難，往往需要根據(jù)經(jīng)驗(yàn)來(lái)判斷可能出現(xiàn)問(wèn)題的代碼。原因主要是兩個(gè)：對(duì)象沒有被釋放（多種情況引起，往往是比較隱蔽的引用導(dǎo)致被Hold而無(wú)法被回收）。另一種就是真的Memory不夠用了，需要增加JVM的Heap來(lái)滿足應(yīng)用程序的需求。最近有同事發(fā)的關(guān)于解決OOM的問(wèn)題，讓我了解了原來(lái)OOM除了在JVM Heap不夠時(shí)會(huì)發(fā)生，在Native Heap不夠的時(shí)候也會(huì)發(fā)生，同時(shí)JVM Heap和Native Heap存在著相互影響和平衡的關(guān)系，因此就仔細(xì)的去看了關(guān)于OOM和JVM配置優(yōu)化的內(nèi)容。

OOM

       在其他語(yǔ)言類似于C,Delphi等等由于內(nèi)存都是由自己分配和管理，因此內(nèi)存泄露的問(wèn)題比較常見，同時(shí)也是很頭痛的一件事情。而Java的對(duì)象生命周期管理都是JVM來(lái)做的，簡(jiǎn)化了開發(fā)人員的非業(yè)務(wù)邏輯的處理，但是這種自動(dòng)管理回收機(jī)制也是基于一些規(guī)則的，而違背了這些規(guī)則的時(shí)候，就會(huì)造成所謂的“Memory Leak”。

OOM(Java Heap)

       錯(cuò)誤提示：java.lang.OutOfMemoryError。

這類OOM是由于JVM分配的給應(yīng)用的Heap Memory已經(jīng)被耗盡，可能是因?yàn)閼?yīng)用在高負(fù)荷的情況下的卻需要很大的內(nèi)存，因此可以通過(guò)修改JVM參數(shù)來(lái)增加Java Heap Memory（不過(guò)也不能無(wú)限制增加，后面那種OOM有可能就是因?yàn)檫@個(gè)原因而產(chǎn)生）。另一種情況是因?yàn)閼?yīng)用程序使用對(duì)象或者資源沒有釋放，導(dǎo)致內(nèi)存消耗持續(xù)增加，最后出現(xiàn)OOM，這類問(wèn)題引起的原因往往是應(yīng)用已不需要的對(duì)象還被其他有效對(duì)象所引用，那么就無(wú)法釋放，可能是業(yè)務(wù)代碼邏輯造成的（異常處理不夠例如IO等資源），也可能是對(duì)于第三方開源項(xiàng)目中資源釋放了解不夠?qū)е率褂靡院筚Y源沒有釋放（例如JDBC的ResultSet等）。

       幾個(gè)容易出現(xiàn)問(wèn)題的場(chǎng)景：

       1．應(yīng)用的緩存或者Collection：如果應(yīng)用要緩存Java對(duì)象或者是在一個(gè)Collection中保存對(duì)象，那么就要確定是否會(huì)有大量的對(duì)象存入，要做保護(hù)，以防止在大數(shù)據(jù)量下大量?jī)?nèi)存被消耗，同時(shí)要保證Cache的大小不會(huì)無(wú)限制增加。

       2．生命周期較長(zhǎng)的對(duì)象：盡量簡(jiǎn)短對(duì)象的生命周期，現(xiàn)在采用對(duì)象的創(chuàng)建釋放代價(jià)已經(jīng)很低，同時(shí)作了很好的優(yōu)化，要比創(chuàng)建一個(gè)對(duì)象長(zhǎng)期反復(fù)使用要好。如果能夠設(shè)置超時(shí)的情景下，盡量設(shè)置超時(shí)。

       3．類似于JDBC的Connection Pool，在使用Pool中的對(duì)象以后需要釋放并返回，不然就會(huì)造成Pool的不斷增大，在其他Pool中使用也是一樣。同樣ResultSet，IO這類資源的釋放都需要注意。

       解決的方法就是查找錯(cuò)誤或者是增加Java Heap Memory。對(duì)于此類問(wèn)題檢測(cè)工具相當(dāng)多，這里就不做介紹了。      

OOM(Native Heap)

錯(cuò)誤提示：requested XXXX bytes for ChunkPool::allocate. Out of swap space。

       Native Heap Memory是JVM內(nèi)部使用的Memory，這部分的Memory可以通過(guò)JDK提供的JNI的方式去訪問(wèn)，這部分Memory效率很高，但是管理需要自己去做，如果沒有把握最好不要使用，以防出現(xiàn)內(nèi)存泄露問(wèn)題。JVM 使用Native Heap Memory用來(lái)優(yōu)化代碼載入（JTI代碼生成），臨時(shí)對(duì)象空間申請(qǐng)，以及JVM內(nèi)部的一些操作。這次同事在壓力測(cè)試中遇到的問(wèn)題就是這類OOM，也就是這類Memory耗盡。同樣這類OOM產(chǎn)生的問(wèn)題也是分成正常使用耗盡和無(wú)釋放資源耗盡兩類。無(wú)釋放資源耗盡很多時(shí)候不是程序員自身的原因，可能是引用的第三方包的缺陷，例如很多人遇到的Oracle 9 JDBC驅(qū)動(dòng)在低版本中有內(nèi)存泄露的問(wèn)題。要確定這類問(wèn)題，就需要去觀察Native Heap Memory的增長(zhǎng)和使用情況，在服務(wù)器應(yīng)用起來(lái)以后，運(yùn)行一段時(shí)間后JVM對(duì)于Native Heap Memory的使用會(huì)達(dá)到一個(gè)穩(wěn)定的階段，此時(shí)可以看看什么操作對(duì)于Native Heap Memory操作頻繁，而且使得Native Heap Memory增長(zhǎng)，對(duì)于Native Heap Memory的情況我還沒有找到辦法去檢測(cè)，現(xiàn)在能夠看到的就是為JVM啟動(dòng)時(shí)候增加-verbose:jni參數(shù)來(lái)觀察對(duì)于Native Heap Memory的操作。另一種情況就是正常消耗Native Heap Memory，對(duì)于Native Heap Memory的使用主要取決于JVM代碼生成，線程創(chuàng)建，用于優(yōu)化的臨時(shí)代碼和對(duì)象產(chǎn)生。當(dāng)正常耗盡Native Heap Memory時(shí)，那么就需要增加Native Heap Memory，此時(shí)就會(huì)和我們前面提到增加java Heap Memory的情況出現(xiàn)矛盾。

應(yīng)用內(nèi)存組合

       對(duì)于應(yīng)用來(lái)說(shuō)，可分配的內(nèi)存受到OS的限制，不同的OS對(duì)進(jìn)程所能訪問(wèn)虛擬內(nèi)存地址區(qū)間直接影響對(duì)于應(yīng)用內(nèi)存的分配，32位的操作系統(tǒng)通常最大支持4G的內(nèi)存尋址，而Linux一般為3G，Windows為2G。然而這些大小的內(nèi)存并不會(huì)全部給JVM的Java Heap使用，它主要會(huì)分成三部分：Java Heap，Native Heap，載入資源和類庫(kù)等所占用的內(nèi)存。那么由此可見，Native Heap和 Java Heap大小配置是相互制約的，哪一部分分配多了都可能會(huì)影響到另外一部分的正常工作，因此如果通過(guò)命令行去配置，那么需要確切的了解應(yīng)用使用情況，否則采用默認(rèn)配置自動(dòng)監(jiān)測(cè)會(huì)更好的優(yōu)化應(yīng)用使用情況。

       同樣要注意的就是進(jìn)程的虛擬內(nèi)存和機(jī)器的實(shí)際內(nèi)存還是有區(qū)別的，對(duì)于機(jī)器來(lái)說(shuō)實(shí)際內(nèi)存以及硬盤提供的虛擬內(nèi)存都是提供給機(jī)器上所有進(jìn)程使用的，因此在設(shè)置JVM參數(shù)時(shí)，它的虛擬內(nèi)存絕對(duì)不應(yīng)該超過(guò)實(shí)際內(nèi)存的大小。

待續(xù)……

JVM優(yōu)化配置

更多內(nèi)容可訪問(wèn)：http://blog.csdn.net/cenwenchu79/

Author: wenchu.cenwc

Email: wenchu.cenwc@alibaba-inc.com

Memcached 介紹與分析

       Memcached是一種集中式Cache，支持分布式橫向擴(kuò)展?？偨Y(jié)幾個(gè)它的特點(diǎn)來(lái)理解一下它的優(yōu)點(diǎn)和限制。

       Memory：內(nèi)存存儲(chǔ)，不言而喻，速度快，對(duì)于內(nèi)存的要求高，不指出的話所緩存的內(nèi)容非持久化。對(duì)于CPU要求很低，所以常常采用將Memcached服務(wù)端和一些CPU高消耗Memory低消耗應(yīng)用部屬在一起。（作為我們AEP正好有這樣的環(huán)境，我們的接口服務(wù)器有多臺(tái)，接口服務(wù)器對(duì)于CPU要求很高（由于WS-Security），但是對(duì)于Memory要求很低，因此可以用作Memcached的服務(wù)端部屬機(jī)器）

       集中式Cache：避開了分布式Cache的傳播問(wèn)題，但是需要非單點(diǎn)保證其可靠性，這個(gè)就是后面集成中所作的cluster的工作，可以將多個(gè)Memcached作為一個(gè)虛擬的cluster，同時(shí)對(duì)于cluster的讀寫和普通的memcached的讀寫性能沒有差別。

       分布式擴(kuò)展：Memcached的很突出一個(gè)優(yōu)點(diǎn)，就是采用了可分布式擴(kuò)展的模式?？梢詫⒉繉僭谝慌_(tái)機(jī)器上的多個(gè)Memcached服務(wù)端或者部署在多個(gè)機(jī)器上的Memcached服務(wù)端組成一個(gè)虛擬的服務(wù)端，對(duì)于調(diào)用者來(lái)說(shuō)完全屏蔽和透明。提高的單機(jī)器的內(nèi)存利用率，也提供了scale out的方式。

       Socket通信：傳輸內(nèi)容的大小以及序列化的問(wèn)題需要注意，雖然Memcached通常會(huì)被放置到內(nèi)網(wǎng)作為Cache，Socket傳輸速率應(yīng)該比較高（當(dāng)前支持Tcp和udp兩種模式，同時(shí)根據(jù)客戶端的不同可以選擇使用nio的同步或者異步調(diào)用方式），但是序列化成本和帶寬成本還是需要注意。這里也提一下序列化，對(duì)于對(duì)象序列化的性能往往讓大家頭痛，但是如果對(duì)于同一類的Class對(duì)象序列化傳輸，第一次序列化時(shí)間比較長(zhǎng)，后續(xù)就會(huì)優(yōu)化，其實(shí)也就是說(shuō)序列化最大的消耗不是對(duì)象序列化，而是類的序列化。如果穿過(guò)去的只是字符串，那么是最好的，省去了序列化的操作，因此在Memcached中保存的往往是較小的內(nèi)容。

       特殊的內(nèi)存分配機(jī)制：首先要說(shuō)明的是Memcached支持最大的存儲(chǔ)對(duì)象為1M。它的內(nèi)存分配比較特殊，但是這樣的分配方式其實(shí)也是對(duì)于性能考慮的，簡(jiǎn)單的分配機(jī)制可以更容易回收再分配，節(jié)省對(duì)于CPU的使用。這里用一個(gè)酒窖比喻來(lái)說(shuō)明這種內(nèi)存分配機(jī)制，首先在Memcached起來(lái)的時(shí)候可以通過(guò)參數(shù)設(shè)置使用的總共的Memory，這個(gè)就是建造一個(gè)酒窖，然后在有酒進(jìn)入的時(shí)候，首先申請(qǐng)（通常是1M）的空間，用來(lái)建酒架，酒架根據(jù)這個(gè)酒瓶的大小分割酒架為多個(gè)小格子安放酒瓶，將同樣大小范圍內(nèi)的酒瓶都放置在一類酒架上面。例如20cm半徑的酒瓶放置在可以容納20-25cm的酒架A上，30cm半徑的酒瓶就放置在容納25-30cm的酒架B上?；厥諜C(jī)制也很簡(jiǎn)單，首先新酒入庫(kù)，看看酒架是否有可以回收的地方，如果有直接使用，如果沒有申請(qǐng)新的地方，如果申請(qǐng)不到，采用配置的過(guò)期策略。這個(gè)特點(diǎn)來(lái)看，如果要放的內(nèi)容大小十分離散，同時(shí)大小比例相差梯度很明顯，那么可能對(duì)于使用空間來(lái)說(shuō)不好，可能在酒架A上就放了一瓶酒，但占用掉了一個(gè)酒架的位置。

       Cache機(jī)制簡(jiǎn)單：有時(shí)候很多開源的項(xiàng)目做的面面俱到，但是最后也就是因?yàn)檫^(guò)于注重一些非必要性的功能而拖累了性能，這里要提到的就是Memcached的簡(jiǎn)單性。首先它沒有什么同步，消息分發(fā)，兩階段提交等等，它就是一個(gè)很簡(jiǎn)單的Cache，把東西放進(jìn)去，然后可以取出來(lái)，如果發(fā)現(xiàn)所提供的Key沒有命中，那么就很直白的告訴你，你這個(gè)key沒有任何對(duì)應(yīng)的東西在緩存里，去數(shù)據(jù)庫(kù)或者其他地方取，當(dāng)你在外部數(shù)據(jù)源取到的時(shí)候，可以直接將內(nèi)容置入到Cache中，這樣下次就可以命中了。這里會(huì)提到怎么去同步這些數(shù)據(jù)，兩種方式，一種就是在你修改了以后立刻更新Cache內(nèi)容，這樣就會(huì)即時(shí)生效。另一種是說(shuō)容許有失效時(shí)間，到了失效時(shí)間，自然就會(huì)將內(nèi)容刪除，此時(shí)再去去的時(shí)候就會(huì)命中不了，然后再次將內(nèi)容置入Cache，用來(lái)更新內(nèi)容。后者用在一些時(shí)時(shí)性要求不高，寫入不頻繁的情況。

       客戶端的重要性：Memcached是用C寫的一個(gè)服務(wù)端，客戶端沒有規(guī)定，反正是Socket傳輸，只要語(yǔ)言支持Socket通信，通過(guò)Command的簡(jiǎn)單協(xié)議就可以通信，但是客戶端設(shè)計(jì)的合理十分重要，同時(shí)也給使用者提供了很大的空間去擴(kuò)展和設(shè)計(jì)客戶端來(lái)滿足各種場(chǎng)景的需要，包括容錯(cuò)，權(quán)重，效率，特殊的功能性需求，嵌入框架等等。

       幾個(gè)應(yīng)用點(diǎn)：小對(duì)象的緩存（用戶的token，權(quán)限信息，資源信息）。小的靜態(tài)資源緩存。Sql結(jié)果的緩存（這部分用的好，性能提高相當(dāng)大，同時(shí)由于Memcached自身提供scale out，那么對(duì)于db scale out的老大難問(wèn)題無(wú)疑是一劑好藥）。ESB消息緩存。

集成設(shè)計(jì)

       為什么需要集成？直接使用現(xiàn)有的兩個(gè)Java實(shí)現(xiàn)Memcached是否就可以了？

       當(dāng)前集成主要為了兩方面考慮，首先是方便的配置使用，如何將Memcached內(nèi)嵌到類似于ASF以及其他框架中去，并且通過(guò)配置文件方便使用，這就需要作部分的集成工作，這部分工作主要是定義了配置文件以及通過(guò)Stax去解析配置的功能。然后是如何管理Memcached，這部分內(nèi)容包括了初始化，運(yùn)行期檢測(cè)，資源回收的工作。最后是擴(kuò)展，這里的擴(kuò)展分成兩部分（功能的擴(kuò)展以及框架實(shí)現(xiàn)的擴(kuò)展），功能擴(kuò)展例如當(dāng)前擴(kuò)展了虛擬的cluster，可以讓多個(gè)memcached Client組成一個(gè)虛擬的cluster，如果通過(guò)放入cluster的方式放入到其中一個(gè)Cache Client中的話，那么就可以在整個(gè)cluster都作好備份，這樣其實(shí)可以根據(jù)memcached的單機(jī)多實(shí)例以及多機(jī)多實(shí)例作交互備份，提高可靠性。當(dāng)然后續(xù)還有很多可以擴(kuò)展的內(nèi)容，這里只是一個(gè)開頭?？蚣軐?shí)現(xiàn)的擴(kuò)展指的是這里采用了類似于Jdk的JAXP的框架設(shè)計(jì)，只是規(guī)定了框架API結(jié)構(gòu)，至于實(shí)現(xiàn)者動(dòng)態(tài)載入，這個(gè)和ASF等現(xiàn)在可擴(kuò)展的框架一樣，提供了很方便的擴(kuò)展點(diǎn)，后續(xù)的設(shè)計(jì)中會(huì)提到。

接口設(shè)計(jì)類圖：

圖1 Cache接口包類圖

       ICache和IMemcachedCache實(shí)現(xiàn)的是最基本的Cache的功能，只是IMemcachedCache有所增強(qiáng)，提供了對(duì)于虛擬的Cluster的操作，批量操作，統(tǒng)計(jì)的功能。ICacheManager和IMemcachedCacheManager分別是對(duì)于上面兩個(gè)Cache的管理類，根據(jù)配置文件解析，初始化客戶端池，建立虛擬集群，銷毀客戶端池等工作。

圖2 Memcached 實(shí)現(xiàn)包

       省略了一些輔助類定義。這部分是具體的實(shí)現(xiàn)，同時(shí)可以在圖上看到spi包內(nèi)的CacheManagerFactory就是用來(lái)提供擴(kuò)展使用的接口。只需要定義在jar的META-INF下面建立services目錄，建立兩個(gè)名為：com.alisoft.xplatform.asf.cache.IMemcachedCacheManager和com.alisoft.xplatform.asf.cache.spi.CacheManagerFactory的文件就可以替換MemcachedCacheManager和CacheManagerFactory的實(shí)現(xiàn)類，從而改變Memcached Client實(shí)現(xiàn)機(jī)制。如果沒有這兩個(gè)文件在Classpath目錄下面，那么默認(rèn)將會(huì)使用當(dāng)前框架中的兩個(gè)實(shí)現(xiàn)。

圖3 Memcached的結(jié)構(gòu)圖

       Memcached Server就是部署在不同服務(wù)器或者在同一臺(tái)服務(wù)器上的Memcached實(shí)例，一般采用后臺(tái)守護(hù)進(jìn)程方式運(yùn)行。SocketPool是客戶端連接到服務(wù)端的Socket通信層，Memcached Client可以歸屬為虛擬的Cluster，MemcachedCacheManager作用是管理Cluster和Cache。從這個(gè)結(jié)構(gòu)圖可以看出客戶端的每一層都是很獨(dú)立，這樣有利于層次的交互，以及組合擴(kuò)展。

測(cè)試與使用

1． 配置：

需要有一個(gè)名為memcached.xml的文件在classpath中，可以在jar里面也可以在任意classpath可以找的到的地方，需要注意的是，CacheManager實(shí)現(xiàn)了對(duì)于多個(gè)memcached.xml merge的功能。

具體的配置內(nèi)容如下：

<?xml version="1.0" encoding="UTF-8"?>

<memcached>//總標(biāo)簽

  //memcached Client的配置，也就是一個(gè)IMemcachedCache的配置。Name必須填，表示Cache的名稱，socketpool必須填，表示使用的遠(yuǎn)程通信連接池是哪一個(gè)，參看后面對(duì)于socketpool的定義。后面都是可選的，第三個(gè)參數(shù)表示傳輸?shù)臅r(shí)候是否壓縮，第四個(gè)參數(shù)表示默認(rèn)的編碼方式

<client name="mclient1" socketpool="pool1" compressEnable="true" defaultEncoding="UTF-8" >

        <!--errorHandler></errorHandler-->//可定義錯(cuò)誤處理類，一般不需要定義

    </client>

    <client name="mclient2" socketpool="pool2" compressEnable="true" defaultEncoding="UTF-8" >

    </client>  

     //socketpool是通信連接池定義，每一個(gè)memcached Client要和服務(wù)端交互都必須有通信連接池作為底層數(shù)據(jù)通信的支持，name必填，表示名字，同時(shí)也是memcached client指定socketpool的依據(jù)，failover表示對(duì)于服務(wù)器出現(xiàn)問(wèn)題時(shí)的自動(dòng)修復(fù)。initConn初始的時(shí)候連接數(shù)，minConn表示最小閑置連接數(shù)，maxConn最大連接數(shù)，maintSleep表示是否需要延時(shí)結(jié)束（最好設(shè)置為0，如果設(shè)置延時(shí)的話那么就不能夠立刻回收所有的資源，如果此時(shí)從新啟動(dòng)同樣的資源分配，就會(huì)出現(xiàn)問(wèn)題），nagle是TCP對(duì)于socket創(chuàng)建的算法，socketTO是socket連接超時(shí)時(shí)間，aliveCheck表示心跳檢查，確定服務(wù)器的狀態(tài)。Servers是memcached服務(wù)端開的地址和ip列表字符串，weights是上面服務(wù)器的權(quán)重，必須數(shù)量一致，否則權(quán)重?zé)o效

    <socketpool name="pool1" failover="true" initConn="10" minConn="5" maxConn="250" maintSleep="0"

        nagle="false" socketTO="3000" aliveCheck="true">

        <servers>10.0.68.210:12000,10.0.68.210:12222</servers>

        <weights>5,5</weights>

    </socketpool>  

    <socketpool name="pool2" failover="true" initConn="10" minConn="5" maxConn="250" maintSleep="0"

        nagle="false" socketTO="3000" aliveCheck="true">

        <servers>10.0.68.210:22000,10.0.68.210:22222</servers>

        <weights>5,5</weights>

    </socketpool>

    //虛擬集群設(shè)置，這里將幾個(gè)client的cache設(shè)置為一個(gè)虛擬集群，當(dāng)對(duì)這些IMemcachedCache作集群操作的時(shí)候，就會(huì)自動(dòng)地對(duì)集群中所有的Cache作插入，尋找以及刪除的操作，做一個(gè)虛擬交互備份

    <cluster name="cluster1">

        <memCachedClients>mclient1,mclient2</memCachedClients>

    </cluster>            

</memcached>

2． 測(cè)試代碼，這里就附帶一個(gè)單元測(cè)試類的代碼就可以很清楚的知道使用方法。

后話

沒有不好的，只有不適合的，適合的場(chǎng)景使用，根據(jù)場(chǎng)景適合的使用，才是提高性能的最有效手段。后需要根據(jù)所需的應(yīng)用場(chǎng)景繼續(xù)對(duì)這部分集成內(nèi)容作完善，實(shí)踐完善設(shè)計(jì)。

 

     周四下午聽了一節(jié)課就提早回來(lái)了，周五身體不好也就沒有去公司，也沒有寫關(guān)于第二天的一些所見所聞，其實(shí)第一天的啟發(fā)也并非完全是參加了大會(huì)的感觸，只是正好和自己目標(biāo)有些碰撞，感覺還有一些可寫的。第二日，早晨的內(nèi)容其實(shí)昨天已經(jīng)也略有所聞，但是可能更為詳細(xì)一些，下午的內(nèi)容就基本沒怎么聽了，因?yàn)槲ㄒ灰粋€(gè)感覺還算是比較務(wù)實(shí)的課堂連載給我的感覺就是“空”，也可能是因?yàn)闀r(shí)間都只有一個(gè)小時(shí)，所以基本那些演講人翻翻ppt就來(lái)不及了，也沒什么可以細(xì)致的解答的，而提問(wèn)的同學(xué)聽來(lái)聽去就是問(wèn)一個(gè)問(wèn)題：“實(shí)施SOA怎么做？”老師能給的一個(gè)答案就是“不同的情況又不同的處理辦法吧”。既然寫了，那么還是流水的記錄一下這一天的所見所聞。

       早晨還是主題演講，和昨天一樣，也是技術(shù)+實(shí)踐。一共分成了五部分：1.提高企業(yè)生產(chǎn)效率：企業(yè)社會(huì)計(jì)算與業(yè)務(wù)流程管理。2.中國(guó)生活網(wǎng)項(xiàng)目介紹。3.極速虛擬化。4.東軟的演講。5.BEA咨詢副總裁的實(shí)施創(chuàng)新。這五部分內(nèi)容，第一部分還是有一些其啟發(fā)的內(nèi)容，因此最后介紹一下。

中國(guó)生活網(wǎng)，東軟的演講就像給我blog留言的一個(gè)同樣去了BEA2007的朋友說(shuō)的一樣，商業(yè)推廣大于技術(shù)創(chuàng)新推廣。

極速虛擬化主要介紹的是BEA和VMWare公司合作的一種應(yīng)用服務(wù)部署模式，將原來(lái)的服務(wù)器+OS+VM+WEBContainer+App改變成為服務(wù)器+LiquidVM+WLS-VE+App，省略了原來(lái)的OS，同時(shí)通過(guò)虛擬層的優(yōu)化，將硬件服務(wù)器由單機(jī)獨(dú)立部署，轉(zhuǎn)變成為硬件資源池，軟件負(fù)載均衡動(dòng)態(tài)部署應(yīng)用，提高服務(wù)器的利用率，將軟件抽象出來(lái)與底層硬件分離。由于這部分內(nèi)容和底層硬件優(yōu)化比較緊密，和上層軟件架構(gòu)不是很相關(guān)，因此對(duì)我來(lái)說(shuō)能夠?qū)嵺`的機(jī)會(huì)比較少。

BEA咨詢副總裁講的實(shí)施創(chuàng)新，一開始就以當(dāng)前最為火熱的幾個(gè)web2.0的網(wǎng)站作為切入點(diǎn)，講述了一下這些網(wǎng)站成功就是在與創(chuàng)新，后面就是推廣性的介紹了一下當(dāng)前互聯(lián)網(wǎng)應(yīng)用的情況，并沒有提到如何去創(chuàng)新。赫赫，不過(guò)如果說(shuō)出來(lái)了，就不叫作創(chuàng)新了，創(chuàng)新還是要根據(jù)每個(gè)人的商業(yè)嗅覺，當(dāng)有了技術(shù)的支持以后，如何變技術(shù)為社會(huì)價(jià)值，并將其社會(huì)價(jià)值最大化，那就依賴于個(gè)人創(chuàng)新能力體現(xiàn)了。

最后談?wù)勆衔绲谝粋€(gè)主題演講：提高企業(yè)生產(chǎn)效率：企業(yè)社會(huì)計(jì)算與業(yè)務(wù)流程管理。這個(gè)主題其實(shí)針對(duì)的客戶群應(yīng)該不是類似于我這樣的應(yīng)用平臺(tái)開發(fā)架構(gòu)師，而是國(guó)有大中型企業(yè)的IT技術(shù)經(jīng)理。這部分內(nèi)容其實(shí)應(yīng)該是涉及到了SOA的應(yīng)用，將SOA+Web2.0結(jié)合應(yīng)用到了企業(yè)級(jí)信息管理中。不過(guò)同一本佛經(jīng)，不同的和尚悟出的道理也是不同的，給出下面幾個(gè)重點(diǎn)詞，做一下解釋和自己的一些分享（這里只是從自己的角度去看待主題中的一些關(guān)鍵內(nèi)容）。

Key point：資產(chǎn)管理的演變

Detail：企業(yè)的資產(chǎn)管理由Capital的管理àInformation管理àInteraction管理。其實(shí)第一步就是我們過(guò)去說(shuō)的最原始的ERP風(fēng)潮的進(jìn)化，而第二步其實(shí)是在當(dāng)前Web2.0的啟發(fā)下，企業(yè)內(nèi)部管理的再次變革，當(dāng)然這次變革是跟隨當(dāng)前互聯(lián)網(wǎng)Web2.0的技術(shù)變革而產(chǎn)生的。一個(gè)領(lǐng)域的變革，能夠啟發(fā)另一個(gè)領(lǐng)域的變革。當(dāng)企業(yè)內(nèi)部由有形資產(chǎn)比例占據(jù)絕對(duì)優(yōu)勢(shì)逐漸轉(zhuǎn)變成為人力資源等無(wú)形資產(chǎn)占據(jù)絕對(duì)優(yōu)勢(shì)以后，企業(yè)管理的手段以及方式都將作很大的改變，而一個(gè)企業(yè)和一個(gè)互聯(lián)網(wǎng)應(yīng)用一樣，如果想要不斷發(fā)展，那么就不能僅僅依靠?jī)扇齻€(gè)管理者的智慧，而是要依靠企業(yè)員工所構(gòu)筑的企業(yè)內(nèi)社會(huì)網(wǎng)絡(luò)來(lái)不斷提供新鮮血液。這點(diǎn)也就是Web2.0的重要特性之一，社區(qū)概念和群眾參與。將每一個(gè)個(gè)體的生產(chǎn)率轉(zhuǎn)變成為企業(yè)生產(chǎn)率。而完成這一點(diǎn)當(dāng)前能夠采取的有效手段，就是通過(guò)SOA+BPM在企業(yè)中的實(shí)施來(lái)達(dá)成。構(gòu)建信息共享網(wǎng)絡(luò)（現(xiàn)在可比以前豐富多了，blog,rss,wiki等等，在回來(lái)的時(shí)候我們幾個(gè)還談?wù)摿丝梢詷?gòu)建企業(yè)內(nèi)部的交友社區(qū)，解決大齡男女的終身大事問(wèn)題）。管理的交互策略：將流程，人員，信息提供給每一個(gè)企業(yè)員工，員工可以參與流程的制定，以及及時(shí)反饋企業(yè)流程問(wèn)題。

My option：企業(yè)是否需要SOA來(lái)完善自身信息化，還是根據(jù)各自的情況和財(cái)力而定。對(duì)我的架構(gòu)設(shè)計(jì)來(lái)說(shuō)，其實(shí)可以同樣推出這么一個(gè)觀念，架構(gòu)設(shè)計(jì)需要能夠融入創(chuàng)新，可以靈活擴(kuò)展，提倡每個(gè)開發(fā)工程師和架構(gòu)設(shè)計(jì)師貢獻(xiàn)idea和solution，這也是SCA的一個(gè)亮點(diǎn)和根基所在。

Key point：企業(yè)社會(huì)計(jì)算+BPM+SOA = 提升生產(chǎn)效率

Detail：首先說(shuō)一下三部分的各自功能。企業(yè)社會(huì)計(jì)算的功能：1.參與者驅(qū)動(dòng)的協(xié)作工具。2.社會(huì)搜索與專業(yè)知識(shí)的發(fā)現(xiàn)。3.組裝與Mashup（后面會(huì)談以下關(guān)于Mashup的一些了解）。BPM的功能：1.連接到交互與協(xié)作的工具。2.建立專門的協(xié)作模型（終端）。3.使企業(yè)流程民主化。SOA的功能：1.服務(wù)創(chuàng)建與啟用。2.服務(wù)的動(dòng)態(tài)發(fā)現(xiàn)。3.普遍的安全訪問(wèn)。這三部分如何提升企業(yè)生產(chǎn)率呢？企業(yè)社會(huì)計(jì)算是以用戶為中心，那么個(gè)人的智慧就能夠最大限度的貢獻(xiàn)并且提升成為企業(yè)智慧。BPM提供了實(shí)時(shí)業(yè)務(wù)可視和控制，能夠及時(shí)地糾正問(wèn)題，并且快速做出響應(yīng)。SOA將活動(dòng)和數(shù)據(jù)轉(zhuǎn)換為可重用和松耦合的服務(wù)，提高了業(yè)務(wù)開發(fā)速度，降低了開發(fā)成本，最大限度地利用已有資源。

My option：其實(shí)這三點(diǎn)就是昨天BEA對(duì)于創(chuàng)世紀(jì)平臺(tái)的構(gòu)想，將Web2.0思想+BPM可視化工具+SOA模塊化服務(wù)三者結(jié)合起來(lái)，最大限度地挖掘互聯(lián)網(wǎng)應(yīng)用的價(jià)值，提高靈活快速的開發(fā)和響應(yīng)模式，滿足客戶需求，最終達(dá)到業(yè)務(wù)級(jí)別的敏捷。說(shuō)到這兒，其實(shí)我發(fā)現(xiàn)那么多的概念，思想和規(guī)范，最終的目標(biāo)歸結(jié)起來(lái)就是阿里巴巴的考核第一條：客戶第一。互聯(lián)網(wǎng)應(yīng)用的客戶就是無(wú)數(shù)的網(wǎng)民，每個(gè)人的需求不同，每個(gè)人的喜好不同，如何開發(fā)出在這么一個(gè)廣闊的客戶群體中能夠長(zhǎng)期生存的應(yīng)用，只能夠不斷地根據(jù)用戶反饋來(lái)分析，創(chuàng)新，改變，那么應(yīng)用的設(shè)計(jì)，開發(fā)都需要敏捷。Java世界中,初學(xué)者會(huì)使用Jdk提供了很多API包，成熟的開發(fā)人員可以根據(jù)很多開源項(xiàng)目來(lái)構(gòu)建自己所需要的應(yīng)用。而到了今天，其實(shí)需要更高層次的封裝和構(gòu)建，也就是業(yè)務(wù)級(jí)別的封裝和構(gòu)建，使得互聯(lián)網(wǎng)應(yīng)用開發(fā)能夠基于這些服務(wù)組件自由組裝，拼裝出客戶所需要的應(yīng)用，極端一點(diǎn)說(shuō)，可能客戶通過(guò)一個(gè)工具就可以訂制出自己所需要的一個(gè)組合應(yīng)用。用個(gè)形象的比喻，就好比量體裁衣式的一對(duì)一的模式已經(jīng)不能夠適合這個(gè)飛速發(fā)展的互聯(lián)網(wǎng)時(shí)代，需要的是可定制化的模版式設(shè)計(jì)，客戶只需要將自己喜歡的上衣，褲子，帽子搭配好，根據(jù)自身尺寸就可以定制到自己喜歡的套裝，快速便捷。有人可能會(huì)問(wèn)，那么大家都穿成一樣豈不是很沒有個(gè)性。兩個(gè)方面看這個(gè)問(wèn)題：首先看看快餐的啟發(fā)，為什么人們那么容易接受快餐？在效率和可用性上如果能夠滿足的情況下，每個(gè)月快餐店推出的一款新產(chǎn)品就足以讓現(xiàn)代人覺得有新鮮感。（周日中午和老婆去爸爸媽媽家吃飯，聽到了樓下有喊磨剪刀戧菜刀，爸爸說(shuō)這也就這邊小鎮(zhèn)上才有的風(fēng)景了。老婆問(wèn)，那么城里面刀鈍了怎么辦？赫赫，大家都一個(gè)反應(yīng)，真的不行就換一把唄。）另一個(gè)方面就是個(gè)性化，其實(shí)在SAAS模式下多租戶的個(gè)性化也是和重要的一點(diǎn)，我們需要批量定制，同時(shí)需要個(gè)性化服務(wù)，不存在矛盾，如果覺得矛盾了，那么架構(gòu)設(shè)計(jì)需要考慮是否能夠有更好的優(yōu)化。在BEA的不同角色多視圖的演示中，就是展現(xiàn)的這么一點(diǎn)，其實(shí)個(gè)性化的并不是底層的應(yīng)用服務(wù)，而是在同一層的應(yīng)用服務(wù)池中，用Mashup的方式來(lái)結(jié)合客戶端的精彩技術(shù)構(gòu)建出豐富多彩的個(gè)性化界面，滿足用戶地個(gè)性化需求，說(shuō)到底也就是以業(yè)務(wù)組件抽象為基礎(chǔ)，多角度展現(xiàn)應(yīng)用。

上面第二點(diǎn)好像談的越來(lái)越與主題無(wú)關(guān)了，其實(shí)本來(lái)就是非針對(duì)我的課題，我自然就會(huì)遐想到其他地方去了。早晨就這么過(guò)去了，中午吃過(guò)飯，和同事去黃埔江邊逛了一下看看時(shí)間尚早，就去了一樓的廠商參展區(qū)，昨天晚上也去了一下，不過(guò)因?yàn)樘恚芏鄰S商都收拾走了，也沒有太多收獲，今天正好去看看。由于當(dāng)前比較關(guān)心Web Service安全性能方面的問(wèn)題，因此特意去了BEA的展臺(tái)看看是否有收獲，開始看到了BEA的安全介紹展臺(tái)，和展臺(tái)的朋友聊了一陣，發(fā)現(xiàn)大家的角度不同，他主要是側(cè)重于用戶鑒權(quán)和資源訪問(wèn)控制這部分的安全策略，BEA對(duì)于用戶鑒權(quán)和資源訪問(wèn)控制提供了數(shù)據(jù)庫(kù)設(shè)計(jì)和對(duì)應(yīng)的API，也沒有仔細(xì)了解就轉(zhuǎn)去了另外地方看看。走了幾步看見了一個(gè)BEA的展臺(tái)正在給幾個(gè)朋友看SOAP消息，這下我就來(lái)勁了，馬上走過(guò)去看看，果然這個(gè)展臺(tái)是我想去的展臺(tái)，正好那兩個(gè)看的人都沒有興趣走開了，我一對(duì)一的和工作人員交流，問(wèn)起了BEA現(xiàn)在對(duì)Web Service所采用的安全策略是什么？SAML2.0。性能怎么樣？（因?yàn)槲疫@邊作的壓力測(cè)試web service在附帶了WS-Security Signature以后對(duì)于CPU的消耗高了幾倍）沒做過(guò)測(cè)試，因?yàn)閯倓傞_發(fā)出來(lái)一個(gè)月。兼容性如何（對(duì)于Php,.net）？沒有做過(guò)測(cè)試。那位工作人員不是負(fù)責(zé)這個(gè)模塊開發(fā)的，所以也不是很了解，我請(qǐng)他幫忙到時(shí)候給我一些SAML 2的資料，并留了我的card給他，他也很友好的答應(yīng)給我回復(fù)。有一點(diǎn)點(diǎn)的失望，不過(guò)畢竟開發(fā)人員工作可能都很忙，這種展會(huì)都是推廣的多。

轉(zhuǎn)眼看了看表就到了1點(diǎn)40分了，趕緊去了三樓參加下午的培訓(xùn)，結(jié)果那個(gè)教室一早滿員，我只好站在邊上聽，巧的是正好有個(gè)人走了，我就安心的座了下來(lái)聽，看過(guò)BEA World2007的分會(huì)場(chǎng)安排的朋友就會(huì)知道，其實(shí)每一個(gè)會(huì)場(chǎng)兩天下午安排的都是系列性的講座，也就是每一個(gè)會(huì)場(chǎng)每天多節(jié)課都是相互關(guān)聯(lián)的，我選擇的這個(gè)是比較適合架構(gòu)師和PM聽的結(jié)合概念，設(shè)計(jì)和實(shí)踐的系列講座，所以次次人滿為患，但是今天下午聽了一節(jié)課以后，加之昨天下午的兩節(jié)，我提早和我同事說(shuō)還是早點(diǎn)走吧。

就這樣結(jié)束了我2天的BEA SOA之旅，慶幸的是還是有不少的收獲，不論是否是大會(huì)給我的啟發(fā)。前一陣子給自己的blog以及所有的IM都改了一個(gè)名字，叫做：做塊石頭沉下去。因?yàn)橛X得做一個(gè)技術(shù)人員（個(gè)性使然，目標(biāo)是做一個(gè)大Ｐ），應(yīng)該像一塊石頭一樣沉在下面，踏踏實(shí)實(shí)的做事，經(jīng)得起成功，也經(jīng)得起失敗。不過(guò)今天早晨跑步的時(shí)候又覺得，其實(shí)做技術(shù)的人，應(yīng)該做一塊可以浮起來(lái)也能夠沉的下去的石頭，去參加這樣的技術(shù)大會(huì)，就是抱著浮起來(lái)的心態(tài)，去看看新的世界，接受新的思想，石頭沉的太深太久會(huì)被淤泥掩埋，同樣會(huì)因?yàn)殚]塞而止步不前。當(dāng)然浮起來(lái)就是為了去更好的地方沉下去，河流那么大，要學(xué)的還有很多很多。
    更多分享在我的csdn的blog：http://blog.csdn.net/cenwenchu79

附加：今天早晨還看了關(guān)于mashup的兩篇文章，很不錯(cuò)，也受益匪淺。

http://www.ibm.com/developerworks/cn/webservices/ws-soa-mashups/?S_TACT=105AGX52&S_CMP=content

 

BEA World 2007 SOA第一日手記

       前一陣子工作忙，去北京參加CSDN的web2.0的機(jī)會(huì)錯(cuò)過(guò)了，這次我正好處與服務(wù)框架第一階段總結(jié)期，同時(shí)測(cè)試部的資深總監(jiān)受到BEA的邀請(qǐng)，可以帶上架構(gòu)師一起去，所以有機(jī)會(huì)去上海參加BEA World 2007 SOA大會(huì)。說(shuō)起來(lái)我們老大說(shuō)這次會(huì)議的主題和我也算是“專業(yè)對(duì)口”，不是一直在說(shuō)SCA讓SOA落地么，那么就去看看BEA怎么讓SOA走的踏踏實(shí)實(shí)的。

       會(huì)議一共分成了兩天，這兩天上午都是主題演講，下午和其他的年度大會(huì)一樣，分成很多分會(huì)場(chǎng)，自己可以根據(jù)自己的興趣去選擇所要聽的主題。因?yàn)橐矝]有太多時(shí)間去看電子郵件中的會(huì)刊，所以對(duì)主題都還不清楚，早晨起床就粗粗瀏覽了一下上午的主題，一共分成了四塊：1.超越SOA：技術(shù)融合與動(dòng)態(tài)應(yīng)用。2.江蘇電力SOA實(shí)踐。3.基礎(chǔ)架構(gòu)新探索。4.鑄就面向客戶的英國(guó)航空公司。正好是技術(shù)與實(shí)踐相結(jié)合，兩個(gè)技術(shù)案例，兩個(gè)商業(yè)案例。9點(diǎn)左右，大廳門一開，大家魚貫而入，選了貴賓席后面的第二排，就開始了我這上午半天的BEA SOA之旅。我想看我blog的多半是技術(shù)人員，我們就不講關(guān)于BEA公司的宣傳內(nèi)容，直接進(jìn)入主題，首先是總的談?wù)勥@幾部分具體介紹的內(nèi)容，然后談?wù)勎疫@個(gè)半吊子的SOA學(xué)習(xí)者的一些感觸。

       超越SOA：技術(shù)融合與動(dòng)態(tài)應(yīng)用：

既然是BEA公司的SOA年度會(huì)議，那么自然會(huì)將BEA公司對(duì)于SOA的解決方案和產(chǎn)品推向我們每一個(gè)人。這次BEA推出的是他們的SAAS的平臺(tái)Genesis（創(chuàng)世紀(jì)），SAAS今年很熱，當(dāng)然我們自己公司也是基于SAAS理念來(lái)構(gòu)筑我們的電子商務(wù)平臺(tái)，BEA是將三個(gè)熱門的思想（WEB2.0 SAAS SOA）結(jié)合在了一起，放在這個(gè)創(chuàng)世紀(jì)平臺(tái)上，這三部分任何一項(xiàng)都可以作為互聯(lián)網(wǎng)應(yīng)用開發(fā)的新理念來(lái)指導(dǎo)新一輪的互聯(lián)網(wǎng)運(yùn)動(dòng)浪潮，不過(guò)結(jié)合起來(lái)是否能夠達(dá)到想象的效果，這還需要實(shí)踐來(lái)檢驗(yàn)。BEA為我們演示了一個(gè)關(guān)于模擬汽車銷售，服務(wù)，研發(fā)以及客戶多角色共同參與的項(xiàng)目實(shí)踐，在同一個(gè)業(yè)務(wù)系統(tǒng)中，角色的不同所看到的視圖不同，同時(shí)不同角色可以相互溝通，更甚者客戶可以對(duì)于設(shè)計(jì)者提出設(shè)計(jì)需求，同時(shí)銷售可以觀察客戶行為，主動(dòng)地推薦產(chǎn)品。同時(shí)BPM的流程管理靈活性也在這個(gè)展示中成為了靈活適應(yīng)需求的一個(gè)亮點(diǎn)。

江蘇電力SOA的實(shí)踐：

一個(gè)感覺，畫圖的水平不錯(cuò)，滿眼的線路圖。

基礎(chǔ)架構(gòu)新探索：

這部分內(nèi)容其實(shí)是對(duì)于第一部分的介紹做了部分的系統(tǒng)架構(gòu)介紹，也就是對(duì)于剛在的Genesis平臺(tái)作了一個(gè)總體的概述，以及一個(gè)遠(yuǎn)景規(guī)劃。闡述了Genesis平臺(tái)的層次結(jié)構(gòu)設(shè)計(jì)，主要分成四個(gè)層次：

User Interaction

Business Process

Service Network

Hosting

最低下一層叫作Hosting，并不是我們常規(guī)考慮的硬件Hosting，而是指的我們各個(gè)業(yè)務(wù)系統(tǒng)原來(lái)的各種實(shí)現(xiàn)，也就是我們常說(shuō)的各種信息孤島或者就是不同的遺留應(yīng)用或者針對(duì)SAAS來(lái)說(shuō)就是ISV的應(yīng)用，這些Hosting常常技術(shù)實(shí)現(xiàn)不同，但是希望能夠被融合起來(lái)，發(fā)揮更大的價(jià)值。Service Network是SOA概念中的Service Domain，這一層往往來(lái)說(shuō)是我們現(xiàn)在比較關(guān)注去實(shí)現(xiàn)的一層，因?yàn)檫@層是SOA是否能夠真正達(dá)到服務(wù)融合，服務(wù)復(fù)用的基礎(chǔ)，如何讓服務(wù)注冊(cè)，路由，交互，為上層提供靈活組合的基礎(chǔ)，是一個(gè)關(guān)鍵性的問(wèn)題。Business Process層的作用主要是通過(guò)BPM來(lái)將下層的Service串起來(lái)，發(fā)揮服務(wù)靈活響應(yīng)需求變化的要求。User Interaction這層次屬于比較高要求的層次，其實(shí)也就是結(jié)合了Web2.0的一個(gè)特性，那就是客戶參與和貢獻(xiàn)，使得產(chǎn)品更加具有活力。

英國(guó)航空公司的案例：

另一個(gè)感覺，好多數(shù)字展示了英航在互聯(lián)網(wǎng)信息化的成就。

以上是我上午聽了四個(gè)主題講座的如實(shí)感受和介紹，后面把我自己的一些新的體會(huì)感悟說(shuō)一下。

       前面說(shuō)了，ASF（SCA-based Application Service Framework）第一期正好告一段落，其實(shí)在周二來(lái)上海之前，我正在畫第一期的結(jié)構(gòu)圖以及后續(xù)需要規(guī)劃和完善的功能圖，當(dāng)時(shí)其實(shí)有一些迷惘，作為我來(lái)說(shuō)，不能和Tuscany一樣做純粹架構(gòu)設(shè)計(jì)和實(shí)現(xiàn)，我需要關(guān)心業(yè)務(wù)部門的需求，根據(jù)需求來(lái)考慮框架功能實(shí)現(xiàn)優(yōu)先級(jí)。根據(jù)首架的需求，我的第二期內(nèi)容在年內(nèi)暫時(shí)大部分內(nèi)容是對(duì)于前期框架Web Service安全性能優(yōu)化，多種分布式場(chǎng)景技術(shù)實(shí)現(xiàn)及測(cè)試，跨平臺(tái)客戶端兼容性的測(cè)試，最后一點(diǎn)就是ISV服務(wù)互通的架構(gòu)支撐預(yù)研。總結(jié)了前期的工作，同時(shí)把一些新的功能點(diǎn)做了羅列（對(duì)于基礎(chǔ)框架生命周期的維護(hù)和監(jiān)測(cè)，擴(kuò)展點(diǎn)的增加），同時(shí)也對(duì)性能優(yōu)化方案作了初步的制定，但是總感覺好像有些迷失方向的感覺，難道按照現(xiàn)有需求就只需要完成這些就達(dá)到了我們ASF的階段性交付了么，對(duì)于ISV服務(wù)互通采用什么策略呢？正好周二也要來(lái)上海，也沒有再多想，不過(guò)雖然剛才說(shuō)了早晨的演講就這么些，但是對(duì)我腦子里那些問(wèn)題倒是正好給了一些spark，下面就將這些spark一一道來(lái)。

       SPARK One：DBA。不要誤會(huì)，不是我們公司的DBA，呵呵，是Dynamic Business Application的縮寫。這個(gè)詞匯是我第一次聽到，也是BEA公司給我的一個(gè)新的概念，叫做動(dòng)態(tài)業(yè)務(wù)應(yīng)用。它的概念其實(shí)就是指服務(wù)于服務(wù)之間組成了業(yè)務(wù)應(yīng)用可以根據(jù)用戶需求靈活變化，成為動(dòng)態(tài)而非過(guò)去，由需求，建模，概要設(shè)計(jì)，詳細(xì)設(shè)計(jì)，編碼實(shí)現(xiàn)而產(chǎn)生出來(lái)的傳統(tǒng)商業(yè)應(yīng)用。應(yīng)為傳統(tǒng)應(yīng)用最大的弱點(diǎn)就是固化和僵硬，面對(duì)現(xiàn)在互聯(lián)網(wǎng)應(yīng)用的多變性和客戶化，傳統(tǒng)的設(shè)計(jì)理念和模式已經(jīng)很難適應(yīng)這種應(yīng)用場(chǎng)景，因此需要一種敏捷的開發(fā)模式，面向服務(wù)+BPM+ESB，可能這些技術(shù)早就都已經(jīng)存在并且也都曾經(jīng)被廣為推崇，但是結(jié)合起來(lái)所能達(dá)到的效果確不是1+1+1=3的效果。同時(shí)結(jié)合Web2.0的特質(zhì)，倡導(dǎo)參與貢獻(xiàn)多于遵循使用，這種靈活的框架模式無(wú)疑成為應(yīng)用平臺(tái)很好的一個(gè)理念。此時(shí)我回顧了我這段時(shí)間SCA的一些工作，當(dāng)前的服務(wù)框架已經(jīng)能夠做到讓開發(fā)者不用過(guò)多關(guān)心業(yè)務(wù)邏輯以外的內(nèi)容，業(yè)務(wù)模塊化和面向服務(wù)交互的理念已經(jīng)深入開發(fā)過(guò)程中，但是考慮一下提到的以后ISV應(yīng)用的互通解決策略，就可以發(fā)現(xiàn)，其實(shí)由于當(dāng)前我們所開發(fā)的系統(tǒng)首先都是新系統(tǒng)，采用同樣的技術(shù)架構(gòu)，雖然ISV和我們的交互已經(jīng)是異構(gòu)環(huán)境，但是我們系統(tǒng)之間處于業(yè)務(wù)流程相對(duì)來(lái)說(shuō)比較固定，服務(wù)組裝交互實(shí)現(xiàn)可以定義好的情況，也就是說(shuō)是一種服務(wù)靜態(tài)組裝的過(guò)程。但是對(duì)于未來(lái)我們的ISV應(yīng)用來(lái)說(shuō)，首先都是異構(gòu)的實(shí)現(xiàn)，然后就是在ISV之間串聯(lián)未必可以通過(guò)靜態(tài)配置和設(shè)計(jì)事先確定，同時(shí)針對(duì)用戶行為分析是否可以及時(shí)動(dòng)態(tài)調(diào)整服務(wù)流程，都是一個(gè)動(dòng)態(tài)的過(guò)程，這也給我一個(gè)啟示，那就是第二期的互通，需要量體裁衣（最后會(huì)提到為什么要用這個(gè)詞），來(lái)構(gòu)造適合的Service Network和 Business Work Flow。當(dāng)然這個(gè)過(guò)程還是和我先前說(shuō)的一樣，按照需求的優(yōu)先級(jí)逐步實(shí)現(xiàn)，按需而進(jìn)。

       Spark Two：User Interaction。其實(shí)這個(gè)概念應(yīng)該是我在我同事北京帶回來(lái)程序員web2.0增刊中所看到的一個(gè)理念。我想現(xiàn)實(shí)生活中其實(shí)這類工作老早開展起來(lái)了，就好比你去商場(chǎng)買東西給你一個(gè)反饋表，讓你填寫一下，那么那個(gè)產(chǎn)品會(huì)根據(jù)客戶的反饋?zhàn)饕欢ǖ母倪M(jìn)。只是今天BEA給我展示的時(shí)候，通過(guò)不同角色所看到的用戶操作界面的個(gè)性化和專業(yè)化，讓User Interaction這個(gè)概念在技術(shù)上有了實(shí)實(shí)在在的表現(xiàn)，同時(shí)在基于剛才提到的DBA基礎(chǔ)上，客戶的反饋在最最極端的情況下都可以直接主導(dǎo)流程（即客戶可以修改流程），不過(guò)BEA也說(shuō)了這還是需要安全策略的配置允許的。那么作為我們未來(lái)互聯(lián)網(wǎng)應(yīng)用的場(chǎng)景下，這種面向客戶的交互其實(shí)對(duì)于互聯(lián)網(wǎng)應(yīng)用來(lái)說(shuō)無(wú)疑是很有吸引力的。

       Spark Three：社會(huì)計(jì)算。這個(gè)詞很新鮮，也是今天第一次聽到，下午也在一個(gè)分會(huì)場(chǎng)站了50分鐘（會(huì)場(chǎng)太小，走錯(cuò)以后再回來(lái)就只能站著了）。社會(huì)計(jì)算和Web 2.0中的Social networking有一定的概念上的類似，其實(shí)就是溝通，也就是團(tuán)體的溝通，個(gè)體的溝通，通過(guò)什么樣的有效手段來(lái)溝通，rss,mash up,blog，都是一種手段，在上面的例子里面，買車子的客戶可以通過(guò)blog反饋給Designer，Sales可以push給客戶一個(gè)小短片來(lái)展示給客戶看新的產(chǎn)品，這些都是一些很有效的溝通手段，其實(shí)溝通就是為了雙贏，互聯(lián)網(wǎng)貿(mào)易除了安全這個(gè)大問(wèn)題以外，剩下的最大問(wèn)題就是如何讓買賣雙方因?yàn)闇贤▎?wèn)題導(dǎo)致交易受挫。同時(shí)社區(qū)化是應(yīng)用的互通價(jià)值最大化的有效生態(tài)環(huán)境保證。

       Spark Four：客戶行為分析。其實(shí)也是一種手段，不過(guò)指的是自學(xué)習(xí)的一種行為分析，類似于Google對(duì)于客戶行為分析。如果留意一下，我們?cè)谌粘Ｋ阉髦腥绻阉鞯膬?nèi)容經(jīng)常會(huì)出現(xiàn)，那么Google就會(huì)智能化的提高客戶體驗(yàn)。

       其實(shí)，對(duì)我最有啟發(fā)的還是第一點(diǎn)，同時(shí)對(duì)于我來(lái)說(shuō)有很多的問(wèn)題需要去深入了解和分析，同時(shí)結(jié)合當(dāng)前框架以及業(yè)務(wù)場(chǎng)景做量體裁衣，這么說(shuō)的目的其實(shí)在于聽過(guò)了BEA的創(chuàng)世紀(jì)平臺(tái)規(guī)劃后，整個(gè)框架設(shè)計(jì)和理念都是讓人覺得很有創(chuàng)新和價(jià)值的，但是BEA規(guī)劃到了2009年，他的功能點(diǎn)和橫向縱向切面都作了規(guī)劃，但是這么一個(gè)龐然大物對(duì)于ASF來(lái)說(shuō)并不合適，ASF也并不需要朝著這個(gè)方向發(fā)展。阿里的人都喜歡用武俠小說(shuō)來(lái)打比方，我就打個(gè)比方，BEA為韋小寶提供了一套盔甲的解決方案，不論從外觀和安全性上來(lái)說(shuō)都是完美無(wú)缺的，不過(guò)韋小寶其實(shí)需要的是一件金絲甲，輕輕薄薄的，跑路快，又可以刀槍不入。同時(shí)有什么問(wèn)題隨時(shí)可以修補(bǔ)增改?？蚣茉O(shè)計(jì)的敏捷性和框架問(wèn)題相應(yīng)的敏捷性是同樣重要的，龐大的項(xiàng)目版本周期長(zhǎng)，為了不同客戶訂制困難，那么就是另一個(gè)固化和僵硬的體現(xiàn)。當(dāng)然設(shè)計(jì)框架幾個(gè)關(guān)鍵點(diǎn)需要把握：擴(kuò)展性，規(guī)范通用性（不要用私有的協(xié)議），學(xué)習(xí)基礎(chǔ)上的創(chuàng)新。

       上面是上午的內(nèi)容，其實(shí)為什么花了那么多字寫了上午的內(nèi)容，其實(shí)是下午的內(nèi)容沒什么好說(shuō)了^_^

       下午一共參加了四個(gè)分會(huì)場(chǎng)，一個(gè)就是剛才提到的站了50分鐘的社會(huì)計(jì)算和Web2.0的講座，概念性的介紹，不過(guò)擴(kuò)展了思路。Liquid Infrastructure for Enterprise Java Application，這個(gè)課程名字不錯(cuò)吧，流動(dòng)性的框架針對(duì)企業(yè)及的java應(yīng)用，結(jié)果去了一聽，是談到使用vmware的產(chǎn)品，如何在服務(wù)器池中部署企業(yè)應(yīng)用，提高效率和節(jié)約成本，晚上吃飯的時(shí)候和我們的測(cè)試部老大談起了這個(gè)，他剛進(jìn)公司就做了這樣的實(shí)施，得卻對(duì)于效能有一定的幫助，不過(guò)對(duì)我原先的理解就偏差大了，早知道仔細(xì)看看簡(jiǎn)介了。最后兩節(jié)課是SOA一個(gè)培訓(xùn)的聯(lián)系課程，今天下午四節(jié)，明天下午4節(jié)，我今天下午就參加了兩節(jié)，最后兩節(jié)，一節(jié)是談到了關(guān)于SOA的治理，一位香港的朋友介紹的，聽了一節(jié)課，就知道他最后一句說(shuō)出了他SOA治理的名言：SOA治理最難的就是搞定內(nèi)部關(guān)系，技術(shù)從來(lái)就不是問(wèn)題。赫赫，這句至理名言好象在很多行業(yè)中盛行。第二節(jié)課是對(duì)SOA技術(shù)的一個(gè)匯總，講師開始整一個(gè)介紹了Web Service的框架，最后才提了一句孤立的Web Service不是SOA，真是畫龍點(diǎn)睛啊，要是沒有這句話，我真的要為他捏把汗了，不過(guò)他發(fā)的BEA對(duì)于SOA的最后幾個(gè)領(lǐng)域模型介紹還是應(yīng)該蠻有幫助的，不過(guò)因?yàn)闀r(shí)間緊迫，他沒有講這些重點(diǎn)，而是把時(shí)間讓給了最后BEA認(rèn)證介紹的講師。我么，提起包包，吃晚飯去了。

       這就是我第一天BEA的手記，明天是否會(huì)下午全部聽完，這就要看我們同行老大的安排了，不過(guò)還是期待明天上午的主題演講能夠有一些Spark，讓我也能有所收獲。這次也看見一些同行的朋友提問(wèn)，有些是技術(shù)型的，但是聽那兩個(gè)SOA講座的有不少還是理論先行的，這感覺SOA又開始在這兒“漂浮”起來(lái)。

       總的來(lái)說(shuō)，其實(shí)參加這樣的大會(huì)我也早就有心理準(zhǔn)備，未必能夠真的了解很多核心的解決方案，只是可以接觸一些新的思想，新的碰撞可能會(huì)給自己的工作帶來(lái)一些靈感和啟發(fā)，后續(xù)周末或者下周就可以把第一階段總結(jié)和第二階段的思考再?gòu)男乱?guī)劃一下。轉(zhuǎn)眼就11點(diǎn)半了，洗澡睡覺，期待明天的碰撞，不論是否有火花。

 

Trackback: http://tb.blog.csdn.net/TrackBack.aspx?PostId=1926332

 

       上周周四快速了結(jié)了對(duì)于搜索引擎的集成以后，又從新回到對(duì)ISV WebService接口集成和測(cè)試的支持中。測(cè)試部發(fā)現(xiàn)了一個(gè)很棘手的問(wèn)題，將WS-Security集成到了ASF(應(yīng)用服務(wù)框架)中以后，接口中如果出現(xiàn)中文，就會(huì)導(dǎo)致異常拋出。這個(gè)問(wèn)題相關(guān)的同事已經(jīng)跟蹤了1，2天了，但是還是沒有頭緒，離周末還有一天，我趕緊接手，希望能夠趕在測(cè)試部下周整體測(cè)試前修復(fù)這個(gè)問(wèn)題。其實(shí)前面做了那么多工作，如果一旦這個(gè)問(wèn)題被卡住，那么就會(huì)前功盡棄了。

       首先工作就是要確定，究竟是加了WS-Security導(dǎo)致中文問(wèn)題，還是本來(lái)WS的中文返回就有問(wèn)題。簡(jiǎn)單的做了單元測(cè)試驗(yàn)證了一下，確認(rèn)了的卻是增加了WS-Security導(dǎo)致的中文作為參數(shù)或者作為返回值都回拋出異常。根據(jù)異常的翻譯來(lái)看，就是因?yàn)樵谙Ⅲw中出現(xiàn)了非法字符。前幾天一位同事讓我?guī)兔?/span>WS的一個(gè)中文問(wèn)題時(shí)發(fā)現(xiàn)，在Http頭上對(duì)方返回的編碼方式是utf-8而在SOAP消息體中，XML的編碼方式卻寫著gbk，所以客戶端解析器在解析SOAP消息中的xml時(shí)候采用的是Utf-8的編碼方式，解析出來(lái)的中文自然是不對(duì)的。同時(shí)翻閱了一下資料，在xml  1.0的內(nèi)部二進(jìn)制嵌入必須用base64編碼一下，否則是不允許出現(xiàn)非法字符，在xml 1.1已經(jīng)對(duì)這部分作了擴(kuò)展。所以這次集成了WS-Security產(chǎn)生的問(wèn)題，可能就會(huì)因?yàn)檫@兩種原因造成的。

       但是事實(shí)上并不是這兩方面的原因造成，Axis2和當(dāng)前很多Web Service框架都采用了Stax方式的Jaxp(Java API for xml processing)，在帶WS-Security和不帶的兩種流程中，所用的Jaxp的讀寫解析器采用的是不同的解析器，所以才會(huì)出現(xiàn)了上面的問(wèn)題，因此還是要從根本上去了解Stax模式的Jaxp框架結(jié)構(gòu)及工作模式。

Stax(Streaming API for XML)

背景

Stax不是很新的概念了，在2002年就被提出，在2004年被JCP作為編號(hào)為173的JSR正式發(fā)布。因此在我們?nèi)粘ｉ_發(fā)中如果說(shuō)到Jsr 173就是關(guān)于Streaming API for XML的內(nèi)容，同時(shí)，在lib中如果列了jsr-173.jar或者stax-api.jar也就是對(duì)于Streaming API for XML的接口定義包，同時(shí)這個(gè)包內(nèi)只是定義框架接口，并沒有具體的實(shí)現(xiàn)，JSR 173是接口定義規(guī)范，各個(gè)開源組織或者廠商都可以根據(jù)規(guī)范實(shí)現(xiàn)自身的Stax，這個(gè)后面的結(jié)構(gòu)介紹中就會(huì)提到。Stax的創(chuàng)始者是BEA的兩位系統(tǒng)工程師，所以在我們?nèi)蘸蟮某鲥e(cuò)中，如果類似于com.bea.xml.stream.XXX  Class not found 等錯(cuò)誤，多半是在所有的lib庫(kù)中沒有對(duì)應(yīng)的Stax的具體實(shí)現(xiàn)，只有接口定義。當(dāng)前支持JSR的實(shí)現(xiàn)有Sun,Bea,Oracle,Breeze Factor和其他的一些開源項(xiàng)目（最出名的就是codehaus的woodstox）。

在Jdk 1.6種已經(jīng)把Stax集成到了內(nèi)部(javax.xml.transform.stax)，順便說(shuō)一句的就是，在jdk1.5中，范型和對(duì)于Collection的增強(qiáng)是很成功的，而在jdk1.6中雖然沒有1.5的很多新特性的融入，但是仔細(xì)觀察一下就可以發(fā)現(xiàn)，其實(shí)對(duì)于xml和web service的處理和支持作了不少的增強(qiáng)，其實(shí)也是針對(duì)當(dāng)前SOA的大趨勢(shì)作的技術(shù)方面的增強(qiáng)，很多概念和實(shí)現(xiàn)其實(shí)很早就在我們的應(yīng)用開發(fā)中得到體現(xiàn)，個(gè)人覺得這也是Sun在開源后的最大受益之處（利用開源來(lái)匯集更多的亮點(diǎn)和精華），包括對(duì)于1.7的OSGI的暢想，其實(shí)都是大勢(shì)所趨。這讓我想起了昨天看程序員增刊第一部分對(duì)于Web2.0中的特質(zhì)的一項(xiàng)描述，利用集體智慧，有所放棄有所收獲，放棄了獨(dú)享的知識(shí)專利（當(dāng)然核心部分可以保留），獲得的是廣泛的集體參與所帶來(lái)的智慧亮點(diǎn)。

Stax結(jié)構(gòu)體系和功能描述

自Stax的提出開始，其本身就只是一個(gè)框架性的規(guī)范，并沒有具體的實(shí)現(xiàn)約束，這也為各個(gè)開發(fā)商和開源組織認(rèn)可這個(gè)規(guī)范提供了一個(gè)最基本的優(yōu)勢(shì)條件。這點(diǎn)也是當(dāng)前所有的有生命力的框架或者系統(tǒng)所具備的最基本的特點(diǎn)之一，開放性，制定接口，規(guī)范流程，但是不約束具體的實(shí)現(xiàn)。

功能描述：

       這是我第一次去看JSR的描述，JSR是Java Specification Request的縮寫，也就是規(guī)范申請(qǐng)，其中所需要填的描述中就詳細(xì)的寫出了申請(qǐng)為JSR的目的（這比類似于國(guó)內(nèi)申請(qǐng)專利之類的，不過(guò)感覺更為簡(jiǎn)潔和開放）。

       Streaming API for XML 描述的是一種基于java用pull方式來(lái)處理XML的API。Streaming API通過(guò)暴露簡(jiǎn)單的Iterator模式API提供給開發(fā)者處理XML的控制權(quán)。同時(shí)當(dāng)前兩種關(guān)于XML的規(guī)范，JAXB和JAX-RPC也十分需要通過(guò)Stax模式來(lái)處理xml。

       其實(shí)早在Stax出現(xiàn)之前，jdk中的已經(jīng)有了jaxp家族，sax和dom，這兩種API分別針對(duì)不同的應(yīng)用場(chǎng)景作了很好的封裝。SAX是用于處理XML的事件驅(qū)動(dòng)方法，由很多的回調(diào)函數(shù)組成。而DOM則是將XML解析成為內(nèi)存中的樹狀結(jié)構(gòu)，然后通過(guò)API來(lái)對(duì)XML中的元素和標(biāo)簽進(jìn)行分析。SAX速度快，需要的內(nèi)存小，但是無(wú)法修改XML，而DOM可以提供對(duì)于XML任意節(jié)點(diǎn)的訪問(wèn)，同時(shí)也可以寫入內(nèi)容到XML，但是缺陷就是速度慢，消耗內(nèi)存大，需要把XML全部解析完以后才能夠繼續(xù)操作。

       網(wǎng)上對(duì)于Stax的好處有很多很詳細(xì)的文檔，就我自己的學(xué)習(xí)理解來(lái)看，比較重要的幾點(diǎn)就是：1.pull方式替代了push。Stax從名字上就可以看出和SAX十分相像，其實(shí)很大的一點(diǎn)不同就是在于Pull替代了Push。Sax可以實(shí)現(xiàn)很多固定的回調(diào)函數(shù)，然后在執(zhí)行XML解析的過(guò)程中不斷的被調(diào)用和處理，但是缺點(diǎn)很明顯，首先被動(dòng)回調(diào)導(dǎo)致開發(fā)者無(wú)法根據(jù)場(chǎng)景來(lái)動(dòng)態(tài)選擇如何裁減事件處理需求，同時(shí)無(wú)法同時(shí)處理多個(gè)XML。2.Stax比SAX可以更靈活定制事件處理?xiàng)l件。3.Stax可以寫入XML。4.Stax除了和SAX提供了一樣的API模式的處理方式，還封裝了Event模式的對(duì)象處理方式。5.Stax比DOM性能高，應(yīng)用場(chǎng)景廣泛，特別是當(dāng)前很多應(yīng)用處理xml數(shù)據(jù)流時(shí)都需要邊讀邊分析，當(dāng)流結(jié)束以后就自動(dòng)關(guān)閉了，此時(shí)可能已經(jīng)將流釋放，然而此時(shí)在作DOM分析已經(jīng)無(wú)法實(shí)現(xiàn)，而Stax正好滿足了這種需求。因此對(duì)于Stax適用范圍的描述如下：需要清晰，有效的pull-parsing模式分析XML，另一方面也需要靈活的對(duì)XML Stream進(jìn)行讀寫操作，需要?jiǎng)?chuàng)建新的事件類型和擴(kuò)展XML的文檔類型以及屬性的情況。

Stax體系結(jié)構(gòu)：

       下圖中是Stax接口部分的類圖，基本上已經(jīng)包括了Stax規(guī)范中的大部分接口定義。

圖 Stax接口類圖

 

 

兩類API設(shè)計(jì)接口：Cursor API，Iterator API

       Cursor API的兩個(gè)接口定義為：XMLStreamReader和XMLStreamWriter。這部分接口提供了類似于游標(biāo)方式的方法定義，能夠在XML解析過(guò)程中，從XML文檔流獲取或者寫入信息，同樣也類似于游標(biāo)讀取信息一樣，只能前進(jìn)不能后退，在任意一個(gè)時(shí)刻能夠返回XML中的部分信息片斷。

       Iterator API的兩個(gè)接口定義為：XMLEventReader和XMLEventWriter。Iterator API將XML輸入流看作了一組離散的事件對(duì)象，這些XML流讀入并被Parser分析，然后被解析成為這類事件對(duì)象，在開發(fā)者的應(yīng)用程序中，可以主動(dòng)的Pull（拉）出需要處理的事件對(duì)象。

對(duì)于這兩種API的選擇基于下面幾點(diǎn)：

1.內(nèi)存有限類似于J2ME可以選擇使用cursor API。

2.性能是第一優(yōu)先級(jí)，創(chuàng)建底層的庫(kù)或者框架結(jié)構(gòu)時(shí)使用cursor API更有效。

3.如果需要類似于管道處理XML，使用Iterator API。

4.如果想要修改事件流，使用Iterator API。

5.如果需要應(yīng)用能夠處理可插入的處理流程，使用Iterator API。

6.總的來(lái)說(shuō)，如果你對(duì)性能要求不是很高，建議使用Iterator API，因?yàn)樗`活和易擴(kuò)展。

工廠類

Stax采用的是抽象工廠模式來(lái)動(dòng)態(tài)的根據(jù)環(huán)境配置加載不同的Stax的實(shí)現(xiàn)。在我原先查找問(wèn)題的時(shí)候看來(lái)也是產(chǎn)生WS-Security中文問(wèn)題的根源，當(dāng)帶WS-Security的時(shí)候?qū)τ?/span>XML流分析和讀寫采用了codehaus的woodstox包中針對(duì)Stax的Cursor API實(shí)現(xiàn)，而不帶WS-Security時(shí)對(duì)于XML流分析和讀寫采用的是axis2中實(shí)現(xiàn)的Cursor API。 

工廠類都是抽象類，因此都需要實(shí)例來(lái)繼承實(shí)現(xiàn)，如何選取工廠類的實(shí)現(xiàn)，并且通過(guò)工廠類來(lái)生成兩套API的實(shí)現(xiàn)，按照以下的規(guī)則來(lái)載入：（以XMLInputFactory為例）

1.       讀取系統(tǒng)屬性，看配置中是否有javax.xml.Stream.XMLInputFactory等配置的描述。

2.       讀取Jre的lib/xml.stream.properties文件來(lái)讀取配置。

3.       從可讀取的Jar中讀取在META-INF/services/javax.xml.stream.XMLInputFactory文件來(lái)判斷載入哪一個(gè)的工廠類實(shí)現(xiàn)。

4.       使用默認(rèn)的XMLInputFactory實(shí)例。

其他接口的說(shuō)明

       XMLResolver接口可以在分析XML的過(guò)程中對(duì)于某些資源解析定位到定義和實(shí)現(xiàn)的方法上。

       XMLReporter接口用于報(bào)告所有的非致命的錯(cuò)誤，致命錯(cuò)誤通過(guò)XMLStreamException來(lái)報(bào)告。

對(duì)于接口使用細(xì)節(jié)可以參看sun公司的webservice tutorial。

WS-Security中文問(wèn)題解決

       在對(duì)新一代的Jaxp做了基本學(xué)習(xí)以后，那么對(duì)于axis2如何處理SOAP消息有了基本的了解，在跟蹤了代碼調(diào)試以后，發(fā)現(xiàn)問(wèn)題主要是出在axis2的rampart模塊的Axis2Util類，其中的兩個(gè)方法getDocumentFromSOAPEnvelope(SOAPEnvelope env, boolean useDoom)和getSOAPEnvelopeFromDOMDocument(SOAPEnvelope env, boolean useDoom)。在有WS-Security和沒有的不同情況下，傳入的參數(shù)useDoom為true和false，導(dǎo)致走了兩個(gè)不同的解析流程。當(dāng)useDoom為true的時(shí)候，axis2通過(guò)SOAPEnvelope對(duì)象和axis2的Streaming parser來(lái)解析和構(gòu)建Dom Document。當(dāng)useDoom為false的時(shí)候，首先將SOAPEnvelope對(duì)象讀入字節(jié)數(shù)組流，然后在根據(jù)Stax工廠生成實(shí)例，并且構(gòu)造出StAXSOAPModelBuilder，然后返回通過(guò)StAXSOAPModelBuilder獲得的Dom Document對(duì)象。

       察看了一下調(diào)用者傳入?yún)?shù)的地方，其實(shí)是通過(guò)MsgContext的參數(shù)配置來(lái)確定采取什么策略，因此只需要將axis2.xml中配置增加一個(gè)parameter，設(shè)置useDoom為true即可?；蛘呔褪亲鲆粋€(gè)handle或者phase在Inflow和outflow中配置這個(gè)參數(shù)即可。

       搞了那么久也就是修改一個(gè)配置，如果光從結(jié)果看，花了兩天時(shí)間真是比較浪費(fèi)，但是如果從過(guò)程來(lái)看，那么這兩天時(shí)間所學(xué)到的那還是比較值的。

       由于第二天是周日，問(wèn)題解決了也就沒有再繼續(xù)細(xì)究。但是周日早晨晨跑的時(shí)候，給自己列了三個(gè)疑問(wèn)，首先為什么走系統(tǒng)獲取的Stax會(huì)有問(wèn)題，再則如果我用sun的jaxp實(shí)現(xiàn)來(lái)替換是否能夠解決此問(wèn)題而不需要配置useDoom。useDoom兩種處理模式究竟有什么區(qū)別。

問(wèn)題的再次細(xì)究

       周一上班的時(shí)候還是記得周日早晨提出的三個(gè)問(wèn)題，因此就仔細(xì)的再分析了一下這三個(gè)問(wèn)題。

首先是采取sun的jaxp替換，這個(gè)實(shí)現(xiàn)在sun的jwsdp中已經(jīng)包含了，替換以后然后強(qiáng)制在jre的配置文件中指定使用，出現(xiàn)了異常，看來(lái)直接使用還不行，需要針對(duì)一些參數(shù)作配置，特別是對(duì)namingspace的解析，同時(shí)也沒有花更多時(shí)間去細(xì)研究。

再則，仔細(xì)回想了一下我在定位這個(gè)問(wèn)題的時(shí)候做的實(shí)驗(yàn)，我曾經(jīng)試圖將中文先用Base64編碼，然后服務(wù)端接收到以后回傳，客戶端再用Base64解碼，沒有任何問(wèn)題。有時(shí)候換一個(gè)中文或者中文前后有字母數(shù)字，也可以正常處理，同時(shí)在跟蹤代碼過(guò)程中看過(guò)SOAP消息中的內(nèi)容，內(nèi)容是亂碼。這讓我有點(diǎn)啟發(fā)，例如我輸入?yún)?shù)為“岑文初”每次始終都會(huì)出錯(cuò)，如果輸入為“岑文”，就沒有問(wèn)題，看了看內(nèi)存內(nèi)的變量，發(fā)現(xiàn)，原來(lái)如果是“岑文初”的時(shí)候SOAP消息中的標(biāo)簽封閉被破壞，如果是“岑文”,雖然是亂碼，但是沒有破壞標(biāo)簽的封閉。

仔細(xì)看了看上次提到的兩個(gè)流程，其實(shí)兩個(gè)流程除了parser不同以外，對(duì)于SOAPEnvelope的處理也是不一樣的，走UseDoom的是直接將分析好的Dom對(duì)象返回，不做附加的處理，只是根據(jù)Envelope生成了SOAP的解析器以及配置了Stax的Cursor的兩個(gè)接口實(shí)現(xiàn)類。不走UseDoom的情況則是完全將SOAPEnvelope再次序列化并且通過(guò)外部的Stax實(shí)現(xiàn)來(lái)解析和處理，但是問(wèn)題就出在對(duì)象到字節(jié)流的序列化過(guò)程，默認(rèn)的是使用了SOAP規(guī)定的utf-8編碼方式，因此在這個(gè)過(guò)程中有些中文的內(nèi)容就破壞了SOAP的消息包XML的標(biāo)簽合法性，導(dǎo)致外部解析器分析出現(xiàn)問(wèn)題。如果將傳入和傳出的中文都編碼成utf-8沒有任何問(wèn)題。

問(wèn)題總結(jié)就是其實(shí)根源在于對(duì)于內(nèi)容中的中文字符編碼時(shí)采用Utf-8破壞了xml的封閉性，而我開始采用的useDoom正好規(guī)避了這個(gè)過(guò)程，也就自然通過(guò)了。但是就其設(shè)計(jì)本身來(lái)說(shuō)，rampart應(yīng)該是贊同使用useDoom為false的方式，這才是真正的Stax的模式，同時(shí)有很好擴(kuò)展性。另一方面?zhèn)€人覺得類似于這種抽象工廠機(jī)制來(lái)說(shuō)，最好不要在系統(tǒng)變量或者jre中強(qiáng)制指定，這樣會(huì)導(dǎo)致一些意想不到的問(wèn)題，雖然是規(guī)范，但是細(xì)節(jié)實(shí)現(xiàn)畢竟有差異，因此一些特殊的開源框架的一些莫名其妙的xml解析問(wèn)題也常常由于這些引起。

幾點(diǎn)感悟

       靈活的SPI（Service Provider Interface）模式是當(dāng)前框架設(shè)計(jì)以及底層設(shè)計(jì)的必要特質(zhì)，開放才會(huì)發(fā)展得更好。

       靈活是把雙刃劍，在遇到一些靈活的框架設(shè)計(jì)時(shí)，首先必須了解其原理和結(jié)構(gòu)，然后根據(jù)實(shí)踐來(lái)驗(yàn)證問(wèn)題的緣由。

       抽象工廠還是有適用場(chǎng)景的，類似于Jaxp和SCA等框架的實(shí)現(xiàn)，抽象工廠以及利用Jar的META-INF/services來(lái)載入SPI的實(shí)現(xiàn)是IOC的一種很好的補(bǔ)充。

     更多內(nèi)容請(qǐng)?jiān)L問(wèn)我的blog：http://blog.csdn.net/cenwenchu79

和第三部分同樣，這部分內(nèi)容其實(shí)應(yīng)該在后面才對(duì)，不過(guò)當(dāng)前工作既然做了，也需要寫下來(lái)分享，那么就提前插隊(duì)到成長(zhǎng)記錄當(dāng)中吧。看了這篇文章以后，可能給人的感覺是有點(diǎn)偏離服務(wù)框架的內(nèi)容。的卻，如果純粹從技術(shù)方面來(lái)說(shuō)，這部分應(yīng)該不屬于服務(wù)框架范疇。拿杭州作個(gè)例子，杭州是全國(guó)唯一一個(gè)景點(diǎn)不但不漲價(jià)，反而免門票的地方，原因何在，無(wú)非是管理者看得遠(yuǎn)，景點(diǎn)的門票收益看得到，但是是小頭，免去門票帶來(lái)的商機(jī)那才是金礦。框架其實(shí)也是這樣，如果客戶用起來(lái)不方便，甚至都不能用，那么框架再好，也會(huì)有人笑話你是個(gè)高高在上的理論主意者，這種框架適合于教學(xué)，而非實(shí)用?，F(xiàn)在也是在邁出平臺(tái)服務(wù)框架兼容性的第一步，那天和同事們開玩笑說(shuō)，以前聯(lián)通移動(dòng)的wap業(yè)務(wù)，好在大家的開發(fā)語(yǔ)言都相似，isp只需要兼容各種手機(jī)客戶端，我們現(xiàn)在要做的就是兼容各種不同開發(fā)語(yǔ)言，平臺(tái)，以后甚至瀏覽器，我們這種全部都搞通的人出去，那就真的是搶手貨了。

周一測(cè)試部和ISV support小組的日?qǐng)?bào)反映，.net的客戶端對(duì)于復(fù)雜對(duì)象數(shù)組返回有問(wèn)題，緊接著就是.net客戶端對(duì)于web service的wsse無(wú)法調(diào)試通過(guò)。我以前沒有接觸過(guò).net，沒辦法，硬著個(gè)頭皮裝了個(gè)vs2005和WSE 3。前面一個(gè)問(wèn)題就是我前面半周間斷性的解決的問(wèn)題，在第三篇記錄中也寫了。后面的問(wèn)題比較緊急，也比較嚴(yán)重，因?yàn)槿绻?/span>wsse不能順利調(diào)試通過(guò)，那么將會(huì)直接影響我們后續(xù)將wsse全面部署的計(jì)劃，同時(shí)ISV已經(jīng)跟在后面作測(cè)試了?？戳丝磿r(shí)間進(jìn)度表，下周要進(jìn)入平臺(tái)搜索引擎增強(qiáng)的開發(fā)和WSSE性能優(yōu)化（WSSE對(duì)于CPU的消耗真是厲害），因此也就只有兩天，周四和周五。昨天晚上調(diào)試到了很晚（我說(shuō)的很晚可能有些朋友覺得很早，不過(guò)對(duì)于我這種早睡早起的人來(lái)說(shuō)，真的算晚了），雖然盡力了，但是還是卡在了最后的部分（服務(wù)端返回內(nèi)容的驗(yàn)證解析），周五一大早到公司就開始繼續(xù)調(diào)試，一直到了下午5點(diǎn)鐘，我的神哪，讓我看到那個(gè)斷點(diǎn)不再跳出一個(gè)令我已經(jīng)看到都反胃的出錯(cuò)提示框（順便說(shuō)一下，微軟的vs出錯(cuò)提示框作的蠻精致，不過(guò)再好看都是出錯(cuò)，2天內(nèi)看到了不下數(shù)百次，再好看也讓人反胃了），最后在群里面大大的發(fā)泄了一把，公司一堆人覺得莫名其妙，不知道我受了什么打擊，就搞通一個(gè)東西能夠壓抑成這樣，其實(shí)這其中的苦也就自己知道，還是那句話：“在沒有調(diào)試過(guò).net的程序以前不知道開源的好啊，能看到源碼是多么開心的一件事情啊，整一個(gè)在替微軟作白盒測(cè)試，連google都被我翻爛了，也就只看到幾個(gè)老外在Q，而沒有人在那兒A”。廢話說(shuō)了那么多，言歸正傳，實(shí)踐是建立在理論基礎(chǔ)上的，那么先系統(tǒng)性的來(lái)介紹一下關(guān)于WSSE的內(nèi)容（如果概念已經(jīng)十分熟悉了，跳過(guò)即可），以及如何解決.net客戶端無(wú)法調(diào)試Java發(fā)布的web service的問(wèn)題。

在互連網(wǎng)應(yīng)用中Web Service已經(jīng)得到了廣泛的認(rèn)同，同時(shí)也是因?yàn)檫@種廣泛的應(yīng)用，使得Web Service在規(guī)范化方面越來(lái)越成熟。企業(yè)和企業(yè)之間的信息交互，很重要一點(diǎn)就是信息的安全性，電子商務(wù)等互連網(wǎng)應(yīng)用這方面的需求更為突出，如果沒有安全的保證，沒有客戶或者企業(yè)愿意將信息在網(wǎng)上交互，同時(shí)也不會(huì)信任任何接受到的信息。然而，作為SOA的有效技術(shù)手段，Web Service的動(dòng)態(tài)性很強(qiáng)，服務(wù)的開發(fā)者無(wú)法預(yù)料到服務(wù)將在什么環(huán)境下被使用，因此服務(wù)的安全性變得更加復(fù)雜。

在考慮安全性方面主要有三個(gè)關(guān)鍵性的概念：

機(jī)密性(Confidentiality),完整性（Integrity）,身份鑒別（Authentication）。

機(jī)密性：除了指定的接受者，其他人無(wú)法查看消息的內(nèi)容。通常會(huì)使用密鑰（對(duì)稱或非對(duì)稱）對(duì)消息加密，從而保證消息的機(jī)密性。
    完整性：確保消息在傳輸?shù)倪^(guò)程中沒有被修改。即保證消息的接收者接收到的消息與消息發(fā)送者最初發(fā)送的消息完全一致。通常會(huì)對(duì)消息做摘要(Digest)，再使用密鑰（對(duì)稱，非對(duì)稱）加密摘要，從而保證消息的完整性。   

身份鑒別：確保消息發(fā)送者的身份與消息中所聲稱的用戶身份一致。最簡(jiǎn)單的做法就是讓用戶同時(shí)發(fā)送用戶名和密碼，服務(wù)方確認(rèn)密碼的有效性從而判斷該用戶身份是否與用戶名所代表的一致。然而在實(shí)際的應(yīng)用中的做法通常不會(huì)如此簡(jiǎn)單，此時(shí)往往會(huì)使用密鑰對(duì)一段信息加密，服務(wù)方通過(guò)解密此信息確認(rèn)用戶的身份。

那么如何選擇使用對(duì)稱密鑰還是非對(duì)稱密鑰？什么時(shí)候使用公鑰，什么時(shí)候使用私鑰？首先由于對(duì)稱密鑰的加密解密速度比非對(duì)稱的密鑰快很多（大約1000倍），所以在加密消息的時(shí)候一般都使用對(duì)稱密鑰。但是有一個(gè)問(wèn)題就是對(duì)稱密鑰又如何發(fā)布呢？網(wǎng)絡(luò)上兩個(gè)沒有聯(lián)系的用戶如何建立起一個(gè)共享的密鑰？這時(shí)就需要PKI來(lái)幫助我們將這個(gè)共享的密鑰建立起來(lái)，即利用非對(duì)稱密鑰中的公鑰來(lái)加密那個(gè)共享密鑰，傳遞到私鑰的擁有方。由此可以知道：對(duì)稱密鑰加密普通信息，非對(duì)稱密鑰加密對(duì)稱密鑰。

在Integrity中，使用非對(duì)稱密鑰的私鑰加密摘要，得到的東西是一個(gè)廣為人知的東西—Digital Signature(數(shù)字簽名). 而使用對(duì)稱密鑰加密摘要得到的是HMAC(Hash message authentication codes)。他們?cè)诒ＷC消息完整性的同時(shí)，都具有身份鑒別的功能，不過(guò)前者還有一個(gè)功能---抗否認(rèn)性。值得注意的是在Confidentiality中，使用非對(duì)稱密鑰方法是用公鑰加密，私鑰解密，而在Integrity中使用非對(duì)稱密鑰的方法恰恰相反。

在當(dāng)前的安全策略上很多時(shí)候會(huì)使用到SSL和VPN，他們的好處和缺點(diǎn)網(wǎng)上都有評(píng)論，但作為和傳輸層無(wú)關(guān)的安全策略，WS-Security規(guī)范無(wú)疑是最具廣泛的應(yīng)用。IBM，BEA,Microsoft共同制定了WS-Security規(guī)范，解決了安全的三個(gè)基本問(wèn)題：機(jī)密性、完整性、身份鑒別，在Web Services使用SOAP（XML 格式）作為消息封裝協(xié)議的背景下，標(biāo)準(zhǔn)化組織分別制定了XML Encryption、XML Digital Signature、與SAML(XML格式的Security Token)三套規(guī)范，WS-Security則是規(guī)定了如何將以上規(guī)范組合起來(lái)以滿足Web Services安全需求的一套規(guī)范。

XML Signature規(guī)范是將數(shù)字簽名和XML組合而成的產(chǎn)物，不要以為XML Signature僅僅是將數(shù)字簽名技術(shù)應(yīng)用于XML文件。

XML Signature包括以下的功能：

    1．XML Signature可以對(duì)任何能夠以URI形式(uniform resource identifier)定位的資源做簽名。既包括與簽名同在一個(gè)XML文件中的元素，也包括其他XML文件中的元素，甚至可以是非XML形式的資源(比如一個(gè)圖形文件)，只要能被URI定位到的資源都可以應(yīng)用XML Signature. 這也代表了XML簽名的對(duì)象可以是動(dòng)態(tài)的變化。

    2．XML Signature可以對(duì)XML文件中的任一元素做簽名，也可以對(duì)整個(gè)文件做簽名。

    3．XML Signature 既可以用非對(duì)稱密鑰做簽名(Digital Signature)，也可以用對(duì)稱密鑰做簽名(HMAC)。

具體的標(biāo)簽以及含義就不做解釋了，不過(guò)如果要做簽名策略配置，需要熟悉這些標(biāo)簽，這也會(huì)影響到后續(xù)開發(fā)中遇到的各種問(wèn)題。另外兩個(gè)規(guī)范這邊就不做說(shuō)明了，因?yàn)楝F(xiàn)在服務(wù)框架暫時(shí)只是提供了Signature的要求，如果內(nèi)容需要加密，那么對(duì)于應(yīng)用來(lái)說(shuō)性能可能是不可接受的，因此需要的是利用SSL和簽名結(jié)合的策略來(lái)實(shí)現(xiàn)完整的安全機(jī)制。

對(duì)于WSSE的支持

       ASF這部分是改造了Tusncay的Web Service子項(xiàng)目，Tuscany子項(xiàng)目?jī)?nèi)部集成的web service的開源框架是axis2，雖然很多朋友評(píng)價(jià)xfire好于axis2，不過(guò)個(gè)人在使用過(guò)程中感覺其實(shí)兩者各有所長(zhǎng)，只是說(shuō)如何在適當(dāng)?shù)膱?chǎng)合使用，如果需要和Spring很好的集成，那么xfire當(dāng)然是最好的選擇，如果需要能夠有很好的wsse以及其他開源支持，那么axis2應(yīng)該是個(gè)很不錯(cuò)的選擇，畢竟apache組織下的開源項(xiàng)目眾多，自家人集成起來(lái)更是得心應(yīng)手，特別是wss4j和axis2的集成，axis2的address和rampart兩個(gè)子插件模塊使用起來(lái)十分方便，同時(shí)在框架的可插入性和模塊化上，覺得axis2要好過(guò)xfire。不過(guò)axis2的客戶端比xfire要麻煩得多，xfire封裝的好多了，這也是很多人喜歡xfire的緣故了（不過(guò)再傻瓜也抵不過(guò).net客戶端的傻瓜，不過(guò)這個(gè)傻瓜模式無(wú)法讓人測(cè)試，那么就真的被當(dāng)成傻瓜了），畢竟易用性往往是吸引到第一批客戶的重要特質(zhì)，這也是后續(xù)做ASF所需要考慮的問(wèn)題。

       使用Axis2的框架結(jié)合Jetty這個(gè)輕量級(jí)內(nèi)嵌容器作為Web Service發(fā)布框架（不得不提的是，在作web service的性能測(cè)試的過(guò)程中，公司的測(cè)試資深人員對(duì)于ASF的web service性能作了肯定，其實(shí)這和使用Jetty也有一定的關(guān)系，現(xiàn)在越來(lái)越多的開源框架都使用了Jetty作為內(nèi)置web輕量級(jí)容器，很靈活，同時(shí)也可以達(dá)到很好的性能要求，在后面工作中對(duì)于hessian集成到服務(wù)框架中來(lái)，也是采用了Hessian+Jetty），并且通過(guò)Axis2的rampart集成了wss4j，提供了WSSE的增強(qiáng)功能。

對(duì)于認(rèn)證模式場(chǎng)景需求問(wèn)題的解決

       ASF對(duì)于Web Service Security這部分只是要求了Signature，而對(duì)于Signature需要提供兩種方式，UserNameToken和X.509證書。前者提供給內(nèi)部的一些應(yīng)用使用，后者提供給外部ISV使用，兩者主要差別也就是在性能上，后者經(jīng)過(guò)測(cè)試，在CPU的使用上，是6-8倍于不帶Signature的Web Service。

       UserNameToken這種模式很簡(jiǎn)單，就很類似于我們平常的用戶認(rèn)證，用戶名和密碼作為明文或者加密，嵌入在Soap Header中即可，客戶端根據(jù)本地保存的受信用戶記錄來(lái)交驗(yàn)是否是合法用戶。

       X.509就比較特殊一些，所謂的證書，其中包括了公鑰私鑰對(duì)（作為簽名和認(rèn)證使用），證書頒發(fā)者的信息（可能是一些CA機(jī)構(gòu)或者是用本地的證書生成工具自己生成），證書擁有者的身份信息，以及一些導(dǎo)入的受信第三方的公鑰證書。當(dāng)前的證書方式的簽名認(rèn)證主要有兩種模式，一種是雙方證書都是由第三方CA認(rèn)證，同時(shí)雙方都將對(duì)方的CA作為可信的CA，那么請(qǐng)求發(fā)起方將會(huì)把自己的證書放入到Soap Header中，接受方接受到請(qǐng)求以后，獲取證書，發(fā)現(xiàn)是受信的CA，那么就認(rèn)為請(qǐng)求發(fā)起方身份可信，同時(shí)在作完整性摘要校對(duì)。另一種模式就是雙方的證書可以沒有任何權(quán)威的CA作保證，但是雙方首先就需要將附帶自己公鑰的證書發(fā)送給對(duì)方，對(duì)方將這附帶有公鑰的證書分別導(dǎo)入到證書管理庫(kù)中(java是某個(gè)JKS，.net是windows的當(dāng)前用戶或者本機(jī)的證書管理文件)。雙方交互的時(shí)候不需要將證書置入Soap Header中，但是需要將證書的引用標(biāo)示（序列號(hào)或者是X.509 SubjectKeyIdentifier）傳遞給服務(wù)端，服務(wù)端根據(jù)標(biāo)示在本地的證書庫(kù)中查找并且校驗(yàn)，這種模式的好處就是不需要CA的認(rèn)證（省錢）同時(shí)傳遞的時(shí)候不需要將證書帶入到Header中，節(jié)省了傳遞報(bào)文的大小，缺點(diǎn)就是雙方需要互相保存對(duì)方的公鑰證書到本地的證書庫(kù)中，同時(shí)這種模式也為跨平臺(tái)帶來(lái)了很多問(wèn)題，后續(xù)的互通中就會(huì)提到。

       ASF的證書認(rèn)證模式中采用了后者，因?yàn)橐竺總€(gè)ISV去有一個(gè)第三方CA作為授權(quán)不是很可行，但是問(wèn)題就是如果ISV需要導(dǎo)入我們的公鑰證書比較方便，但是我們需要管理那么多ISV的證書，同時(shí)又需要?jiǎng)討B(tài)上傳修改保存證書那么就不能用原有的手動(dòng)導(dǎo)入的模式，同時(shí)由于到時(shí)候部署的服務(wù)器集群不可能都維護(hù)一份本地的證書庫(kù)，因此需要用數(shù)據(jù)庫(kù)手段來(lái)維護(hù)，但是在應(yīng)用啟動(dòng)以后再要新增或者修改證書，將會(huì)比較麻煩，因此采取了擴(kuò)展wss4j的策略讀取方式來(lái)適應(yīng)新的應(yīng)用場(chǎng)景。

擴(kuò)展的CrytoProvider類圖

擴(kuò)展后的keystore初始化以及signature部分流程圖

         這部分設(shè)計(jì)主要是擴(kuò)展了WSS4J的CrytoProvider,擴(kuò)展后的CrytoProvider重載了獲取X509證書的幾個(gè)方法，這里類似于AOP，通過(guò)提供ICertsLoaderHandler接口來(lái)回調(diào)獲取其它存儲(chǔ)內(nèi)的certs構(gòu)建 visual keystore，同時(shí)在作signature的時(shí)候，如果發(fā)現(xiàn)ISV的cert不存在于當(dāng)前的visual keystore 中根據(jù)CrytoProvider的接口實(shí)現(xiàn)，來(lái)決定是全部刷新還是部分獲取刷新當(dāng)前的visual keystore中的certs。這樣就可以達(dá)到了動(dòng)態(tài)裝載和刷新certs的要求，同時(shí)根據(jù)性能要求選擇配置和實(shí)現(xiàn)不同的CrytoProvider。

.Net和Java的互通

       Java 的客戶端和服務(wù)端Security互通很快就搞定了，只是對(duì)于一些應(yīng)用場(chǎng)景做證書管理的擴(kuò)展。然而，在經(jīng)歷了.net客戶端調(diào)用Java發(fā)布的ws返回?cái)?shù)組對(duì)象類型的問(wèn)題以后，又一個(gè)大難題擺在了我的面前，ISV support小組和測(cè)試部的日?qǐng)?bào)上把.net客戶端無(wú)法在wsse的模式下調(diào)用Java 發(fā)布的 Web Service作為了重點(diǎn)問(wèn)題，需要我支持，那么當(dāng)然當(dāng)仁不讓的接下來(lái)盡快搞定了，雖然對(duì).net來(lái)說(shuō)，我算是新手中的新手，不過(guò)經(jīng)過(guò)兩天的測(cè)試，讓我總結(jié)出了.net調(diào)試的技巧，那就是截包分析（感覺又回到我前幾年在通信行業(yè)干活時(shí)的狀況，對(duì)于對(duì)方協(xié)議不了解，又沒有源碼可看，那么就截報(bào)文來(lái)分析么）。開始挺樂觀的，想著WS-Security微軟也是參與者么，應(yīng)該會(huì)嚴(yán)格遵守的，估計(jì)一天搞定，結(jié)果活活的折騰了兩天，下面所描述的如何互通可能總的看起來(lái)應(yīng)該不是很復(fù)雜，不過(guò)摸索的過(guò)程可真是很費(fèi)事，google的每一條老外的信息都被我看過(guò)了，但是Question多Answer少。廢話不多說(shuō)，進(jìn)入正題。

       首先不管是什么客戶端調(diào)用什么服務(wù)端，都需要先做一件事情，準(zhǔn)備key pairs。在Java中證書管理庫(kù)可以通過(guò)Jdk提供的key tools這個(gè)工具生成jks格式的Java Key Store，可以將公鑰導(dǎo)出，或者將公鑰導(dǎo)入，同時(shí)可以生成秘鑰對(duì)保存在證書中。在.net中可以通過(guò)makecert的工具來(lái)生成符合Public Key Cryptography Standards #12，PKCS#12標(biāo)準(zhǔn)定義，包含了公鑰和私鑰的二進(jìn)制格式的證書形式，以pfx作為證書文件后綴，同時(shí)可以通過(guò)mmc對(duì)windows的證書存儲(chǔ)區(qū)進(jìn)行管理，導(dǎo)入或者導(dǎo)出證書。其實(shí).net和java的互通關(guān)鍵問(wèn)題就是出在證書格式不同以及獲取證書的算法上。下面就具體的描述一下如何從Java的開發(fā)者來(lái)做好Java WebService和.net互通的工作。

        更多內(nèi)容請(qǐng)參見：http://blog.csdn.net/cenwenchu79