fisher

blog也搬遷了：http://blog.sina.com.cn/liuwendao

來武漢快三年了，留在北京的最后一件物件-電吉它，也被我拿到武漢來了

我們這么混，能成功嗎？
立帖為證

　　軍事演習區(qū)，一位婦女駕車在大橋前被一名軍官攔住：“對不起，公民，您現(xiàn)在不能過去。”“為什么？”“這座橋在一小時前被炸毀了。”“您能告訴我這究竟是怎么回事嗎？”“很抱歉，不行。我本人已于2小時前陣亡。”
　　
　　
　　伊萬看電視，是勃在演講。伊萬覺得無聊，換了一個，還是勃在演講，又換一個，還是他。伊萬一連撥了幾十個臺，最后累了，準備關電視。這時候電視畫面變成一個KGB，怒氣沖沖地叫：“你再敢換？再敢換？再換判你10年大牢！”
　　
　　
　　某日蘇聯(lián)舉行國慶**，沿著大街開來了炮兵、機械化步兵、坦克、自行火炮、戰(zhàn)術導彈、戰(zhàn)略核導彈，破壞力一個比一個大；隊列末尾卻是兩個帶公文包的矮子。在看臺上勃列日涅夫驚訝地說：“這兩個人破壞力比核導彈還大！他們是什么人？”
　　KGB頭子說：“不是我的人。”
　　國防部長說：“沒見過他們。”
　　蘇聯(lián)總理說：“他們是國家計委的...”
　　
　　
　　戈爾巴喬夫視察農(nóng)場，看到豬兒乖乖，一時興起站在豬中間照了張像。
　　待到報紙準備發(fā)表時，編輯為照片的標題犯了難？？
　　“戈爾巴喬夫同志和豬在一起”不好。
　　“豬和戈爾巴喬夫同志在一起”也不好。
　　報紙出版后，照片下的說明文字是？？
　　“左起第三位是戈爾巴喬夫同志”
　　
　　
　　勃列日涅夫和美國總統(tǒng)卡特在瑞士開會，休息時間兩個人很無聊，就開始比誰的保膘更忠誠。卡特先來，他把自己的報膘叫進來，推開窗（外面是20層樓）說：“約翰，從這里跳下去！”
　　約翰哭著說：“你著么能這樣呢，總統(tǒng)先生，我還有老婆孩子吶。”
　　卡特被感動了，流著淚說是自己不對，叫約翰走了，然后掄到勃列日涅夫，他也大聲叫自己的保膘伊萬。
　　“伊萬，從這里跳下去！”
　　伊萬二話不說就要往下跳，卡特一把抱住他說：“你瘋了？跳下去會死的！”
　　伊萬一邊掙扎著要跳下去一邊說：“放開我，混蛋，我還有老婆孩子吶。”
　　
　　
　　早年莫斯科修地鐵，工程師將方案上報斯大林審批。不久，方案發(fā)下來，上面有斯大林的簽字。
　　細心的工程師發(fā)現(xiàn)圖紙上多了一個圓型的茶杯印，于是莫斯科地鐵就多了一條環(huán)形線。
　　
　　
　　斯大林肅反時期的蘇聯(lián)。一位內(nèi)務人民委員部審判員結束一天的審判工作，回到辦公室，突然一個人大笑起來。對面辦公桌的同事奇怪的問道：“有什么好笑的事嗎？”“是啊，”審判員用手帕擦著笑出來的眼淚：“一個很好笑的笑話……”“哦？說來聽聽？”“你瘋了嗎？！我剛判了說這笑話的家伙五年苦役！”
　　
　　
　　蘇聯(lián)30年代肅反擴大化時期。內(nèi)務人民委員部的一間牢房里關了三個人，彼此間談起坐牢的原因。
　　第一個人說，我因為反對了黨書記彼得羅夫；
　　第二個人說，我因為支持了彼得羅夫；
　　第三個人說，我就是彼得羅夫。
　　
　　
　　戈爾巴喬夫和他的司機開著車在路上，戈爾巴喬夫突發(fā)異想，說：讓開！我來開。一個老警察和一個新警察在路上值勤，見一輛車歪歪扭扭的開得瘋快，老警察就對新警察說：去！好好收拾一下。新警察將車攔住之后，又沒趣沒趣地回來了。老警察問：怎么？里面是誰？新警察回答說：我也不知道里面是誰，反正給他開車的是戈爾巴喬夫。
　　
　　
　　美國外交代表團到蘇聯(lián)訪問，蘇聯(lián)接待官員陪他們參觀“建設的偉大成就”，并且得意的說：“到了下一個五年計劃，每個蘇聯(lián)家庭都可以擁有一架私人飛機！”美國人驚訝的問：“ 他們要飛機干什么呢？”蘇聯(lián)官員說：“當然有用啊……譬如你在莫斯科聽說列寧格勒開始供應面包了，你可以馬上開著飛機趕去排上隊。”
　　
　　
　　一位公民打電話到基輔電臺問主持人：“共產(chǎn)主義到底是藝術還是科學？” 主持人說：“我也不清楚，但我肯定不是科學” “為什么？” “如果是科學的話，他們應該拿狗做試驗。”
　　
　　
　　斯大林在大會上引經(jīng)據(jù)典地說：“馬克思和列寧說1+1=2，而托洛茨基和布哈林說1+1不等于3。是托洛茨基和布哈林說的對呢？還是馬克思和列寧說得對呢？”下面聽眾一臉疑惑，“毫無疑問，是馬克思和列寧說的對！”底下熱烈鼓掌，“托洛茨基和布哈林是帝國主義派來的間諜，說1+1不等于3的人罪不容赦……”
　　
　　
　　列寧快去世了，叫趕快把繼承人斯大林召進克里姆林宮來，臨終有幾句話要囑托。“不瞞你說，我還有一個隱憂啊，斯大林。”“說吧，親愛的伊里奇。”斯大林專心地聽著。“那就是，人們會跟你走嗎？不知你想過了沒有？”“他們一定會跟我走的。”斯大林強調說，“一定會！” “但愿如此。”列寧說，“我只是擔心，萬一他們不跟你走，你怎么辦？”“沒問題！”斯大林答道：“那他們就得跟你走！”
　　
　　
　　集體農(nóng)莊莊員伊萬在河里捉到一條大魚，高興的回到家里和老婆說：“看，我們有炸魚吃了！”
　　“沒有油啊。”
　　“那就煮！”
　　“沒鍋。”
　　“烤魚！”
　　“沒柴。”
　　伊萬氣死了，走到河邊把魚扔了回去。那魚在水里劃了一個半圓，上身出水，舉起右鰭激動地高呼：“斯大林萬歲！”
　　
　　
　　“瑞典能否建立共產(chǎn)主義”？
　　“不能。”
　　“為何？”
　　“列寧同志說了：共產(chǎn)主義不在山那邊。”
　　
　　
　　一個蘇聯(lián)KGB特工和一個美國CIA特工互相吹噓各自的機構是如何的杰出。
　　那個KGB特工首先發(fā)言說，“我們擁有你們美國過去15年里所有導彈發(fā)射的詳細數(shù)據(jù)。”
　　CIA特工說：“這不算什么。我們CIA掌握著你們蘇聯(lián)未來15年里所有當選的中央委員名單。”
　　
　　
　　一艘航行在大海上的輪船快要沉了，船長叫乘客趕緊跳海，但他喊了半天沒有一個人跳，一個社會學家說我來喊，他去喊過之后所有的人都跳下海去了。船長覺得奇怪，問他是怎么喊的，社會學家回答說：我對法國人說這樣跳下去很浪漫，我對西班牙人說這樣跳下去很瀟灑，我對英國人說這樣跳下去是一種體育運動，我對美國人說這樣跳下去有利可圖，我對蘇聯(lián)人說這樣跳下去是革命行動。
　　
　　
　　在蘇聯(lián)的一趟公交車，一個男的非常謙恭地問站在他身旁的另一個男的：“同志，請問您是克格勃嗎？”
　　那人答道：“不是。”
　　又問：“那您有沒有親戚或朋友是克格勃呢？”
　　答：“沒有。”
　　還問：“那您是否跟克格勃有些交往或聯(lián)系？”
　　答：“沒有，你要干嘛啊！”
　　該男生氣地說：“干嘛，他媽的，你踩著我的腳了！”
　　
　　
　　赫魯曉夫作報告，批判斯大林。忽然，有人從臺下遞了個紙條，寫道：當他做壞事的時候，你在哪里？赫魯曉夫一看這個條子，大聲怒喝道：“是誰寫的，給我站出來。”臺下雅雀無聲，沒有人站出來。赫魯曉夫接著說道：“同志們，我當時就和你們現(xiàn)在一樣，你們知道我當時為什么不敢站出來了吧”
　　
　　
　　勃列日涅夫：同志們，美國人登上了月球，我們不能再等了，黨決定讓你們上太陽。
　　宇航員：總書記同志，我們會被燒死的。
　　勃列日涅夫：沒關系，同志們，黨都替你們想好了，你們晚上去。
　　
　　
　　電影《這里的黎明靜悄悄》試映時，由于其中有部分裸體鏡頭，因此主管電影審核的官員曾試圖把這部電影禁演，幸虧勃列日涅夫內(nèi)部觀看時感動得熱淚盈眶，這部優(yōu)秀的電影才有幸與觀眾見面，成為世界電影史上不朽的篇章。而另一部電影由于其中有主人公走到教堂時跪地痛哭的鏡頭，被電影審核官員認為是宣揚宗教而準備勒令裁掉這部分內(nèi)容，恰恰勃列日涅夫看到這里時動了感情，因此這個鏡頭得以幸存下來。
　　
　　
　　當年的捷克斯洛伐克政府中，設立了一個“海軍部”，結果，蘇聯(lián)老大哥就對捷克人說：你們是內(nèi)陸國家，設什么海軍部？
　　捷克人回答說：那你們不是也設了文化部嗎？

最近看到越來越多的人使用mina，甚至在線下也碰到合作公司的庫中使用MINA，出于好奇，嘗試一下用自己的blog做一下調查，訪問本blog的兄弟，如果您使用MINA作為自己的通訊基礎件，請留言介紹一下自己

