从银行WebService报文接口系统中，学习敏捷设计

做了好几次webservice的接口，总觉得传输xml比传输序列化的对象来的方便，来的直接。
1.对于记录日志，xml更方便，更易读。
2.对于扩展性，xml更加灵活。
3.对于开发过程中的未知因素，显然xml更容易。
4.对于跨语言的需求，显而易见xml才容易实现。

SOAP本身就是传XML的，而且本身是有标准的。

在SOAP之上再传自定义的XML格式，就等于使用标准的XML封装了非标准的XML。既然这里用了非标准的自定义的XML格式，还有什么开放性可言？明明是你自己根本不理解SOAP是干啥的，还说别人不懂SOAP的好处，这简直就是个笑话。

另外，你这里强调很多很多老的系统以及行业，在应用层面不是使用http而是使用SOAP，我就更要笑话你啦。你说是http出现的早还是SOAP出现的早呢？http从出现到现在都已经20年了，从目前最流行的http1.1算起也有10多年的历史了，在这十多年里，http1.1经历了无数的考验，在其上构建的系统远多于在SOAP之上构建的系统。而SOAP从成为标准到现在还不足10年，最新的SOAP1.2标准距今才只有3年的历史，而且SOAP 1.0、1.1、1.2三个标准的兼容性相当差劲，你还指望使用老版本SOAP协议的系统能跟使用新版本SOAP协议的系统实现互通，这本身就是一个笑话，更何况还要在这个本来就不能很好互通的协议之上再跑一个自定义的非标准的XML，还说这叫开放性，这就是笑话之上的笑话了。http的互通性远比SOAP要好的多，反正都是要交换自定义XML的话，与其再穿上一层XML的外衣，让标准XML套上非标准XML，真的还不如在http上裸奔非标准XML好。

至于你说的为什么要用SOAP而不用RMI传对象，这个道理大家都知道，因为RMI仅限于Java，而SOAP却不是仅限于Java，这跟你说的是不是传对象没有任何关系。所以你这个例子根本证明不了你自己观点。而且要跨平台传输对象，在7年之前，确实SOAP可能是当时最好的选择，但现在来说SOAP已经不是唯一选择，也不是最好的选择了。向PHPRPC、Hprose等新型的高效的跨语言跨平台的远程对象调用的兴起，已经完全可以代替臃肿繁杂的SOAP。所以不管是新系统建设，还是老旧系统的维护，SOAP都没有任何适用的理由了。

1、格式清晰的纯文本比XML更易读。而对象转换为清晰格式的纯文本要比先解析XML到对象再转换为格式清晰的纯文本高效的多。
2、直接操作对象的扩展性比操作XML的扩展性要方便灵活的多。
3、对于开发过程中的未知因素，没有任何技术可以让你更容易，xml也不能。如果非要说xml能，那么其它其它技术可以比xml能做的更好。
4、对于跨语言的需求，xml是最麻烦的一种实现。目前很多跨语言跨平台的高效通讯协议，比如PHPRPC、Hprose都比XML来的容易，来的高效。

我请问lz，你喜欢哪个？

login(String userId,String password);

String xml ="<request><parameter name="userId">foo</parameter><parameter name="password">bar</parameter></request>";
login(String xml);

1.每个技术都要放在当时的历史环境看.从历史看ws的发展和http的发展根本就是两条线,所以站在现在去简单的批判ws,还拿现在的http来说事,根本就不是一个平等的对比.
2.单就ws来说,之所以那么多实践要在soap的xml内部再嵌套xml.恰恰说明了大家意识到,传输层越简单越好的道理.协议格式与我的业务数据是隔离的,我的业务数据就是一个xml片,至于你的协议是什么,是那个版本,采用什么方式传输都只是我的协议接口实现的问题.从认知的角度,接触到SOAP,觉得麻烦,然后再看到别人好的实践,然后学习到这种"挂羊头卖狗肉"的做法,这就是我的实际学习过程,我只是说出来而已.
3.站在现在看,SOAP还那么有必要么?确实没必要,如你所说,直接http+xml比他还省事,但这是第三个阶段,是一个理解的过程.如同你用惯了现代操作系统,反过头也没必要指责老的操作系统如何如何.
4.http的历史确实很长,但是像现在这样功能越来越强大,涉及领域越来越多从我个人感觉看却只是这几年了功夫,倘若http 10年前就像现在这般无所不能,SOAP也许根本不会出现.
5.SOAP臃肿繁杂并不代表传输简单值对象就不行,远程对象调用也未必真会成主流.如同html一样,传输层越简单越明了越好.这点恐怕很难改变,修改的只是我们使用的具体协议.至于业务的xml片,从未改变过.

