漁人碼頭

寫的很不錯啊！非常感謝！

白衣，為什么www.springside.org.cn 訪問不了啊？ 持續有段時間了啊

GetMethod method=new GetMethod("http://www.baidu.com/");

GetMethod ?

這個東西哪來的?

同上，拿什么做圖示的？

好久沒有搞Java了，想不到這么多朋友看了我的帖子，呵呵
很高興能幫到樓上的那個朋友。

最近我發現有個叫網絡爬蟲的開源組建那些，應該會比我這個辦法好

如何輸出的流程文件

請問addTransition()是加在哪個類里？

強！！！！！！

不錯，期待作者能將它封裝一下。

大哥，請給我也發一份。 謝謝
fisher_yu126@126.com

@Samuel.Mo

在我當時翻譯的時候，并沒有0.9以后版本的MINA
而Trustin Lee也在mina的doc中指出了0.9以后版本的架構變化
我想是你關注的太少了

http://www.apachefriends.org/zh_cn/xampp-linux.html

整合的apache

下載不到啊～ 能夠提供下載嘛？

hehe，很高興我有了第一個留言者

好文！收藏了，謝謝！

very interesting

轉載一些代碼，使用HttpUrlConnection來模擬ie form登陸web：


關于java模擬ie form登陸web的問題

HttpURLConnection urlConn=(HttpURLConnection)(new URL(url).openConnection());
urlConn.addRequestProperty("Cookie",cookie);
urlConn.setRequestMethod("POST");
urlConn.setRequestProperty("User-Agent","Mozilla/4.0 (compatible; MSIE 6.0; Windows 2000)");
urlConn.setFollowRedirects(true);
urlConn.setDoOutput(true); // 需要向服務器寫數據
urlConn.setDoInput(true); //
urlConn.setUseCaches(false); // 獲得服務器最新的信息
urlConn.setAllowUserInteraction(false);
urlConn.setRequestProperty("Content-Type","application/x-www-form-urlencoded");
urlConn.setRequestProperty("Content-Language","en-US" );
urlConn.setRequestProperty("Content-Length", ""+data.length());

DataOutputStream outStream = new DataOutputStream(urlConn.getOutputStream());
outStream.writeBytes(data);
outStream.flush();
outStream.close();

cookie=urlConn.getHeaderField("Set-Cookie");
BufferedReader br=new BufferedReader(new InputStreamReader(urlConn.getInputStream(),"gb2312"));

@QQ:30903953
sorry，我不跟蹤MINA已經很久了，由于工作的原因，目前具體開發技術上的事情關心比較少，恐怕也幫不到你什么

角色轉換既然是無法避免的，延長轉換的時間又有什么意義呢？難道是為了壓縮自己對未來的思考時間嗎？
我倒認為，如果具備相應的條件，應盡早讓自己適應這種轉變，單純的開發活動不會帶來任何實際的意義，而設計思想的理解對未來的工作才有實際意義。但是未來的工作可能需要對管理和人更多的關注，臨時抱佛腳恐怕是很難的吧

成功的通訊框架有很多，最成功的莫過于C++的ACE，目前C的apr、python的twisted，都算是很成功的通訊框架

JDBC數據源每次都要重新連接一次數據庫，而腳本數據源可以自己在數據源內使用數據庫連接池，所以腳本數據源明顯效率高于JDBC數據源

:)

這.TEXT的編輯器排版簡直太難了，排了一上午

charls == charlesxp??

恭喜恭喜^_^

歡迎討論^_^

@guitarpoet

^_^

@ guitarpoet

我的意思是說，不要拘泥于分層開發還是分模塊開發
而是要認清為什么要分層，為什么要分模塊，有什么好處，有什么弊端
以前有人問我某個設計該怎么分層，我說，理解為什么要分層就知道該怎么分層了
不要為了分層而分層
況且，分層不足以描述軟件開發的根本問題，它只是解決根本問題的表現手法之一
這我在前面已經說過了

忙里偷閑上來看看^_^
接jerry的話，我也會來說說我的項目的情況

其實我覺得分層或分模塊的說法并不準確
何謂分層？何謂分模塊呢？

咱們先繞開這個容易引發爭論的定義，來說說實際情況
在J2EE應用中，似乎分層是很自然的想法
簡單的說，我們要分：表現層、邏輯層、持久層
然后分模塊，則是一個人負責一個功能模塊，貫穿所有層

現在，我們來跳出J2EE領域，看看軟件開發其他領域是什么樣的
比如，一個電信基礎業務系統開發
我們假設，包括語音平臺、帳務平臺、后臺主機系統、前端接入系統、計費平臺、業務管理平臺等
在系統設計中，我們分為語音模塊開發、帳務系統模塊開發、主機通訊系統開發、前端接入系統開發、計費及業務管理系統開發
那么這是分層還是分模塊呢？
顯然，一個人做一個業務的全套處理是不可能的（我很想結識能做到的xd），所以，這不會是分模塊開發。
如果說是分層，那么邏輯層在哪里？持久層在哪里？另外的問題是主機通訊系統將會貫穿始終，這應該算哪一層？并且帳務處理會使所有層的數據產生強烈耦合。