軟件開發(fā)的世界里充滿了不理解，客戶不理解軟件是怎樣開發(fā)的、經(jīng)理不理解開發(fā)人員、開發(fā)人員不理解指揮者。

問題在于軟件開發(fā)驚人的困難，造成很少有開發(fā)人員能夠說出軟件自始至終是怎樣開發(fā)的，并能夠對這個過程中會遇到的不同選擇所隱含的結果表現(xiàn)出適度的理解。

在軟件開發(fā)人員還很年輕的時候（十幾歲或二十出頭），他們通常集中精力學習和使用技術，稱自己為perl程序員、Linux專家、EJB開發(fā)人員、.NET開發(fā)人員等。對他們來說技術是最重要的事情。因為技術在不斷的變化，年輕的程序員傾向于大致學習一個技術，在一到兩個項目中使用，然后重新開始學習新技術或者是學習以前使用過的技術的最新發(fā)展。這里的問題是，他們一遍又一遍的重復的學習的不過是同樣的低層次基本技能的不同風味。

幸運的是，很多開發(fā)人員在經(jīng)過了幾輪技術學習之后逐漸意識到：一旦用COBOL、Java、C#等語言為事務控制編寫過代碼，就會開始認識到基本的、本質的東西是不變的。不同環(huán)境下的數(shù)據(jù)庫訪問、用戶界面設計等領域也是同樣的情況。不久以后，開發(fā)人員逐漸認識到無論具體的技術怎樣，很多基礎性的東西是保持不變的，這些基礎性的東西有的在學校里講過，有的沒有。
這種認識經(jīng)常發(fā)生在開發(fā)人員接近三十歲或剛過三十歲的時候，通常是人們開始穩(wěn)定下來，結婚、買房的時候。這是比較幸運的情況，因為上面提到的這些新的個人需求意味著他們不可能再投入大量的時間去學習新的技術，他們需要用這些時間和家庭成員在一起。突然的，高層次的角色如項目負責人、項目經(jīng)理、（非敏捷的）建模人員等對他們變得非常有吸引力，因為這些角色不需要持續(xù)花費大量的時間和精力去學習新技術。于是，等到開發(fā)人員開始真正學到技藝的時候，他們已經(jīng)處于離開開發(fā)人員角色的轉變過程中了。所幸的是，新的“小年輕”不斷的跟上來，這個過程在不斷的循環(huán)重復。最終的結果是：大部分最活躍的正在開發(fā)軟件的人通常不是最稱職的做這件事的人，而他們自己甚至還不知道。

/*-------------------------------------------

? 程序員的進化——從學生到首席執(zhí)行官

翻譯 2002 王詠剛 http://www.contextfree.net/
轉譯自 Omri's Computer Humor Page
http://www.cs.bgu.ac.il/~omri/Humor/
-------------------------------------------*/


--------------------------------------------------------------------------------
中學階段

? ? ? 10 PRINT "HELLO WORLD"
? ? ? 20 END
--------------------------------------------------------------------------------
大學一年級

? ? ? program Hello(input, output)
? ? ? ? begin
? ? ? ? writeln('Hello World')
? ? ? ? end.
--------------------------------------------------------------------------------
大學高年級

? ? ? (defun hello
? ? ? ? (print
? ? ? ? (cons 'Hello (list 'World))))
--------------------------------------------------------------------------------
初級程序員

? ? ? #include <stdio.h>
? ? ? void main(void)
? ? ? {
? ? ? ? char *message[] = {"Hello ", "World"};
? ? ? ? int i;

? ? ? ? for(i = 0; i < 2; ++i)
? ? ? ? printf("%s", message );
? ? ? ? printf("\n");
? ? ? }
--------------------------------------------------------------------------------
編程老鳥

? ? ? #include <iostream.h>
? ? ? #include <string.h>

? ? ? class string
? ? ? {
? ? ? private:
? ? ? ? int size;
? ? ? ? char *ptr;

? ? ? public:
? ? ? ? string() : size(0), ptr(new char('\0')) {}

? ? ? ? string(const string &s) : size(s.size)
? ? ? ? {
? ? ? ? ptr = new char[size + 1];
? ? ? ? strcpy(ptr, s.ptr);
? ? ? ? }

? ? ? ? ~string()
? ? ? ? {
? ? ? ? delete [] ptr;
? ? ? ? }

? ? ? ? friend ostream &operator <<(ostream &, const string &);
? ? ? ? string &operator=(const char *);
? ? ? };

? ? ? ostream &operator<<(ostream &stream, const string &s)
? ? ? {
? ? ? ? return(stream << s.ptr);
? ? ? }

? ? ? string &string::operator=(const char *chrs)
? ? ? {
? ? ? ? if (this != &chrs)
? ? ? ? {
? ? ? ? delete [] ptr;
? ? ? ? size = strlen(chrs);
? ? ? ? ptr = new char[size + 1];
? ? ? ? strcpy(ptr, chrs);
? ? ? ? }
? ? ? ? return(*this);
? ? ? }

? ? ? int main()
? ? ? {
? ? ? ? string str;

? ? ? ? str = "Hello World";
? ? ? ? cout << str << end

? ? ? ? return(0);
? ? ? }
--------------------------------------------------------------------------------
編程高手

? ? ? [
? ? ? uuid(2573F8F4-CFEE-101A-9A9F-00AA00342820)
? ? ? ]
? ? ? library LHello
? ? ? {
? ? ? ? // bring in the master library
? ? ? ? importlib("actimp.tlb");
? ? ? ? importlib("actexp.tlb");

? ? ? ? // bring in my interfaces
? ? ? ? #include "pshlo.idl"

? ? ? ? [
? ? ? ? uuid(2573F8F5-CFEE-101A-9A9F-00AA00342820)
? ? ? ? ]
? ? ? ? cotype THello
? ? ? {
? ? ? interface IHello;
? ? ? interface IPersistFile;
? ? ? };
? ? ? };

? ? ? [
? ? ? exe,
? ? ? uuid(2573F890-CFEE-101A-9A9F-00AA00342820)
? ? ? ]
? ? ? module CHelloLib
? ? ? {

? ? ? ? // some code related header files
? ? ? ? importheader(<windows.h>);
? ? ? ? importheader(<ole2.h>);
? ? ? ? importheader(<except.hxx>);
? ? ? ? importheader("pshlo.h");
? ? ? ? importheader("shlo.hxx");
? ? ? ? importheader("mycls.hxx");

? ? ? ? // needed typelibs
? ? ? ? importlib("actimp.tlb");
? ? ? ? importlib("actexp.tlb");
? ? ? ? importlib("thlo.tlb");

? ? ? ? [
? ? ? ? uuid(2573F891-CFEE-101A-9A9F-00AA00342820),
? ? ? ? aggregatable
? ? ? ? ]
? ? ? ? coclass CHello
? ? ? {
? ? ? cotype THello;
? ? ? };
? ? ? };

? ? ? #include "ipfix.hxx"

? ? ? extern HANDLE hEvent;

? ? ? class CHello : public CHelloBase
? ? ? {
? ? ? public:
? ? ? ? IPFIX(CLSID_CHello);

? ? ? ? CHello(IUnknown *pUnk);
? ? ? ? ~CHello();

? ? ? ? HRESULT __stdcall PrintSz(LPWSTR pwszString);

? ? ? private:
? ? ? ? static int cObjRef;
? ? ? };

? ? ? #include <windows.h>
? ? ? #include <ole2.h>
? ? ? #include <stdio.h>
? ? ? #include <stdlib.h>
? ? ? #include "thlo.h"
? ? ? #include "pshlo.h"
? ? ? #include "shlo.hxx"
? ? ? #include "mycls.hxx"

? ? ? int CHello::cObjRef = 0;

? ? ? CHello::CHello(IUnknown *pUnk) : CHelloBase(pUnk)
? ? ? {
? ? ? ? cObjRef++;
? ? ? ? return;
? ? ? }

? ? ? HRESULT __stdcall CHello::PrintSz(LPWSTR pwszString)
? ? ? {
? ? ? ? printf("%ws\n", pwszString);
? ? ? ? return(ResultFromScode(S_OK));
? ? ? }

? ? ? CHello::~CHello(void)
? ? ? {

? ? ? // when the object count goes to zero, stop the server
? ? ? cObjRef--;
? ? ? if( cObjRef == 0 )
? ? ? ? PulseEvent(hEvent);

? ? ? return;
? ? ? }

? ? ? #include <windows.h>
? ? ? #include <ole2.h>
? ? ? #include "pshlo.h"
? ? ? #include "shlo.hxx"
? ? ? #include "mycls.hxx"

? ? ? HANDLE hEvent;

? ? ? int _cdecl main(
? ? ? int argc,
? ? ? char * argv[]
? ? ? ) {
? ? ? ULONG ulRef;
? ? ? DWORD dwRegistration;
? ? ? CHelloCF *pCF = new CHelloCF();

? ? ? hEvent = CreateEvent(NULL, FALSE, FALSE, NULL);

? ? ? // Initialize the OLE libraries
? ? ? CoInitializeEx(NULL, COINIT_MULTITHREADED);

? ? ? CoRegisterClassObject(CLSID_CHello, pCF, CLSCTX_LOCAL_SERVER,
? ? ? ? REGCLS_MULTIPLEUSE, &dwRegistration);

? ? ? // wait on an event to stop
? ? ? WaitForSingleObject(hEvent, INFINITE);

? ? ? // revoke and release the class object
? ? ? CoRevokeClassObject(dwRegistration);
? ? ? ulRef = pCF->Release();

? ? ? // Tell OLE we are going away.
? ? ? CoUninitialize();

? ? ? return(0);
? ? ? }

? ? ? extern CLSID CLSID_CHello;
? ? ? extern UUID LIBID_CHelloLib;

? ? ? CLSID CLSID_CHello = { /* 2573F891-CFEE-101A-9A9F-00AA00342820 */
? ? ? ? 0x2573F891,
? ? ? ? 0xCFEE,
? ? ? ? 0x101A,
? ? ? ? { 0x9A, 0x9F, 0x00, 0xAA, 0x00, 0x34, 0x28, 0x20 }
? ? ? };