1、你说的没错，技术是要放到当时的历史环境看的，所以我前面在比较http和SOAP时，是从20年前一直讲到现在的，并说明了在这个发展过程中http是如何成功以及SOAP是如何失败的。将一个成功的技术和一个失败的技术对比确实有些不公平。但这里讨论的不是公平不公平的问题，而是讨论该使用一个成功的技术还是该使用一个失败的技术的问题。

2、在很多错误的SOAP实践中采用XML套XML的方式的原因是，大家都知道SOAP是一个皇帝的新装，但是又因为SOAP的权威性以至于质疑它的人中没有几个人敢说出这个事实，因为直接说出我不能理解SOAP为什么要设计成这个样子，可能会被人说成是傻瓜。于是就采用了真正傻瓜才采用的方式那就是XML套XML，当然大部分采用这种XML套XML的人自己也知道这很愚蠢，但是又怕别人说自己愚蠢，于是把这种做法说成是好的实践，这样就可以误导更多的新人也采用这种傻瓜做法，当大家都成为傻瓜的时候，自己也就显得不那么傻瓜了。当有揭穿皇帝新装的小男孩说出事实的时候，这群傻瓜和生怕被人说成是傻瓜的装傻者就会站出来说，我们都清楚你说的是事实，但是你不应该说出来，你说出来对我们是不公平的，我们早就意识到了这个问题，我们只是不说而已。

3、以前的错误认知和错误实践都已经是过去了，我们确实没有必要跟过去的事情做太多的计较，但既然大家都已经认识到直接使用RPC方式，或者使用http+xml要比用SOAP套XML方便省事，还不让说出来，还不让大家从错误的实践中纠正过来，还说指责以前的错误实践是没有必要的事如何如何，这样就有点死要面子活受罪的意思了。

4、http在10年前跟现在并没有任何改变，之所以人们认为它越来越强大，涉及到的领域越来越多，并不是http本身的改变造成的，而是使用它的人的思维在改变，在它之上构建的其它技术在发展，SOAP只是这众多技术中出现的较早的一种而已，而且它基本上已经被事实宣布是失败的啦。我们要以发展的眼光看待事物，既然现在有更新更好的可以取代SOAP的技术，我们就没有必要抱着这样一个失败的技术等死，更何况是以错误的用法来使用一个失败的技术。

5、没有人说SOAP不能传递简单的值对象，但是就算是传递简单值对象，它也是最差劲的一种。远程调用技术强调的就是简单明了，不但让你从如何传输数据上（TCP、HTTP已经做到了）解放出来，而且让你从如何进行数据表示上解放出来。使用远程调用技术（也许有的远程调用技术做不到，但是在我知道的远程调用技术中Hprose可以做到）以后你的本地程序业务接口跟远程程序业务接口完全一致，程序员不需要维护多套接口，更不需要单独造什么XML片，这样才能真正从不同方式编写的接口维护中将程序员解放出来。到时候已有的XML片也可以完全废弃，当然如果还有傻瓜继续杞人忧天的继续用这些XML片也可以，只不过这是跟用SOAP套XML一样的愚蠢做法，但即使采用这种愚蠢做法，也比采用SOAP套XML这种做法高效的多，甚至比用纯SOAP还要高效。

我喜欢

login(String userId,String password);

我想lz从内心里也是喜欢这个，但是为了面子，他可能会选择：

String xml ="<request><parameter name="userId">foo</parameter><parameter name="password">bar</parameter></request>";
login(String xml);

而且会为了显示自己有充分的理由，会在后面说出一些完全没有道理的道理来。

我们之前也有一个项目，基本实现如楼主所示，不过有几点不同
1.action有一个基类
2.service有一个基类。
3.dao有一个基类。


action基类用于定义全局map，log4j，等。service基类定义了需要查询的种类，如sql查询、无事务查询、有事务查询，springjdbc/hibernate查询等。而dao层接口只是定义了些service。

这样的话跟楼主思想差不多一样，不过还是学习了。呵呵。

1.下次叫别人LZ前,请先确定自己叫的对不对.

2.上面一个帖子,你说http很多年未变,恰恰是我更推崇传递简单值对象的原因.如果你觉得因为http协议基本没有大的改变就认为http多年没什么变化,那真是笑死人了.web前端技术,后端技术这些年变化有多大,地球人都知道.可是在这种剧烈的变动中,web开发依然能保持一个稳定的发展,不就因为协议上的简单稳定么?我只能说,看到你的回复,越发的让我坚定能不用远程对象调用就不用远程对象调用的决心.

3.至于什么xml套xml,你觉得丑陋,可我觉得有用就好了.我用已有soap的框架帮我建立连接传输数据,我觉得方便.但是我觉得他对数据定义方面的要求我不喜欢,所以我就按自己喜欢的方式来.这就叫实践.难道你用Struts的时候就是他定义的任何规范和组件都使用么?