同樣的問題，出現在銀行綜合業務處理系統
一個銀行綜合業務處理系統中，我們分為主機系統、主機客戶帳分錄系統、IBS系統、柜面系統、電話銀行接入模塊、ATM系統及接入模塊、網銀系統及接入端點模塊
下面我們來分一下層，按照J2EE的慣例，我們分為表現層、邏輯層和持久層
首先表現層為所有接入模塊及柜面系統、邏輯層是什么呢？IBS？客戶帳系統？還是主機系統？那么持久層呢？按照銀行開發的情況，一般來說，數據分別存儲在Host，客戶帳系統、IBS和網銀上。那么我們顯然不能夠分層開發
那么所謂分模塊呢？哦....我還無緣得識這樣的朋友

所以說，分層還是分模塊，不過是J2EE中的一個idiom
從軟件開發出現到現在，軟件開發的重點仍然是依賴管理，清晰的接口（無論是java中的interface還是c中的.h文件）使得子系統（無論是一個模塊還是一段代碼）的開發人員可以只依賴與接口編程，這才是團隊開發的重點，如果你沒有接口，你就要管理開發人員之間的依賴，如果你有接口，你就要管理接口兩端的依賴。總要有個合作工作的基礎，我們才能繼續前進。

在這點上，似乎英文使用者就不會產生混淆，因為interface這個單詞代表了所能表示的所有交界處。而中文，我們有人機界面、接口、交互、分界面、接觸面等N種解釋

用J2EE的眼光看軟件開發，自然什么都要套到J2EE的模子里去
簡單的說，手里那個錘子，看什么都像釘子：）

我在上面所說的分層、分模塊開發的兩個項目，都是部分分層、部分分模塊的情況，如同我前面所說，是一個縱橫交錯的動態調整過程。
分層，也就是說的那個J2EE項目是在大原則是分層的情況下，實際開發中做了許多調整，項目做到最后，也不能說是分層還是分模塊了：），把一個人硬按在一個位置上，他是不會產生高效的
而另外一個，則是一個銀行綜合業務處理系統。

@BlueDavy

似乎我說的太多了:)
因為我對這個問題真的感興趣
也多次與人交流，在實踐中，我發現無論哪種方法都會有問題

你說“軟件過程以及開發方式都是為了降低人的因素來實現項目的可控性。”
我認為這是不對的，從管理學角度來講，管理的目標是建立行為規范
而行為規范是用來規范人，而不是用來規范過程的

我發現技術人員總是認為以人為本是個討巧的話題
其實正相反，在團隊管理中，用人絕對是一個技術活
是要通過分析得出正確結論的。這需要理論、模型、計算以及權衡裁決
其實跟軟件設計是一回事，這也是為什么管理學到最后也是數學的原因
管理不是感覺、而是技術和數學

anyway，說回分層的話題
無論分層還是分模塊，你都會依賴你的團隊來完成
而無論分層還是分模塊，都會有不同的依賴模型
不知道我這么說是不是很掃大家的興^_^
但我還是那句話：從技術上來說，其重點在于，架構師和項目管理者對有影響力的各個方面的動態依賴的識別及協調能力。

ps.
恰巧，本人目前正在運行中的兩個項目
一個是分模塊開發，一個是分層開發的。

@guitarpoet

首先
以人為本!=團隊特色
任何團隊都會有特色，但不是任何團隊的開發過程都以人為本
所以，你說的顯然是個偽命題

另外，如果某一開發人員的離開對你的團隊和公司有如此打擊，只能是項目經理失職
同任務分解和任務分配的原理沒有任何關系

還有，你提到的例子中，混淆了模塊和模塊劃分的區別
我前面說過，模塊并不是任何任務劃分的一個約束，而只是為不同的人協同書寫相同的模塊提供的一種約束。
而模塊劃分，則既不是業務問題，也不是技術問題，它受到實現技術、任務和人員配置的三角關系的約束。
所以，在架構及開發任務分解這方面，沒有萬試萬靈的靈丹妙藥，最重要的是如何管理依賴，所有的依賴。所以，從技術上來說，其重點在于，架構師和項目管理者對有影響力的各個方面的動態依賴的認識及協調能力。

很高興又有人對這個問題感興趣了，說說我的看法
任務分解不應該以系統功能為主視角
而是考慮以人為本

任務分解，是一個面向人而不是面向任務的過程
這個問題實際上是對系統橫向切分和縱向切分的問題
很多項目管理方面的書要么對這個問題采用了一種偏致的做法
比如《PMP：Project Management Professional Study Guide》中采用縱向分解方法并羅列了很多好處
而有些書籍則再這個問題上搗漿糊，如WBS在這個問題上羅列出N種方案卻沒給出任何實際意見
且，很多人認為任務分解的終極目標為減少對交流的依賴

