fisher

寫的很不錯(cuò)啊！非常感謝！

白衣，為什么www.springside.org.cn 訪問不了啊？ 持續(xù)有段時(shí)間了啊

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

GetMethod ?

這個(gè)東西哪來的?

同上，拿什么做圖示的？

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

最近我發(fā)現(xiàn)有個(gè)叫網(wǎng)絡(luò)爬蟲的開源組建那些，應(yīng)該會(huì)比我這個(gè)辦法好

如何輸出的流程文件

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

強(qiáng)！！！！！！

不錯(cuò)，期待作者能將它封裝一下。

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

@Samuel.Mo

在我當(dāng)時(shí)翻譯的時(shí)候，并沒有0.9以后版本的MINA
而Trustin Lee也在mina的doc中指出了0.9以后版本的架構(gòu)變化
我想是你關(guān)注的太少了

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

整合的apache

hehe，很高興我有了第一個(gè)留言者

好文！收藏了，謝謝！

very interesting

轉(zhuǎn)載一些代碼，使用HttpUrlConnection來模擬ie form登陸web：


關(guān)于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); // 需要向服務(wù)器寫數(shù)據(jù)
urlConn.setDoInput(true); //
urlConn.setUseCaches(false); // 獲得服務(wù)器最新的信息
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已經(jīng)很久了，由于工作的原因，目前具體開發(fā)技術(shù)上的事情關(guān)心比較少，恐怕也幫不到你什么

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

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

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

:)

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

charls == charlesxp??

恭喜恭喜^_^

歡迎討論^_^

@guitarpoet

^_^

@ guitarpoet

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

忙里偷閑上來看看^_^
接jerry的話，我也會(huì)來說說我的項(xiàng)目的情況

其實(shí)我覺得分層或分模塊的說法并不準(zhǔn)確
何謂分層？何謂分模塊呢？

咱們先繞開這個(gè)容易引發(fā)爭論的定義，來說說實(shí)際情況
在J2EE應(yīng)用中，似乎分層是很自然的想法
簡單的說，我們要分：表現(xiàn)層、邏輯層、持久層
然后分模塊，則是一個(gè)人負(fù)責(zé)一個(gè)功能模塊，貫穿所有層

現(xiàn)在，我們來跳出J2EE領(lǐng)域，看看軟件開發(fā)其他領(lǐng)域是什么樣的
比如，一個(gè)電信基礎(chǔ)業(yè)務(wù)系統(tǒng)開發(fā)
我們假設(shè)，包括語音平臺、帳務(wù)平臺、后臺主機(jī)系統(tǒng)、前端接入系統(tǒng)、計(jì)費(fèi)平臺、業(yè)務(wù)管理平臺等
在系統(tǒng)設(shè)計(jì)中，我們分為語音模塊開發(fā)、帳務(wù)系統(tǒng)模塊開發(fā)、主機(jī)通訊系統(tǒng)開發(fā)、前端接入系統(tǒng)開發(fā)、計(jì)費(fèi)及業(yè)務(wù)管理系統(tǒng)開發(fā)
那么這是分層還是分模塊呢？
顯然，一個(gè)人做一個(gè)業(yè)務(wù)的全套處理是不可能的（我很想結(jié)識能做到的xd），所以，這不會(huì)是分模塊開發(fā)。
如果說是分層，那么邏輯層在哪里？持久層在哪里？另外的問題是主機(jī)通訊系統(tǒng)將會(huì)貫穿始終，這應(yīng)該算哪一層？并且?guī)?wù)處理會(huì)使所有層的數(shù)據(jù)產(chǎn)生強(qiáng)烈耦合。

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

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

在這點(diǎn)上，似乎英文使用者就不會(huì)產(chǎn)生混淆，因?yàn)閕nterface這個(gè)單詞代表了所能表示的所有交界處。而中文，我們有人機(jī)界面、接口、交互、分界面、接觸面等N種解釋

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

我在上面所說的分層、分模塊開發(fā)的兩個(gè)項(xiàng)目，都是部分分層、部分分模塊的情況，如同我前面所說，是一個(gè)縱橫交錯(cuò)的動(dòng)態(tài)調(diào)整過程。
分層，也就是說的那個(gè)J2EE項(xiàng)目是在大原則是分層的情況下，實(shí)際開發(fā)中做了許多調(diào)整，項(xiàng)目做到最后，也不能說是分層還是分模塊了：），把一個(gè)人硬按在一個(gè)位置上，他是不會(huì)產(chǎn)生高效的
而另外一個(gè)，則是一個(gè)銀行綜合業(yè)務(wù)處理系統(tǒng)。

@BlueDavy

似乎我說的太多了:)
因?yàn)槲覍@個(gè)問題真的感興趣
也多次與人交流，在實(shí)踐中，我發(fā)現(xiàn)無論哪種方法都會(huì)有問題

你說“軟件過程以及開發(fā)方式都是為了降低人的因素來實(shí)現(xiàn)項(xiàng)目的可控性。”
我認(rèn)為這是不對的，從管理學(xué)角度來講，管理的目標(biāo)是建立行為規(guī)范
而行為規(guī)范是用來規(guī)范人，而不是用來規(guī)范過程的

