渔人码头

写的很不错啊！非常感谢！

白衣，为什么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://www.blogjava.net/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