4.至于什么死不承认,说说以前的经历就是死不承认,我好怕啊,这帽子盖的.我只不过看到有人说ws就说说自己的看法.你觉得ws不好,我也觉得现在ws现在不是最好选择,但是觉得没必要太过鄙视ws,ws设计成那个样子是有原因的.它的主要目的是在解决跨语言调用,有点取代更难用的cobra的意思.你说的什么兼容多种语言的轻量级远程调用框架,这样确实高效,可是你给一个语言一个语言去写实现,而且还会带来对项目的侵入和绑定.ws只不过换另外一个思路,定义个中立语言好了,我不负责兼容别人,别人来兼容我吧.我们这些xml套xml的人就更懒了,连中立语言都不想学,直接用基本什么语言都能识别的xml吧.这只是个思路的不同而已,我是实在看不出什么对错之分.... 再说了,我也不是没用过类似你说的,我们一个实效性要求很高的模块,就是采用google的Protocol Buffers,感觉也很好啊.是不是夸一个非要去贬低另外一个啊?

5.最后回答一下那个喜欢哪个的问题.我当然喜欢login(String userId,String password);了.但是很可惜的是,即便是传xml方式我也是这样调用的.难道真的有人在调用函数的时候拼xml?我是不信DI.协议解析层和业务层不会混成这样吧.

1、lz这两个字母我是接的hatedance的，请先看明白我回答的是谁，然后再插嘴，不要自作多情的把lz往自己身上套。

2、我说的就是http协议多年未变，我什么时候说过“web前端技术,后端技术这些年”没有变化了？你没看到我说的是“使用它的人的思维在改变，在它之上构建的其它技术在发展”吗？你是不是只看前言不看后语啊，难怪你理解事物总是那么片面，使用技术只取其形而未领其意呢，原来是你一直有这种只看前一半文字，而后一般文字完全靠自己杜撰的习惯啊。

3、你前面说坚持不用远程对象调用，可是这里你又坚持用soap套自定义XML，这就很有点自相矛盾了。soap设计出来就是用于实现远程调用的，你既然不用，你就直接用http+xml啊，弄个soap套xml不伦不类的，所以说你坚持的不是简单，而是坚持的滥用。我也不期望我的话能改变你的看法，我没那个本事，我只是希望你不要去用自己的错误实践去误导别人。至于你过去，现在还是将来怎么用，那都是你自己的事情。

4、你说的ws设计出来的“主要目的是在解决跨语言调用,有点取代更难用的cobra的意思”这句话一点都没错，这是ws设计的目的，可是最后的实现ws却把自己变成了一个跟cobra一样难用的东西。“ws只不过换另外一个思路,定义个中立语言好了,我不负责兼容别人,别人来兼容我吧”，你以为ws只要设计出来不用实现就可以用吗？这是不可能的。或者你认为上帝会帮你实现好？这是更不可能的！ws跟其它远程调用技术一样，都需要一个语言一个语言去写实现，每种ws实现也都会带来对项目的侵入和绑定，而且事实上目前ws的复杂程度已经让在各个语言上去实现的难度远远超过其它远程调用技术的实现，这也是为什么只有Java、.NET这些有大厂商后台的语言平台上有比较好用的ws实现（但也仅限于在自己的平台上好用，与其它平台和语言的互通性并不好，这是因为这些大厂商们在自己的实现中都加入了自己特有的东西，这样做是为了构建技术壁垒，所以即使有统一的协议，也不意味着就有统一实现），而其它一些脚本语言上只有一些功能不全互通性差的三流实现（这些三流实现不能良好互通就完全是因为没有足够的技术实力来实现定义如此复杂的ws造成的啦）。我想你根本就不了解ws与其它远程调用技术的本质，才会说出这样一套区别ws和其它远程调用技术的错误理论来。ws和soap是个失败的设计，这个结论不是我个人下的，在《Joel谈优秀软件开发方法》一书中，你会发现说出这个事实的恰恰是一些程序设计大师。另外，你说的Protocol Buffers并不是一种远程调用技术，Protocol Buffers本质上只是一个数据序列化方案，你可以认为他跟XML是一样的东西，都是用来表示数据的。它本身并不包含远程调用的定义，因此基于Protocol Buffers这种数据序列化表示方案的远程调用并不存在统一的定义和实现，不同的远程调用过程中因为走的调用协议不同，所以尽管采用相同的数据表示，仍然不能互通。

5、既然有 login(String userId,String password); 这样的统一接口，至于后面的数据表示采用什么是无所谓的。xml格式也好、Protocol Buffers格式也好、其它序列化格式也好都是一样的。只要采用相同的远程调用协议，就可以实现互通，完全没有必要自己绑死在XML上。另外，hatedance这个问题是问lz的，因为lz的例子里面就是后面那种在调用函数的时候拼xml的方式，所以，你不相信的事情就是lz干的。