我發(fā)現(xiàn)技術(shù)人員總是認(rèn)為以人為本是個(gè)討巧的話題
其實(shí)正相反，在團(tuán)隊(duì)管理中，用人絕對是一個(gè)技術(shù)活
是要通過分析得出正確結(jié)論的。這需要理論、模型、計(jì)算以及權(quán)衡裁決
其實(shí)跟軟件設(shè)計(jì)是一回事，這也是為什么管理學(xué)到最后也是數(shù)學(xué)的原因
管理不是感覺、而是技術(shù)和數(shù)學(xué)

anyway，說回分層的話題
無論分層還是分模塊，你都會(huì)依賴你的團(tuán)隊(duì)來完成
而無論分層還是分模塊，都會(huì)有不同的依賴模型
不知道我這么說是不是很掃大家的興^_^
但我還是那句話：從技術(shù)上來說，其重點(diǎn)在于，架構(gòu)師和項(xiàng)目管理者對有影響力的各個(gè)方面的動(dòng)態(tài)依賴的識別及協(xié)調(diào)能力。

ps.
恰巧，本人目前正在運(yùn)行中的兩個(gè)項(xiàng)目
一個(gè)是分模塊開發(fā)，一個(gè)是分層開發(fā)的。

@guitarpoet

首先
以人為本!=團(tuán)隊(duì)特色
任何團(tuán)隊(duì)都會(huì)有特色，但不是任何團(tuán)隊(duì)的開發(fā)過程都以人為本
所以，你說的顯然是個(gè)偽命題

另外，如果某一開發(fā)人員的離開對你的團(tuán)隊(duì)和公司有如此打擊，只能是項(xiàng)目經(jīng)理失職
同任務(wù)分解和任務(wù)分配的原理沒有任何關(guān)系

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

很高興又有人對這個(gè)問題感興趣了，說說我的看法
任務(wù)分解不應(yīng)該以系統(tǒng)功能為主視角
而是考慮以人為本

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

在這個(gè)問題上，我認(rèn)為應(yīng)該以團(tuán)隊(duì)特色設(shè)計(jì)任務(wù)分解方式
而終極目標(biāo)，則不是減少依賴，而是讓依賴可管理
即軟件結(jié)構(gòu)設(shè)計(jì)影響任務(wù)分解，而任務(wù)分解影響組員間的依賴關(guān)系
反之，只有符合目前團(tuán)隊(duì)的風(fēng)格的任務(wù)分解才能高效運(yùn)行，而該任務(wù)分解將影響架構(gòu)師的架構(gòu)抉擇。其實(shí)，這正是XP中團(tuán)隊(duì)設(shè)計(jì)的根本原因。
這也是軟件項(xiàng)目管理上的一個(gè)重大特色，就是軟件結(jié)構(gòu)設(shè)計(jì)同團(tuán)隊(duì)結(jié)構(gòu)設(shè)計(jì)的不可分割性。也是軟件開發(fā)難以實(shí)行工廠化的原因。

如果你在開始就積極的開展設(shè)計(jì)，并且把設(shè)計(jì)的過程持續(xù)下去，你的任務(wù)的劃分就會(huì)成為一個(gè)縱橫交錯(cuò)的動(dòng)態(tài)的調(diào)整的過程。而應(yīng)該注意的師，模塊并不是任何任務(wù)劃分的一個(gè)約束，而只是為不同的人協(xié)同書寫相同的模塊提供的一種約束。

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

早上睡不著，四點(diǎn)就起床了，最近忙到顛，等有時(shí)間再好好休息一下吧，現(xiàn)在是不可能了....

Mule是EAIP一書的實(shí)現(xiàn)
而ServiceMix是基于JSR208的實(shí)現(xiàn)
從架構(gòu)上來并沒有太大的區(qū)別，只是實(shí)現(xiàn)細(xì)節(jié)上有些不同而已
JBI也是人訂的，不會(huì)超越現(xiàn)有技術(shù)太大

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

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

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

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

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

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

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

哦...Thanks！

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

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

但是要注意身體才好

關(guān)于架構(gòu)師更像導(dǎo)演而不是建筑師的問題
可見《成功的軟件項(xiàng)目管理－銀彈方案》一書
愛爾蘭作者費(fèi)格斯在其中做了精彩的闡述

"至于權(quán)威呢，那就厲害了，他一說話，不但你會(huì)認(rèn)為他是對的，而且還會(huì)認(rèn)為自己過去是錯(cuò)的。反正，他一句能頂你一萬句就是了"

en...這句有意思

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

歡迎一起討論 ：）

恩，如果可能，一定加

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

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

呵呵，沒用過MQ，所以沒辦法寫關(guān)于MQ的內(nèi)容了
我想SOAP的好處是基于XML的標(biāo)準(zhǔn)提供了互通的平臺，并且它在消息轉(zhuǎn)換、元數(shù)據(jù)交換以及安全方面都提供了標(biāo)準(zhǔn)的做法，我認(rèn)為SOAP是一個(gè)很有前途的集成手段
SOAP的缺陷是由Http協(xié)議的基于請求的、無狀態(tài)的特性決定的，這也沒辦法
但是可以通過一些設(shè)計(jì)模式來適當(dāng)?shù)母淖冞@種狀態(tài)，比如使用Cache
或硬性的保持一個(gè)通知連接等機(jī)制

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