? ? ? UUID LIBID_CHelloLib = { /* 2573F890-CFEE-101A-9A9F-00AA00342820 */
? ? ? ? 0x2573F890,
? ? ? ? 0xCFEE,
? ? ? ? 0x101A,
? ? ? ? { 0x9A, 0x9F, 0x00, 0xAA, 0x00, 0x34, 0x28, 0x20 }
? ? ? };

? ? ? #include <windows.h>
? ? ? #include <ole2.h>
? ? ? #include <stdlib.h>
? ? ? #include <string.h>
? ? ? #include <stdio.h>
? ? ? #include "pshlo.h"
? ? ? #include "shlo.hxx"
? ? ? #include "clsid.h"

? ? ? int _cdecl main(
? ? ? int argc,
? ? ? char * argv[]
? ? ? ) {
? ? ? HRESULT hRslt;
? ? ? IHello ? ? *pHello;
? ? ? ULONG ulCnt;
? ? ? IMoniker * pmk;
? ? ? WCHAR wcsT[_MAX_PATH];
? ? ? WCHAR wcsPath[2 * _MAX_PATH];

? ? ? // get object path
? ? ? wcsPath[0] = '\0';
? ? ? wcsT[0] = '\0';
? ? ? if( argc > 1) {
? ? ? ? mbstowcs(wcsPath, argv[1], strlen(argv[1]) + 1);
? ? ? ? wcsupr(wcsPath);
? ? ? ? }
? ? ? else {
? ? ? ? fprintf(stderr, "Object path must be specified\n");
? ? ? ? return(1);
? ? ? ? }

? ? ? // get print string
? ? ? if(argc > 2)
? ? ? ? mbstowcs(wcsT, argv[2], strlen(argv[2]) + 1);
? ? ? else
? ? ? ? wcscpy(wcsT, L"Hello World");

? ? ? printf("Linking to object %ws\n", wcsPath);
? ? ? printf("Text String %ws\n", wcsT);

? ? ? // Initialize the OLE libraries
? ? ? hRslt = CoInitializeEx(NULL, COINIT_MULTITHREADED);

? ? ? if(SUCCEEDED(hRslt)) {

? ? ? ? hRslt = CreateFileMoniker(wcsPath, &pmk);
? ? ? ? if(SUCCEEDED(hRslt))
? ? ? hRslt = BindMoniker(pmk, 0, IID_IHello, (void **)&pHello);

? ? ? ? if(SUCCEEDED(hRslt)) {

? ? ? // print a string out
? ? ? pHello->PrintSz(wcsT);

? ? ? Sleep(2000);
? ? ? ulCnt = pHello->Release();
? ? ? }
? ? ? ? else
? ? ? printf("Failure to connect, status: %lx", hRslt);

? ? ? ? // Tell OLE we are going away.
? ? ? ? CoUninitialize();
? ? ? ? }

? ? ? return(0);
? ? ? }
--------------------------------------------------------------------------------
黑客初階

? ? ? #!/usr/local/bin/perl
? ? ? $msg="Hello, world.\n";
? ? ? if ($#ARGV >= 0) {
? ? ? ? while(defined($arg=shift(@ARGV))) {
? ? ? ? $outfilename = $arg;
? ? ? ? open(FILE, ">" . $outfilename) || die "Can't write $arg: $!\n";
? ? ? ? print (FILE $msg);
? ? ? ? close(FILE) || die "Can't close $arg: $!\n";
? ? ? ? }
? ? ? } else {
? ? ? ? print ($msg);
? ? ? }
? ? ? 1;
--------------------------------------------------------------------------------
黑客有成

? ? ? #include <stdio.h>
? ? ? #define S "Hello, World\n"
? ? ? main(){exit(printf(S) == strlen(S) ? 0 : 1);}
--------------------------------------------------------------------------------
黑客高手

? ? ? % cc -o a.out ~/src/misc/hw/hw.c
? ? ? % a.out
--------------------------------------------------------------------------------
黑客大蝦

? ? ? % cat
? ? ? Hello, world.
? ? ? ^D
--------------------------------------------------------------------------------
初級經(jīng)理

? ? ? 10 PRINT "HELLO WORLD"
? ? ? 20 END
--------------------------------------------------------------------------------
中級經(jīng)理

? ? ? mail -s "Hello, world." bob@b12
? ? ? Bob, could you please write me a program that prints "Hello, world."?
? ? ? I need it by tomorrow.
? ? ? ^D
--------------------------------------------------------------------------------
高級經(jīng)理

? ? ? % zmail jim
? ? ? I need a "Hello, world." program by this afternoon.
--------------------------------------------------------------------------------
首席執(zhí)行官

? ? ? % letter
? ? ? letter: Command not found.
? ? ? % mail
? ? ? To: ^X ^F ^C
? ? ? % help mail
? ? ? help: Command not found.
? ? ? % damn!
? ? ? !: Event unrecognized
? ? ? % logout
--------------------------------------------------------------------------------

還記得孔乙己說：茴香豆的‘茴’字有四種寫法嗎？現(xiàn)在我們的知識份子已經(jīng)進步了，看看Hello World的196種寫法:)

http://man.lupaworld.com/content/develop/hello/HelloWorld.shtml

下午寫完設計，趴在武漢辦公室的窗戶上看風景，天氣好的時候，左面長江右邊東湖都可以看到，其實想想在武漢出差也挺不錯的，呵呵

彼得·德魯克在他的《卓有成效的管理者?》當中，闡述了知識工作者管理的秘訣，那就是知識工作者的工作效率來自于對其工作的有效性以及他的工作是否有所成就。這本1966年出版的管理學書籍經(jīng)過近50年的時間，反而越發(fā)顯得適應潮流。
而卓有成效的知識工作管理者現(xiàn)在顯得比過去任何時候都要短缺，也比現(xiàn)時任何人才都要短缺。在現(xiàn)時這個信息爆炸，案例豐富的年代，戰(zhàn)略眼光與部署格局對于一個企業(yè)人才不再如此重要，對于企業(yè)戰(zhàn)略，任何有管理常識、了解企業(yè)實情的人大都可以分析得很到位，關鍵是要找到合適的人去實施。知道什么樣的人合適，以及找到這個合適的人，成為企業(yè)家最需要做的事情。而成為那個合適的人，則成為草根階層走入舞臺中央的必備能力。

附一篇來自經(jīng)濟觀察報劉軍的《笨蛋，最重要的是人！》
---------------------------------

????? 2005年10月8日管理大師彼得·德魯克曾經(jīng)講過一個他和《時代》《財富》等雜志的出版人亨利·魯斯交往的故事。魯斯有個很好的新雜志方案——試圖創(chuàng)辦“從美國人思考角度出發(fā)”的高格調文化雜志，他去向德魯克求教。德魯克分析了一番說，“這份企劃案很棒，不過晚了50年。”接著，他對魯斯說出了最重要的話：“此外，《時代》的人也無法勝任。我猜，你想鼓勵一些外面的作家來為這本雜志執(zhí)筆，并以一般大眾為讀者群。但是你的專長卻是叫自己手下人搞定，因此大有不同。”?
????? 魯斯回答說，“我來向你請教，正因為我猜想你會這么說。”他因而放棄了這個計劃，因為他深知人的重要性。經(jīng)過十多年的西方管理教育和知識傳播，中國企業(yè)管理者已經(jīng)熟知戰(zhàn)略的理性分析，與重視人比起來更重視事，另外先建立制度、而不是依靠人的觀念也被廣泛接受。不過，我卻逐漸感覺到，在這些問題上我們可能有點矯枉過正，對于知識型工作、對于管理，或許人更重要，是應該優(yōu)先考慮的。?
????? 9月底，索尼新任CEO、美國人霍華德·斯特林格(Howard?Stringer)宣布索尼的戰(zhàn)略調整計劃：全球裁員一萬人，縮減工廠數(shù)目，出售1200億日元的不動產(chǎn)與股票等非核心資產(chǎn)，對消費電子業(yè)務進行架構調整、將權力集中到這一業(yè)務的最高主管手中。在過去五年中，索尼逐漸失去消費電子霸主地位，業(yè)績很不理想，這背后的根本原因正是這些戰(zhàn)略調整所觸及的問題。對于這一點，大概稍微有點管理常識的人都知道，我想索尼前CEO出井伸之自然了然于心，他之下的索尼高管也清楚。不過，大概只有霍華德·斯特林格、索尼歷史上第一個外國人CEO、這個日本文化的局外人才能推行上述改革。?
???? 戰(zhàn)略，有管理常識、了解企業(yè)實情的人大都可以分析得很到位，但真正去做，就需要“合適的人”。我一直相信，選擇霍華德·斯特林格作為繼任者，是出井伸之的最重要的決策，體現(xiàn)這個亞洲最優(yōu)秀的商業(yè)領袖的領導才能。卡洛斯·戈恩已經(jīng)因成功在日產(chǎn)汽車（Nissan）實現(xiàn)大逆轉而成為全球最知名的管理者之一，他當初所做的關閉工廠與裁員、破除日本式企業(yè)聯(lián)盟等措施，都是眾所周知的弊端，但惟有他這個合適的人才能推動變革。斯特林格和戈恩都是在這種情境下最合適的人，只是恰巧他們都是外國人。?
????? Google、微軟和李開復之間的紛爭一直沒有停息的跡象。在這個過程中李開復把自己再次塑造成了最優(yōu)秀的技術專家形象，但如果相信這一點，我們就錯誤理解了Google的智慧。如果要一流的中文搜索研發(fā)人才，Google的最佳人選絕對不是李開復，而可能是李彥宏。如果它的戰(zhàn)略訴求點是這個，它可以百度買下，從而得到李彥宏。但是，Google在中國，需要的哪里是什么技術專家、研發(fā)中心？現(xiàn)在Google中國戰(zhàn)略要的合適的人是據(jù)稱是“技術專家”的李開復，但他在公眾心目中的號召力和政府公關能力才是Google所看重的。?
????? 我們也可以循同樣的視角來看待雅虎和阿里巴巴之間的聯(lián)姻。這一次是把雅虎中國的業(yè)務交道馬云手中去讓他照料，因為對于誰了解中國市場和能夠幫助雅虎發(fā)現(xiàn)中國市場潛力這個問題，馬云是最佳答案。雅虎在中國的最近兩次戰(zhàn)略行動目標都首先是為了“人”。上一次是雅虎在中國收購3721，反而讓其老板周鴻一擔任中國區(qū)總裁，從而讓雅虎中國從跨國公司在華分支機構這樣的角色變成勇猛的中國本土企業(yè)。但在經(jīng)歷一段發(fā)展時期之后，雅虎中國就需要更合適的人。我們可以認為，這是雅虎、阿里巴巴聯(lián)姻的主要原因之一。?
????? 先建立制度、體系，而不是“因人設事”這樣的觀點被廣泛接受，可是，我們忘記了這個觀念背后的工業(yè)化背景：所有人的都被當成了可替換的零件，所以制度體系最重要。但是，對于知識型工作來說，特別是非重復的創(chuàng)造性工作，每個人的工作方式、結果都截然不同。?
????? 我們所設計的制度體系，在當前的人員安排下也似乎運轉正常。但是，由于這些人是無法替換的，人走了，看似精妙的體系也就出現(xiàn)出現(xiàn)問題了。這個時候，是去做不可能完成的任務：尋找適合制度體系的一摸一樣的人？還是更改體系？或者看得更遠點，在現(xiàn)在的情境下，我們根本就不該把制度體系的重要性神話到這種程度？針對知識型工作的討論，和上文對最高管理者的討論并非沒有聯(lián)系，因為在我看來，管理工作是最重要的、最具創(chuàng)造性的知識工作。?
????? 吉姆·柯林斯在《從優(yōu)秀到卓越》說卓越公司是“先人后事”：這些公司的主管不是先確定目的地（先有方向、愿景、戰(zhàn)略），然后才把人們引向那里；他們首先讓合適的人上車（不合適的人自然請下車），然后才決定去向何處。他所說的雖是方向、遠景，但大體上和制度是同一類型的事物。我們都應該了解，合適的人更重要，那些看似嚴密的戰(zhàn)略分析和完善的制度體系有時候會變成令人難以忍受的障礙，因為它們和“合適的人”可能是完全矛盾的，這些人通常都難以放到一個既定的模子中去。?