在這個問題上，我認為應該以團隊特色設計任務分解方式
而終極目標，則不是減少依賴，而是讓依賴可管理
即軟件結構設計影響任務分解，而任務分解影響組員間的依賴關系
反之，只有符合目前團隊的風格的任務分解才能高效運行，而該任務分解將影響架構師的架構抉擇。其實，這正是XP中團隊設計的根本原因。
這也是軟件項目管理上的一個重大特色，就是軟件結構設計同團隊結構設計的不可分割性。也是軟件開發難以實行工廠化的原因。

如果你在開始就積極的開展設計，并且把設計的過程持續下去，你的任務的劃分就會成為一個縱橫交錯的動態的調整的過程。而應該注意的師，模塊并不是任何任務劃分的一個約束，而只是為不同的人協同書寫相同的模塊提供的一種約束。

而如果以任務為視角，無論橫向分解還是縱向分解，都會在某種情況下陷入困境。
實際上，由于國內目前的軟件項目普遍不大，所以對于交流的有效性的感覺并不強烈
這問題在多個公司合作開發的過程中尤為突出

早上睡不著，四點就起床了，最近忙到顛，等有時間再好好休息一下吧，現在是不可能了....

Mule是EAIP一書的實現
而ServiceMix是基于JSR208的實現
從架構上來并沒有太大的區別，只是實現細節上有些不同而已
JBI也是人訂的，不會超越現有技術太大

即使經濟基礎牢固了，也未必會幸福，人的欲望是無限的
隨著你的經濟地位的提高，你會看到更多更有錢的人，所以，還是很難滿足
不如就從今天做起，每天不要那樣逼迫自己去努力

最后，如果你正在選型，希望你能支持國貨Cindy...^_^
MINA目前有三個開發人員，而Cindy似乎仍然是Crmky一個人開發，感覺也不是很活躍，如果有更多的人參與進去，我想Cindy也會越來越出色。

Cindy2.x比MINA性能好是可以預見的，原因在于MINA提供的ByteBuffer和FilterChain
Cindy3.x源代碼我沒有看，所以不好評價
關于MINA的效率問題，在MINA的maillist中也被提出，似乎有相應的issue正要被加入到它的Issue Tracker中

Cindy3.x才剛剛開始，我認為多給Crmky一些時間，他一定可以將架構設計的更好
MINA在設計上也有少許問題，他的IoFilterChain將FilterManager和FilterChain合而為一，在看其代碼的時候會覺得很亂。另外，為了保證包的順序，一個IoSession上的Handler在上一次read調用沒有返回前，是不會被再次調用的。我認為MINA的基礎架構在1.0和1.1版本之間還會變化，以適應新加入的configuration方式。另外，MINA會產生一些內存垃圾，我用profiler檢查過MINA，似乎是SocketIoProcessor中的某個計數器在不停的產生2byte的什么東東（記不太情了），不過似乎Trustin也注意到這個問題了，最近他說會在1.0release之后改善效率和內存的問題。

你可以到Crmky的blog上發帖子，看看他是否愿意提供一個Cindy3.X和MINA的對比

總體來說，java的通訊框架設計并不特別注重效率，而追求架構上的優雅，當然，這也和java中本來能夠進行效率調優的手段就不多有關系，如果真要優化，可能還是需要使用JDK5.0以上提供的高效的內存操作，另外，據說在Linxu2.6內核以后，Mustang的NIO使用了Linux的epoll來實現select()，也許會對目前的IO效率有所幫助。

http://m.tkk7.com/flyingbug/archive/2006/02/24/32350.html

哦...Thanks！

呵呵，你的工作量也不小啊

這里提到的大部分都是勤快人，如果沒更新blog，那肯定就是在忙工作了

但是要注意身體才好

關于架構師更像導演而不是建筑師的問題
可見《成功的軟件項目管理－銀彈方案》一書
愛爾蘭作者費格斯在其中做了精彩的闡述

"至于權威呢，那就厲害了，他一說話，不但你會認為他是對的，而且還會認為自己過去是錯的。反正，他一句能頂你一萬句就是了"

en...這句有意思

看上去像是在講Architecture Pattern
有什么不同嗎？

歡迎一起討論 ：）

恩，如果可能，一定加

呵呵，我個人感覺Message Queue并非什么神奇的技術，而且也不是普遍適用的技術
其實真正通用的整合標準就只有兩個：Http和Socket
SOAP是Http上的技術，Socket則是十年前的整合標準
無論使用哪一種都一樣

基于Socket的整合的中間件我都是自己寫的，所以我沒有用過MQ
只要通訊基礎框架寫的好，支持什么樣協議我想都不是大問題^_^

呵呵，沒用過MQ，所以沒辦法寫關于MQ的內容了
我想SOAP的好處是基于XML的標準提供了互通的平臺，并且它在消息轉換、元數據交換以及安全方面都提供了標準的做法，我認為SOAP是一個很有前途的集成手段
SOAP的缺陷是由Http協議的基于請求的、無狀態的特性決定的，這也沒辦法
但是可以通過一些設計模式來適當的改變這種狀態，比如使用Cache
或硬性的保持一個通知連接等機制

Mule在集成方面提供了實現了很好的模式
但是在底層通訊設施上過于簡單，很多問題沒有考慮
或者說依賴與底層通訊庫
比如message division、protocol support、Traffic throttle、unsequence