今天將webwork2.2.1更換成webwork2.2.2，出現(xiàn)了一個奇怪的異常，每次啟動后，都會報出：
如果將xwork.xml中的global-exception-mappings注釋掉便好

頭疼了幾個小時解決不了，不得不求助飛云小俠
飛云小俠一出手果然不同，馬上定位了問題所在
就是這句：

原來雖然幾次升級webwork.jar，但是xwork.xml的DTD解析還是用的原來的DTD，頂多就是改了DTD的地址，也就是將這句
改為這樣

而實際上解析DTD是靠的前面那句
原來一直是
于是就出現(xiàn)了上面的問題
多謝飛云小俠的幫助^_^

自工作以來，我就養(yǎng)成了睡前讀書的習慣，這一年在武漢，實在買不到一些好書，每次回北京總要帶很多書過來，最近再次面臨回京購書的局面，在回京之前總不能閑著，于是從去年看過的書中亂翻，以第一感覺來決定自己最想重讀那本書，結果選中了溫博格的《成為技術領導者－解決問題的有機方法》
兩年前，當一位同窗好友集齊全套的溫博格系列的時候，我曾很不屑的說他：一個人寫那么多書，質量顯然沒保證，買他作甚？現(xiàn)在看來，當時確是井底之蛙了，溫博格的書中少有瑕疵，尤其是后期作品，讀來總是讓人意猶未盡。
過去的幾年里，我看過很多書，無論是早期GOF的設計模式，Martin Fowler的企業(yè)架構系列，還是Rod的J2EE開發(fā)厚厚的兩卷本，甚至我最喜歡的POSA系列，雖然都會給人技術方面成長的感覺，但最好情況下也只是讓我感覺到技藝的變化。
而管理方面的書籍，則大多走入兩個極端，要么是學院式的分析解構，要么是江湖術士式的技巧集合。就像過去我曾很喜歡DEBORAH G. ANCONA的那本組織行為學和曾士強的中國式管理，但現(xiàn)在看來，DEBORAH關注組織多過于關注團隊，而曾士強則過于強調中國人的心理情結，實用歸實用，但可能不太適合技術人員的口味，讀他的書讓人感覺有些厚黑，讓我常常想到一句俗語：人老精，鬼老靈。

而溫博格的寫作方式，如同Ken在英文版序中所說，會引起大量的思考，對溫博格的文字的思考，思考對溫博格文字的思考，以及對自身思考的思考....通過溫博格的書，讓我體會到的事是，讀書，有時候是為了實用，而的有時候，則純粹是為了過癮。
本書中溫博格的MOI模型，實際上不是一個行為指導手冊，而是帶來了更加宏觀和可思考的空間，讓你對自己在團隊中的行為更加有目的性，也更加有效。我仍然記得兩年前，上述同窗好友在某技術論壇發(fā)表的一篇名為《任務分解和任務分配》的帖子，現(xiàn)在看來，在該貼中提出的Effective Communication仍然太過于關注技術視角了，而現(xiàn)在，我則更加注重人文關懷，包括對技術架構。這一點，在本書第十章得到了精彩的闡述。

下面的內(nèi)容，來自于本書第三章摘錄

各種各樣的想法是解決問題的核心，沒有想法就不可能找到解決方案，但想法太多又會雜亂無章，領導者需要對想法的交流進行有效的管理。以下是領導者常用的12種典型的管理想法交流的方法以及點評。
??? >? 為團隊提供一個聰明的想法。盡管這是最顯而易見的領導者行為，而且有時新的想法的確會起到關鍵性作用，但事實上真正全新的想法是非常罕見的。比發(fā)掘一個新的聰明想法更重要的是創(chuàng)建一個合適的環(huán)境，是能夠解決問題的想法一旦提出就能被大家意識到。
??? >? 鼓勵和借鑒有用的舊想法。盡管有些領導者不愿意承認，但他們實際上是根深蒂固的模仿者。最優(yōu)秀的領導者不僅承認這一點，而且將其視為一門藝術而精心培育。
??? >? 認真完善團隊成員提出的想法。大部分解決問題型領導者在完善一個想法上花費的時間比提出這個想法多上百倍的精力。
??? >? 放棄自己的想法并支持團隊采納的想法，但只有當每個成員都充分了解你的想法時才予以放棄。放棄或保留你的想法是相當簡單的，難的是要做到理智和公正。
??? >? 盡管時間壓力很大，仍然不要吝嗇花時間聽其他人解釋他們的想法。迫于時間壓力，大部分想法沒有經(jīng)過充分理解就被否決了，事實上，其中一些想法可以為我們節(jié)省的時間是花在了解錯誤想法上時間的上百倍。
??? >? 檢驗別人提出的想法。在任何給定的環(huán)境中，絕大部分的想法都是沒用的，但到底哪些才是有用的呢？領導者要做的就是分析和檢驗這些想法。
??? >? 為了保持想法的交流，不要輕易否定團隊成員的想法。盡管檢驗這些想法是非常重要的，但幾乎沒有什么想法會危險到使我們來不及重新考慮一下我們的第一反應，就必須立刻否定。
??? >? 如果你不得不否定一個想法，那么一定要明確，你所否定的只是這個想法，而不是提出這個想法的人。解決問題型領導者一直清楚地知道，并不是所有的想法對每個問題都有幫助，但他們更知道，團隊中的每一個成員都是有用的。
??? >? 在給出你的想法之前要先對它進行檢驗。沒有人可以聰明到提出所有建設性的想法，而一個喋喋不休地發(fā)表自己未經(jīng)仔細考慮的想法的人卻能有效地阻止其他人給出自己的想法。
??? >? 當時間和人力吃緊時，不要再考慮新的想法而應該專注于現(xiàn)有的想法。
??? >? 鼓勵團隊成員放棄以前曾經(jīng)成功過，但并不適用于現(xiàn)在情況的想法。
??? >? 如果一個已被否定的想法對問題的其他部分有價值，就應該重新采納它。其實沒有絕對不好的想法，之所以“不好”只是因為它們出現(xiàn)在不適當?shù)牡攸c或時間。

去年年底，osgi R4發(fā)布，eclipse建立equinox項目，標志著以osgi為核心的組件管理模型正式進入使用階段，鑒于今年年初jsr291的推出，osgi正式走向java世界的前端，遂建立osgi觀察者group，希望能同所有關心和喜愛osgi的國內(nèi)技術人員共同進步。

加入osgi觀察者：

	Subscribe to osgi觀察者
	Email:
	Browse Archives at groups.google.com

最近的忙碌加上精神壓力，讓我患上了胃病，每天吃完飯都會難受好一陣子，給自己學醫(yī)的兒時好友打電話，被勸之：“人生苦短，要學會善待自己每一天”。遂發(fā)此文為戒。

附一篇BJUG中Tin發(fā)的文章《白天紐約黑夜巴黎》
-------------------------------
白天紐約黑夜巴黎
-------------------------------
【王文華／文】

我在趕些什么？我耗盡青春用盡全力，拼命追求身外之物，結果我真的比別人有錢、有名嗎？更重要的，我真的因此而快樂嗎？遠方有廣闊的地平線，為何我還在原地搖過時的呼拉圈？

紐約和巴黎，代表了我人生的兩個面向。紐約是白天，巴黎是黑夜。紐約是前半生，巴黎是下半場。

三十五歲之前，我認定紐約是世上最棒的城市。我在加州念研究所，畢業(yè)后迫不及待地去紐約工作。一做五年，快樂似神仙。我愛紐約的原因跟很多人一樣：她是二十世紀以來世界文化的中心。豐富、方便。靠著地鐵和出租車，你可以穿越時間，前后各跑數(shù)百年。人類最新和最舊、最好和最壞的東西，紐約都看得見。

所以在紐約時，我把握每分每秒去體會。白天，我在金融機構做事，一天十小時。晚上下了班，去NYU學電影，一坐四小時。在那二十多歲的年紀，忙碌是唯一有意義的生活方式。活著，就是要把自己榨干，把自己居住的城市，內(nèi)外翻轉過來。

這種想法并不是到紐約才有的。其實從小開始，臺灣人就過著紐約生活。紐約生活，充滿新教徒的打拚精神和資本主義的求勝意志。相信人要借著不斷努力，克服萬難、打敗競爭。活著的目的，是更大、更多、更富裕、更有名。權力與財富，是紐約人的兩個上帝。而能幫你走進天堂的鞋，就是事業(yè)、事業(yè)、事業(yè)。

在這種弱肉強食的生活方式，為了保持領先，每個人都在趕時間、搶資源。進了電梯，明明已經(jīng)按了樓層的鈕，那燈也亮了，偏偏還要再按幾下，彷佛這樣就可以快一點。出了公司，明明已經(jīng)下班了，卻還要不停講手機，搖控每一個環(huán)節(jié)。在紐約，為達目的，可以不擇手段，甚至趕盡殺絕。在紐約，沒有壞人，只有失敗者。

臺灣，是不是也變成這樣？

每一件事，都變成工作。上班當然是工作，下班后的應酬也是工作。有人談戀愛是在工作，甚至到酒店喝酒、KTV狂歡，臉上都殺氣騰騰，準備拚個你死我活。

我曾熱烈擁抱這種生活，并著迷于這種因為燒烤成功而冒出的焦慮。這種焦慮讓我坐在椅子邊緣，以便迅速地跳起來閃躲明槍暗箭。這種警覺性讓我練就了酒量和膽量、抗壓性和厚臉皮。但也養(yǎng)成了偏執(zhí)和倔強、優(yōu)越感和勢利眼。在紐約時我深信：能在這里活下來的，都是可敬的對手。黯然離開的，統(tǒng)統(tǒng)是輸家。人生任何事，絕對要堅持到底。半途而廢的，必定有隱疾。在這不睡的城市，每天我醒來，帶著人定勝天的活力，跟著法蘭克辛納屈唱〈紐約?紐約〉：「如果你能在紐約成功，你可以在任何地方成功！」是的，在紐約，現(xiàn)代的羅馬競技場，我要和別人，以及自己，比出高低。

這套想法，在我三十五歲以后，慢慢改變。

第一件動搖我想法的，是父親的過世。我父親一生奉公守法、與人為善。毫無不良嗜好，身體健康地像城堡。七十二歲時，他得了癌癥、引發(fā)中風，經(jīng)歷了所有的痛苦和羞辱。他一生辛勤工作、努力存錢、堅信現(xiàn)在的苦可以換得更好的明天。我們也相信一分耕耘、一分收獲，用在紐約拚事業(yè)的精神照顧他。但兩年的治療兵敗如山倒，最后他還是走了。父親逝世的那天，我的價值系統(tǒng)崩潰了。我一路走來引以為傲的「紐約精神」，沒想到這么脆弱。

不止在病床，也在職場。當我在企業(yè)越爬越高，才發(fā)現(xiàn)「資本主義」在職場中也未必靈驗。上過班的都知道，很少公司真的是「開放市場」、「公平競爭」。大部分的同事都覺得你不是朋友、就是敵人。職場上偉大的，未必會成功。成功的，有時很渺小。很多人一輩子為公司鞠躬盡瘁，最后得到一支紀念筆。那些卷款潛逃的，反而變成傳奇。

慢慢的，我體會到：世上有一種比「善有善報、惡有惡報」更高、更復雜的公平。人生有另一種比「功成名就」更幽微、更持久的樂趣。那是沖沖沖的美式資本主義，所無法解釋的。

我能在哪里找到那種公平和樂趣呢？我想過西藏、不丹、非洲、紐西蘭。然后，我注意到法國。

住紐約時，法國是嘲諷的對象。身為經(jīng)濟、科技、和軍事強權的美國，談起法國總是忍不住調侃一番。法國是沒落的貴族，值得崇拜的人都已作古。法國人傲慢，高稅率讓每個人都很慵懶。動不動就罷工，連酒莊主人都要走上街頭。

搬回臺灣后，普羅旺斯、托斯卡尼突然流行。我看了弗朗西斯?梅思的《美麗的托斯卡尼》，其中一句話打動了我：「在加州，時間像呼拉圈。我扭個不停，卻停在原地。在托斯卡尼，我可以在地中海的陽光下，提著一籃李子，逍遙地走一整天。」

是啊！我在趕些什么？我耗盡青春用盡全力，拚命追求身外之物，結果我真的比別人有錢、有名嗎？更重要的，我真的因此而快樂嗎？遠方有廣闊的地平線，為何我還在原地搖過時的呼拉圈？

當我重新學習法國，我發(fā)現(xiàn)法國和美國代表兩種截然不同的生活方式。美國人追求人定勝天，凡事要逆流而上。法國人講究和平共存，凡事順勢而為。紐約有很多一百層的摩天大樓，巴黎的房子都是三百年的古跡。紐約不斷創(chuàng)新，巴黎永遠有懷舊的氣息。巴黎人在咖啡廳聊天，紐約人在咖啡廳用計算機。紐約有人潮，巴黎有味道。紐約有鈔票，巴黎有蛋糕。

不論是政府或個人，法國人都把精神投注在食、衣、住、行等「身內(nèi)之物」。就讓美國去做老大哥吧。要征服太空、要打伊拉克、要調高利率、要發(fā)明新科技，都隨他去。法國人甘愿偏安大西洋，抽煙、喝酒、看足球、搞時尚。當美國人忙出了胃潰瘍，法國人又吃了一罐鵝肝醬。

講到吃，法國有三百種起司、光是波爾多就有五十七個酒的產(chǎn)區(qū)。晚上六點朝咖啡廳門口一坐，一杯紅酒就可以聊三個小時。九點再去吃晚餐，一直吃到隔天凌晨。他們在吃上所花的時間，跟我們上班時數(shù)一樣。但諷刺的是：他們沒有「All
You Can Eat」。

吃很重要，但也要會挑時間，朋友介紹我去試一家法國餐廳，提醒我他們禮拜二、四晚上休息。「為什么？」我問。他說：「因為主廚要回家看足球。」

聰明的主廚懂法律。法國法律規(guī)定一周工作最多三十五小時，大部分的人一年有五周的假期。而美國人把加班當作自己有價值的表示，度假時還拿著手機回E-mail。法國人比美國人會玩。每年六月的巴黎音樂節(jié)，從午后到深夜，幾百場露天音樂會在各處同時舉行，人多到地鐵都暫停收費。每年十月的「白夜」，平日入夜就打烊的店面，徹夜營業(yè)到清晨七點。每年夏天，巴黎市政府在塞納-馬恩省河右岸布置了三段、總長一．八公里的人工海灘。細砂、吊床、躺椅、棕櫚樹，自然海灘有的景致這里都有，讓沒有錢去海邊度假的民眾，也可以享受到海灘風光。

當然，法國這么深厚的文化，不可能只從吃喝玩樂而來。美國人讀書，為了考證照。法國人讀書，為了搞情調。每年十月的讀書節(jié)，大城市的火車站內(nèi)，民眾輪流上臺朗誦詩句。書店營業(yè)到天明，整晚有現(xiàn)場演奏的樂曲。「美食書展」選在銅臭味最重的證券交易所舉辦。小鎮(zhèn)書展的書直接「長」在樹上，讀者必須爬到樹上，把書摘下來品嘗。

一直跟著美國走的臺灣人，會心動嗎？

我心動了。十一月我到巴黎，一位法國朋友來接待我。臨走前我問他：「明天你要干嘛？」

「我要去銀行。」

「然后呢？」我問。

「我不懂你的意思......」

對我來說，「去銀行」是吃完午飯后跑去辦的小事。對法國人來說，這是他一天全部的行程。法國人總是專心而緩慢的，每天把一件小事做好。

這樣的生活，對美國或臺灣人來說，實在是太頹廢了。的確也是。法國失業(yè)率接近10%，高稅率讓雇主寧愿打烊休息，免得幫員工繳稅。巴黎鬧區(qū)紙醉金迷，但郊區(qū)的少數(shù)民族卻沒有工作機會。這些都是黑暗面，但對于每日被強光烤焦的臺灣人，陰暗也許提供了喘息空間。生命的終點都一樣，有錢人的喪禮只是比較多人上香。不斷的追趕只是提前沖向謝幕，為什么不把時間花在慢慢為生命暖場？你不需要一輩子鞠躬盡瘁、死而后已。你可以偶爾伸伸懶腰、安步當車。

我從巴黎回來，臺北并沒有改變。關了兩周的手機再度響起，一通電話找不到我的人會連續(xù)狂call十通。和朋友見面，他很關心地問我：「好了，你現(xiàn)在工作也辭了、歐洲也去了，接下來有什么projects？」

「Projects」？多么紐約的字眼。

我真想說：「好好生活，不就是人生最大的project？」但我知道在熙來攘往的臺北街頭，在不到四十歲的年紀，這樣說太矯情了。況且，我今天之所以有錢有閑享受法式生活，不也正因為我曾在美式生活中得到很多利益？我仍熱愛工作、熱愛紐約，但已不用像二十歲時一樣亦步亦趨、寸步不離。

所以我說：「我還是會早起，白天努力寫作。但到了晚上，我想關掉手機。」

世界少了我，其實無所謂。但我少了我，還剩什么？

他笑一笑：「你這是用紐約來過白天，用巴黎來過黑夜。」

唉，他講得真好！這應該是一個完美的妥協(xié)吧。也許有一天，我能創(chuàng)造自己的「白夜」，讓白天和黑夜融合在一起。但我還沒到那個境界。

「明天星期一，你要干嘛？」他問。

「我要去銀行。」

「然后呢？」

我張大眼睛，停頓了一下。

「然后呢？」他追問。

「然后我會摩拳擦掌，認真地寫一篇文章。」


我們是不是也應該學一學法國人呢？提高些生活質量，注意身體。

很久沒更新blog了，實在太忙，今天看到有朋友在我去年的blog《MINA is a good framwork 》中回復提到比較一下MNA和QuickServer，遂寫一篇小文：

First for all, QuickServer is licensed as LGPL, and MINA as ASL

從我個人角度而言，去年看過QuickServer的源碼，我在項目中采用的每一個框架或類庫都會做綜合評價，通常不會是一個原因導致我采用或沒有采用某個庫或框架，具體最后沒有采用QuickServer的原因忘記了，但是當時給我的總體感覺是，QuickServer雖然很方便，但不會讓我在架構上得到新的好處。而它最大的優(yōu)點則是，支持JDK1.3（如果沒記錯的話），另外就是License的問題

下面看一看來自TrusinLee的評論：

Thank for the information about another network application framework.  I found a few differences:

* QuickServer supports blocking mode.  (MINA supports only non-blocking mode, but you can make your operation block at your will.)
* QuickServer provides GUI-based admin.  (MINA doesn't have one yet, but will have full JMX support soon, which is a standard.)
* QuickServer uses java.util.logging.  (MINA uses SLF4J, which is a safe replacement of commons-logging.)
* QuickServer uses its own XML settings.  (MINA provides Spring framework integration instead.)
* QuickServer can specify maximum number of clients allowed.  (MINA can do this using a filter, but not implemented by default.  Of course, this will be implemented as an overload prevention filter.)
* QuickServer team has one crew.  (MINA has three crews.)
* QuickServer project started in 2003.  (MINA started in 2005.)
* QuickServer has a difference event handler interface from MINA.  (You'll have to compare it by yourself.  IMHO, MINA has one simple enough handler which covers all QuickServer provides.)
* QuickServer doesn't support UDP at all.  (MINA does)
* QuickServer doesn't support client-side API at all.  (MINA does)
* QuickServer integrated authentication and text protocol in its core.  (MINA didn't and they are considered as a cross-cutting concern that a filter should take care of.  IMHO, MINA is more extensible here.)


至于對MINA更詳細的介紹，可以看看我去年翻譯的MINA的Tutorial

MinaTutorialInChinese

MINA的應用，在MINA的Testimonials中有兩個項目：
開源Flash server：red5
http://ludonet.leonardo.it/的game server
還有，就是MINA所在的項目，Apache的LDAP

昨天david問到如何將舊的swt應用轉成一個RCP應用，昨晚胃疼難忍，于是草草說了一下，就早早上床休息了，早上起來又想起這件事情，遂在這里說一下思路
下面說一下我的思路
（注：以下觀點未經(jīng)證實，請自行斟酌使用）

一個舊的SWT應用，應該都是有一個main函數(shù)里初始化一些UI組件，然后run一個事件循環(huán)

在RCP中，由于是基于Eclipse的插件體系，也就是說，使用我前面那篇文章發(fā)布的RCP Application，是可以直接發(fā)布成Eclipse插件的
所以，對于UI組件的控制也要遵循Eclipse的插件體系的代碼要求，看看Hello RCP模板中的幾個類：ApplicationActionBarAdvisor、ApplicationWorkbenchAdvisor、ApplicationWorkbenchWindowAdvisor以及RCPPlugin，想起了什么？對，OSGI

我們只要將原swt的main函數(shù)中初始化的ui組件，放入到這幾個Advisor中進行初始化

將下拉菜單項的ui組件的初始化工作放入到ApplicationActionBarAdvisor的如下方法：

將其他UI組件初始化工作放入到ApplicationWorkbenchWindowAdvisor的如下方法：

至于ApplicationWorkbenchAdvisor這個類，我想你一定想起了Eclipse中的Workbench概念
在這里，可以定義當這個RCP作為plugin的時候的Worbench的透視圖的一些屬性。

-----------------------------------

最后，基于Eclipse3.1的product方式的RCP程序將獲得同Eclipse相同的插件體系支持
也就是說：你的應用本身就是基于Eclipse Platform的，這樣，你的程序也可以接受插件插入了（如果你設計的好的話^_^）
另外，還有其他很多好處，比如在線升級功能的自動綁定啊，幫助功能的使用啊等等
想一想，你的程序將既能作為單獨的程序運行，又能作為Eclipse的插件運行，而且還跨平臺，think about it...
So....try it now, you will get more

     摘要: Eclipse3.1剛剛release的時候，它的RCP發(fā)布功能就很吸引我，當時正好有個小東西要做，就用了這個功能發(fā)布了一個小程序，似乎很多人推薦用NSIS，但是我覺得Eclipse的這個功能似乎更方便，幾乎不用擔心任何部署的問題。
  閱讀全文

Blog有一個多月沒有更新了，今年8個月的忙碌生活，以及最后兩個月的突擊使我徹底失去了熱情，無論是工作還是寫blog，目前只想每天休息休息，看看書。
12月底回了一趟北京，然后又順路回大連家中辦了點事情，待了三天，又飛回武漢著手招人和培訓的工作，為明年的工作做準備，技術上有些事情還得自己動手，不知道這忙碌的生活什么時候可以停歇.....

在妖精群里還跟非魚說要寫一篇關于架構師職責的Blog，暫時還是沒心情寫，不過自從那次在群里討論過架構師的職責之后，似乎已經(jīng)有很多人寫了這方面的文章，在blogjava中就有很多了，架構師之家的文章數(shù)目也一下激增起來。

近期blogjava也是好戲連臺，雖然不寫，看著也是過足癮了。

canonical是個很好的寫手，學理論物理出身的思維縝密果然不同凡響，關于架構師的職責那篇，已經(jīng)把能寫的都寫盡了。江南白衣 搞的springside.org.cn看起來也很吸引人，有理想的好青年的典范。非魚的幾篇關于架構的文章也寫的很扎實，預備役架構師是有些謙虛了，呵呵。Jerry在經(jīng)過一段時間的忙碌之后，似乎又再次復活了，以每天一到兩篇的速度持續(xù)更新blog，讓我著實佩服他的精力，幾篇blog的涉獵范圍so廣，足見積累之深。老莊最近似乎也是瑣事纏身，除了在上月底被Rx反敲喪鐘的時候露了幾次臉，就沒怎么出現(xiàn)過，看來年底了哪里都是忙碌的時候。Raimundox近期多次出手，除了對老莊的《喪鐘》系列的再次釋疑之外，還為我們貢獻了Smalltalk的入門手冊，實為近期技術blog中風頭最勁的一個了。飛云小俠也更新漸少了，除了今天預告了WebWork2.2的發(fā)布，已經(jīng)10天沒更新了。近期weide的技術架構評估也是頗為扎眼，算是近期最全面完整的一篇技術文章了，顯然是花了精力了，難怪達到14709的訪問量 :)

2005年讓我感覺到人的精力畢竟有限，以及，一個純技術人員能發(fā)揮的能量實在太小了，雖然不情愿，但這可能促使我更早的脫離純技術崗位，真是凌亂的一年......

 

開發(fā)一個基于消息的解決方案是不容易的事情，在生產(chǎn)中操作這樣一個產(chǎn)品同樣也是一個挑戰(zhàn)：一個基于消息的集成解決方案一天可以產(chǎn)生、路由和轉換成千上萬的消息。我們不得不處理異常、效率瓶頸或改變合作系統(tǒng)。而為了使事情變得更加有挑戰(zhàn)性，組件經(jīng)常被分布在不同的平臺和機器上，甚至位于不同的地理位置。

 

System Management包含以下幾種模式

l         Control Bus

l         Detour

l         Wire Tap

l         Message History

l         Message Store      

l         Smart Proxy

l         Test Message

l         Channel Purger

 

 

除了與生據(jù)來的復雜性、分布式集成的規(guī)模以及個性化的應用之外，低耦合的架構使得測試和debug變得更加困難。Martin Fowler將這個癥狀稱為“架構師的夢想，開發(fā)者的夢魘”。低耦合的架構原則以及間接的依賴于外部系統(tǒng)提供了靈活性。然而，測試一個消息生產(chǎn)者不了解消息消費者的系統(tǒng)可能會是一個挑戰(zhàn)。另外異步的和時間相關的消息使得事情變的更加復雜。舉例來說，消息方案可能被設計沒有被成消息生產(chǎn)者者必須從接受者那里得到一個回應。同樣的消息基礎設施通常保證傳輸消息，但不能保證傳輸時間。這是的開發(fā)基于消息傳送結果的測試用例變得困難。

 

當監(jiān)控一個消息解決方案，我們可以在兩個抽象層面上跟蹤消息流。一個典型的系統(tǒng)管理方案監(jiān)控多少消息被發(fā)送或者它多長時間得到一個被處理的消息。這些監(jiān)控方案不檢查消息數(shù)據(jù)，除了可能會檢查消息頭中的幾個字段（比如消息標識或者消息歷史）。與之相對的，BAM（business activity monitoring）方案聚焦于包含在消息中的有效數(shù)據(jù)，舉例來說，發(fā)生在過去一小時的所有訂單的金額。System Management中的很多模式都足夠通用并可以用在以上兩個目的中（監(jiān)控消息頭或者消息內(nèi)容）。然而，由于BAM本身就是一個新領域，并且需要從數(shù)據(jù)倉庫中獲得很多數(shù)據(jù)（有些我們根本就沒有涉及到），我們決定在系統(tǒng)管理的內(nèi)容中討論這些模式。

 

系統(tǒng)管理模式被設計用于為保持一個基于消息的復雜系統(tǒng)的運轉所提出的需求并提供工具。System Management的模式涉及三個種類：監(jiān)控和控制，觀察和分析消息流量，測試和調試。

 

監(jiān)控和控制

 

一個Control Bus提供一個單獨的控制點來對一個分布式方案進行監(jiān)控和管理。它將多個組件連接到一個中心管理控制臺，這里可以顯示每個組件的狀態(tài)并且監(jiān)控通過每個組件的消息流量。控制臺同時也可以用于發(fā)送控制命令給組件，比如，轉變消息流。

我們可能想要在路由消息時添加附加的步驟，比如驗證或者日志。由于這些步驟可能使效率降低，所以我們可以通過Control Bus來控制他們開關。一個Detour為我們提供這種能力。

 

觀察和分析消息流量

 

有時我們想要在不影響主要消息流的情況下觀察消息的內(nèi)容。一個Wire Tap允許我們接入到消息流中。

當我們調試一個基于消息的系統(tǒng)，知道一個特定的消息在哪使很有幫助的。Message History保留一個消息訪問過的所有組件的日志，而不需要增加組件間的依賴。

然而Message History依賴于單獨的消息，一個中心的Message Store可以提供一個穿越系統(tǒng)的每個消息的完整記錄。結合Message History，Message Store可以分析所有消息穿過系統(tǒng)的可能路徑。

Wire Tap, Message History, 和Message Store幫助我們分析異步的消息流。為了跟蹤發(fā)送到請求-應答service的消息，我們需要在消息流中插入一個Smart Proxy。

 

測試和調試

 

在部署前測試一個消息系統(tǒng)是一個非常好的注意。但是測試不應該停止在部署前。你應該有能力驗證正在運行的消息系統(tǒng)運行持續(xù)的運行正常。你可以周期性的發(fā)送一個Test Message到系統(tǒng)中并驗證結果。

當一個組件失敗或者運行不正常，它可以簡單的終止，并放棄一個channel中的剩余消息。在測試期間這是很有用的。一個Channel Purger可以為我們做這些。

 

最近身體不太好，轉貼一則文章，提醒自己多多休息和鍛煉。

－－－－－－－－－－－－－－－－－－－－－－－－

　只要踏入在我們IT這個行業(yè), 過不了幾年身體就是亞健康狀態(tài),過渡的話就可能會“過勞死”,要想防止“過勞死”，就必須了解身體為我們發(fā)出的“過勞死”信號。

    研究者認為：在這27項癥狀和因素中占有7項以上，即是有過度疲勞危險者，占10項以上就可能在任何時候發(fā)生“過勞死”。同時，在第1項到第9項中占兩項以上或者在第10項到18項中占3項以上者也要特別注意，這27項癥狀和因素分別是：

　　1.經(jīng)常感到疲倦，忘性大；

　　2.酒量突然下降，即使飲酒也不感到有滋味；

　　3.突然覺得有衰老感；

　　4.肩部和頸部發(fā)木發(fā)僵；

　　5.因為疲勞和苦悶失眠；

　　6.有一點小事也煩躁和生氣；

　　7.經(jīng)常頭痛和胸悶；

　　8.發(fā)生高血壓、糖尿病，心電圖測試結果不正常；

　　9.體重突然變化大，出現(xiàn)“將軍肚”；

　　10.幾乎每天晚上聚餐飲酒；

　　11.一天喝5杯以上咖啡；

　　12.經(jīng)常不吃早飯或吃飯時間不固定；

　　13.喜歡吃油炸食品；

　　14.一天吸煙30支以上；

　　15.晚上10時也不回家或者12時以后回家占一半以上；

　　16.上下班單程占2小時以上；

　　17.最近幾年運動也不流汗；

　　18.自我感覺身體良好而不看病；

　　19.一天工作10小時以上；

　　20.星期天也上班；

　　21.經(jīng)常出差，每周只在家住兩三天；

　　22.夜班多，工作時間不規(guī)則；

　　23.最近有工作調動或工作變化；

　　24.升職或者工作量增多；

　　25.最近以來加班時間突然增加；

　　26.人際關系突然變壞；

　　27.最近工作失誤或者發(fā)生不和。

　　針對如何擺脫過度疲勞，何永成博士開出如下處方：

　　消除腦力疲勞法：適當參加體育鍛煉和文娛活動，積極休息。如果是心理疲勞，千萬不要濫用鎮(zhèn)靜劑、安眠藥等，應找出引起感情憂郁的原因，并求得解脫。病理性疲勞，應及時找醫(yī)生檢查和治療。

　　飲食補充法：注意飲食營養(yǎng)的搭配。多吃含蛋白質、脂肪和豐富的B族維生素食物，如豆腐、牛奶、魚肉類，多吃水果、蔬菜，適量飲水。

　　休息恢復法：每天都要留出一定的休息時間。聽音樂、繪畫、散步等有助解除生理疲勞。

　　科學健身方法：一是有氧運動，如跑步、打球、打拳、騎車、爬山等；二是腹式呼吸，全身放松后深呼吸，鼓足腹部，憋一會兒再慢慢呼出；三是做保健操；四是點穴按摩。

    哥們, 上面27條在你身上出現(xiàn)幾條癥狀了?  怕怕吧? 

　　建議哥們們每天早上和傍晚各抽出一小時鍛煉身體,畢竟身體是革命的本錢!

轉自: 電子商務論壇 http://bbs.eczn.com/

上面下劃線的是我有的問題，你都有哪些？

經(jīng)過這半年的使用，WTP在我們組內(nèi)已經(jīng)從只用于開發(fā)Web Service的工具變成web開發(fā)的首選插件
雖然只是0.7版，但WTP的設計確實很好，目前WTP1.0已經(jīng)release到了M9，還有20幾天就到達release date了，熱烈期待中....

在ESB中另外一個重要的課題就是Message Endpoint，這是關于一個應用程序如何連接到一個消息系統(tǒng)，并通過它來發(fā)送和接收消息。如果你在面向一個消息API編程，則你就正在開發(fā)一個endpoint代碼。商業(yè)中間件通常都提供了這些工具。

 

l         Messaging Gateway

l         Messaging Mapper

l         Transactional Client

l         Polling Consumer

l         Event-Driven Consumer

l         Competing Consumers

l         Message Dispatcher

l         Selective Consumer

l         Durable Subscriber

l         Idempotent Receiver

l         Service Activator

 

發(fā)送和接收模式

 

有些endpoint模式既可以使用在發(fā)送方也可以使用在接受方。它們描述一個應用連接一個消息系統(tǒng)的一般情況。

 

包裝消息代碼 － 一個應用不應該意識到正在使用消息同另外一個應用程序通訊，大多數(shù)應用代碼應該在不知道message的情況下被編寫。在應用集成的地方，應該有一個薄薄的一層代碼來執(zhí)行應用的集成部分。當集成是由消息實現(xiàn)的，這層將應用連接到消息系統(tǒng)的代碼稱為一個Message Gateway

 

數(shù)據(jù)轉換 － 當發(fā)送者和接受者使用不同的數(shù)據(jù)格式，或者不同的消息格式（支持不同的發(fā)送和接收者），在這種情況下，使用一個Message Mapper來在應用格式和消息格式之間轉換數(shù)據(jù)。

 

外部控制的事務 － 消息系統(tǒng)在內(nèi)部和外部使用事務，默認的，每個發(fā)送和接收方法在他們自己的事務中運行。Message生產(chǎn)者和消費者應可選的使用一個Transactional Client來控制事務，當你需要將幾個消息一起發(fā)送伙通過其他事務服務整理消息時是很有用的。

 

消息消費者模式

 

其他endpoint模式只適用于消息消費者，發(fā)送消息是簡單的。棘手的問題是決定一個消息應該何時發(fā)送，它應包含什么，以及怎樣將它送到接受者 － 這是為什么我們有很多消息結構模式 － 但是一旦消息被構建，發(fā)送它是很容易的。另一方面，接收消息 － 很麻煩。因此許多endpoint模式是關于接收消息的。

 

接收消息的一個最重要的主題就是流量控制：一個應用控制，或者調節(jié)它消費消息的速度。一個潛在的問題是任何server都面臨著大量的客戶端請求會使其超載。通過遠程過程調用（RPI），server幾乎受到客戶端調用的支配。同樣的，通過消息，server不能控制客戶端發(fā)送請求的速度 － 但是server可是控制它處理這些請求的速度。應用不必像消息系統(tǒng)傳送消息那么快的接收并處理消息；使用一個Message Channel可以使它在一個可接收的速率上處理消息。然而，當消息積累太多，而server還有資源可以處理的更快，它可以使用同步message消費者來加快速度。所以使用這些消息消費者模式可以讓你的應用將速度控制在它可以承受的范圍。

 

許多消息消費者模式都是成對出現(xiàn)的，你可以任選一個使用。

 

同步或異步接受者 － 可以使用輪詢消費者或一個事件驅動消費者。輪詢提供最好的流量控制，因為如果server忙，則它不再繼續(xù)輪詢消息，所以message將阻塞在隊列。事件驅動的消費者傾向于消息到達便觸發(fā)處理，所以有可能會使server超載，但是每個消費者每次只處理一個消息，所以限制消費者的數(shù)量可以有效的控制消費速度。

 

消息分派 vs 消息獲取 － 另外一個二選一的模式是一堆消費者如何處理一堆消息。如果每個消費者獲得一個消息，他們可以并行的處理消息。最簡單的方法是Competing Consumers，也就是一個點對點的channel有多個消費者。每個都可能獲得任何消息；消息系統(tǒng)的實現(xiàn)決定那個消費者獲得消息。如果你想控制消息到消費者的匹配過程，使用Message Dispatcher。這時只有一個消費者接收消息，但是將委派消息到一個執(zhí)行者去處理。一個應用程序可以通過限制消費者或執(zhí)行者的數(shù)量來控制流量。當然，分派者Message Dispatcher也可以實現(xiàn)一個流量控制行為。

 

接收所有消息或者過濾 － 默認的，任何到達一個Message Channel的消息對于監(jiān)聽著這個channel的Message Endpoint都是可用的。然而有些消費者并不打算處理channel上的任何消息，而是希望只處理其中幾種。這樣一個識別的消費者可以使用一個Selective Consumer來描述它將接收什么類型的消息。然后消息系統(tǒng)將只將匹配的消息對該接受者描述為可用。

 

當斷開連接的時候訂閱消息 － Publish-Subscribe Channels帶來的問題是，如果一個消費者感興趣一個channel，但是現(xiàn)在網(wǎng)絡是斷開的怎么辦？是不是一個未連接的應用將錯過發(fā)布的消息，即使它已經(jīng)訂閱過該消息?默認的，是的，訂閱只對連接的訂閱者有效，為了使應用不會因為連接而錯過訂閱的消息，要使用Durable Subscriber。

 

等冪 － 有時一個消息可能被傳輸不只一次，可能因為消息系統(tǒng)不確定該消息是否已經(jīng)被成功的傳遞過，或者可能因為Message Channel的QoS被設置較低來提高效率。另一面的，消息接受者認為每個消息只會被傳輸一次，并且當它們重復處理相同的消息，它們會出錯。一個Idempotent Receiver可以優(yōu)雅的處理重復的消息，并且阻止它們引起接收者應用的發(fā)生錯誤。

 

同步或異步服務 － 另外一個選擇是一個應用應該暴露它的service為同步（RPI）還是異步的（Messaging）。不同的客戶端可能喜歡不同的方式；不同的環(huán)境可能需要不同的方式。既然很難選擇，就一起使用。一個Service Activator連接一個Message Channel到一個應用的同步服務以便當一個消息被接收，service就被調用。同步客戶端可以簡單的直接調用service；異步客戶端可以通過發(fā)送消息調用service。

 

Message Endpoint的相關主題

 

Message Endpoint的另外一個重要主題是很難同其他模式共同應用Transactional Client。Event-Driven Consumer通常不能適當?shù)脑谕獠靠刂剖聞眨?/SPAN>Message Dispatcher也必須小心的設計這個問題，Competing Consumers的事務也是個重大問題。最安全的使用Transactional Client是使用一個單獨的Polling Consumer，但是這不會是一個令人滿意的解決方案。

 

這里特別要提到應該會保證成功的JMS風格的MDB，EJB的一種。一個MDB是一個消息消費者，它即使一個Event-Driven Consumer又是一個支持J2EE分布式事務的Transactional Client，并且它可以作為Competing Consumers動態(tài)的池化，甚至作為一個Publish-Subscribe Channel。這是在一個自由的應用中實現(xiàn)這些是一個困難且乏味的組合，但是這個功能作為一個EJB容器的內(nèi)建的功能被提供。（MDB框架如何實現(xiàn)的？本質上，容器通過一個動態(tài)改變大小的可重用的執(zhí)行者的線程池來實現(xiàn)了一個Message Dispatcher，在那里每個執(zhí)行者自己使用自己的session和事務來消費消息。）

 

最后，緊記一個單獨的Message Endpoint可以很好結合幾個不同的模式。一組Competing Consumers可以被作為Polling Consumers實現(xiàn)，同時也可以是一個Selective Consumers并且可以作為一個Service Activator調用一個應用的service。

一個Message Dispatcher可以是一個Event-Driven Consumer和一個使用Messaging Mapper的一個Durable Subscriber。無論一個endpoint實現(xiàn)什么模式，它總是一個Messaging Gateway。所以，不要考慮使用哪種模式 － 而要考慮如何結合他們。這是使用模式解決問題的魅力所在。

 

要實現(xiàn)一個Message Endpoint有很多選擇。Message Endpoint模式用于解釋這些選擇是什么以及如何最好的使用它們。

 

 

 

 

 

通常，通過消息系統(tǒng)集成的應用很少有同樣的消息格式。比如說，一個帳務系統(tǒng)同一個CRM系統(tǒng)對客戶對象是有著不同的概念的。基于這個，一個系統(tǒng)可能將消息存儲在關系表中，另一個可能存儲在文件中。集成已存在的系統(tǒng)通常意味著我們沒有修改系統(tǒng)以便使他們更好的一起工作的自由。然而，集成方案不得不協(xié)調和解決各種系統(tǒng)之間的不同。Message Translator模式提供了一個通用的解決方案。這里解釋幾種特定的Message Translator。

 

Message Transformation包含以下幾種模式：

l         Envelope Wrapper

l         Content Enricher

l         Content Filter

l         Claim Check

l         Normalizer

l         Canonical Data Model

 

大多數(shù)消息系統(tǒng)放置特定的需求在消息頭的格式和內(nèi)容中。我們包裝有效數(shù)據(jù)到一個Envelope Wrapper中以適應消息基礎設施的需求。如果消息需要穿過不同的消息基礎設施，可以結合多個Envelope Wrapper。

如果原始系統(tǒng)不能提供目標系統(tǒng)需要的數(shù)據(jù)域，可以使用一個Content Enricher。它可以查找缺少的信息并從已有數(shù)據(jù)中計算出它。Content Filter正好相反，它從消息中刪除不需要的數(shù)據(jù)。Claim Check也從消息中刪除數(shù)據(jù)，但是它將存儲他們以便以后取回。Normalizer將多個不同格式的消息翻譯成統(tǒng)一格式。

 

消除依賴

 

消息轉換在集成中是一個很深的話題。Message Channels和Message Routers可以通過消除應用必須知道另外一個應用的位置的需求從而解除應用間的基本依賴。

一個應用可以發(fā)送一個消息到Message Channel而不必擔心誰來取出消息。然而消息格式增加了另外一種依賴。如果一個應用不得不將消息格式化成另外一個應用的數(shù)據(jù)格式，通過Message Channel解耦的說法就像一個幻想。接收系統(tǒng)的任何改變或切換到另外一個接收系統(tǒng)都需要對發(fā)送應用進行改變。Message Translators可以幫助除去這種依賴。

 

元數(shù)據(jù)管理

 

將消息從一個消息格式轉換到另一個格式需要操作元數(shù)據(jù) － 描述數(shù)據(jù)格式的數(shù)據(jù)。

元數(shù)據(jù)在兩個并行系統(tǒng)之間的集成中扮演著非常重要的角色。一個處理實際的消息數(shù)據(jù)，另外一個處理元數(shù)據(jù)。許多用于處理消息數(shù)據(jù)的模式也同樣可以管理元數(shù)據(jù)。比如說，Channel Adapter不僅可以從一個系統(tǒng)中移進和移出消息，還可以從一個外部應用中獲取元數(shù)據(jù)，并將其加載到一個元數(shù)據(jù)倉庫中。使用這個倉庫，集成開發(fā)者可以定義應用元數(shù)據(jù)與Canonical Data Model.之間的轉換。

 

 

元數(shù)據(jù)集成

 

舉例來說，上面的圖描述了兩個需要交換客戶信息的應用的集成。每個系統(tǒng)的客戶數(shù)據(jù)的定義稍有不同。從A到B的消息需要轉換一下才能被B接收。如果Channel Adapters可以抽取元數(shù)據(jù)的話，創(chuàng)建一個轉換將非常簡單。然后這個元數(shù)據(jù)可以被放入一個倉庫，大大的簡化了Message Translator的配置和驗證。元數(shù)據(jù)可以被存儲成不同的格式。通常XML消息使用XSD格式。其他EAI工具實現(xiàn)所有元數(shù)據(jù)格式，但是允許管理員導入或導出到其他格式。

 

消息系統(tǒng)外的數(shù)據(jù)轉換

 

這些轉換模式組成的很多原則可以被應用于非消息集成。比如說，File Transfer可以執(zhí)行系統(tǒng)間的轉換工作。類似的，Remote Procedure Invocation必須使請求使用要調用的service的格式，即使應用本身的格式可能不同。典型的，需要調用程序來執(zhí)行轉換。一些最成熟的轉換引擎組成了ETL工具，比如Informatica或者DataMirror。這些工具一般都一次轉換大量的數(shù)據(jù)，而不是轉換單個消息。

Message System應專注于幾種基本的Message Translator模式。而不應該關心實體間結構轉換的細節(jié)（不同的數(shù)據(jù)模型之間的轉換，比如ER模型不支持多對多關系而其他的支持這種）。關于這個主題最老也使最相關的書是Kent的《Data and Reality》。

 

在前面的關鍵組件中我們提到了Messages。當兩個應用想要交換數(shù)據(jù)，他們將數(shù)據(jù)包裝在一個message中。但是一個Message Channel不能傳輸原始數(shù)據(jù)，它只能傳輸包含在一個message中的數(shù)據(jù)（即傳輸特定格式的數(shù)據(jù)）。

 

Message在消息系統(tǒng)中處于信息載體的位置，而在ESB中，還消息識別、序列以及生存周期等職責。

 

Message的結構涉及以下幾個模式：

l         Command Message      

l         Document Message      

l         Event Message

l         Request-Reply

l         Return Address

l         Correlation Identifier

l         Message Sequence

l         Message Expiration

l         Format Indicator

 

創(chuàng)建和發(fā)送一個Message產(chǎn)生以下幾個問題：

 

消息意圖 － Message最終是為了運送一些數(shù)據(jù)，但是發(fā)送者可能有其他目的，比如它希望接受者使用消息做些事情。它可以發(fā)送一個Command Message，指定它希望調用的接受者上的函數(shù)或方法。發(fā)送者告訴接受者運行那些代碼。發(fā)送者可以發(fā)送一個Document Message來傳送它的數(shù)據(jù)結構到接受者。發(fā)送者發(fā)送數(shù)據(jù)到接受者，但是不指定接受者應該做什么。

或者它可以發(fā)送一個Event Message，通知接受者發(fā)送者那里有一個改變。發(fā)送者不應告訴接受者應該怎樣適應這個改變，而只應提供通知。

 

返回一個應答 － 當一個應用發(fā)送一個消息，它通常期望得到一個回應來確定消息被處理并提供一個結果。這是一個Request-Reply場景。Request通常是一個Command Message，而應答是一個包含返回值或異常的Document Message。請求者應該在請求中指定一個Return Address來告訴應答者使用哪個通道來傳回應答。請求者可能在一個處理過程中發(fā)送多個請求，所以應答應該包含一個Correlation Identifier來指出這個應答對應哪個請求。

有兩個Request-Reply場景需要注意；它們都包含了一個Command Message請求和一個對應的Document Message應答。在第一個場景中，Message RPC，請求不但要調用應答者的函數(shù)，而且期望一個返回值。這是RPC。另一個場景中，Message Query，請求者執(zhí)行一個查詢；應答者執(zhí)行查詢并在應答中返回結果。這是遠程查詢。

 

大量的數(shù)據(jù) － 有時應用想要傳送大量的數(shù)據(jù)結構，放入一個單獨的message里面不是很合適。在這種情況下，將他們分解成可管理的消息塊并將他們作為Message Sequence發(fā)送。這些消息必須按順序發(fā)送，以便接受者能夠充足原始數(shù)據(jù)結構。

 

慢速消息 － 消息系統(tǒng)的一個問題是發(fā)送者通常不知道接受者要多久才能接受到消息。然而，消息的內(nèi)容可能是時間敏感的，所以如果消息在某一時間內(nèi)沒有被接受，它將被忽略并取消。在這種情況下，sender應該使用Message Expiration來指定一個到期時間。如果消息系統(tǒng)在規(guī)定時間內(nèi)無法傳輸一個消息，應該將它取消并刪除到Dead Letter Channel中。同樣的一個receiver接受到一個超出該時間點的消息，也要取消該消息。

 

總之，只選擇使用消息是不夠的。使一個消息工作的其他決定性因素來自于消息所要完成的任務。