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

我经常看到有人用了Web Service以后，输入输出参数还是XML的。
为什么啊？
这样还不如直接用http GET/POST好了，WS的好处根本没用到嘛。

lz  学习了，能再说的详细点就更好了

Visual Paradigm UML  :-)
http://www.visual-paradigm.com/product/vpuml/

你的想法是否可以理解为使用osgi实现呢？osgi也是实现运行时使用多个classloader加载。你的想法开始我也考虑了，但因需求关系最终没有考虑。
也可以不使用osgi，因为系统中使用了Spring容器，所以通过对BeanFactory的扩展，运行时也可动态加载新加入的请求报文类型。

你说对了，Web Service 本来就是皇帝的新装，只是没人愿意（敢）戳穿他罢了。你是个很勇敢的小男孩！我支持你！

系统就违反了开放-封闭原则 。。。 期望的是日后添加一种新报文后，只在系统中扩展新的请求、查询及响应对象来实现新需求

感觉需求是很简单，设计考虑降低程序的耦合度就可以，楼主说的有点复杂了

当然，用来做例子说明各个原则倒是可以。。。

顶下lz，偶最近也在做类似的，还没lz搞得更具体。。

1.接口是xml是为了最大限度的保证跨语言性.而不采用文本,又是因为xml的结构性和自解释特点.
2.历史看,http和Web Service也没什么联系.准确的来说,Web Service的祖宗们是为了解决C/S架构下的跨语言调用和通用RPC问题.比如技术,那才叫难使用呢.正因为此,再加上XML当时刚兴起,所以就结合XML出了SOAP.那个时候AJAX的原型-微软的Outlook Web Access才刚开始小范围使用而已,Web技术可还是蛮荒阶段呢,根本不会有人把这两个事情合起来想.
3.SOAP也不限于使用http协议.只是由于现在http协议非常强势,人们习惯性的将二者联系起来.

lz可能误解我的意思了。我的意思是既然用了web service，就应该尽量利用它的好处，比如参数序列化机制。
比如输入输出可以定义为可序列化的类。
如果参数还需要自己再解析，那么你不如直接用http的GET方式，比如GET http://server/foo?xml=abcdef
然后返回一段xml文本即可。
你现在的方案里需要自行序列化/反序列化输入输出参数，做起来应该会比较麻烦的，最好能避免。

这儿我给出一个轻量级的解决方案，可以免去你们的很多工作量。
修改你的doQuery方法签名，返回值为2维数组，我猜想你返回的是结果集。

String[][] doQuery(String queryType, String[] parameters); 

以什么方式传数据,是协议的问题.
数据传过来以后,以什么形式给使用者是应用层问题.
两个不在一个层次上的东西,为什么非要混在一起讨论呢?
所谓轻量级,不是说程序员越轻松就越轻量级.很多轻量级的方案,却对实现有着无比严格的要求和侵入.这样的东西,只轻了自己,一点也没在开放性上考虑.
传xml,你觉得序列化麻烦.那干嘛不用RMI?那还能直接操作远程对象呢.
SOAP的好处从来不是说让你可以在调用一个方法后happy的直接使用一个对象,那根本就不是SOAP所考虑的事情.
最后,虽然现在http很强势,但是还是有很多很多老的系统以及行业,在应用层面不是使用http交换数据,在那些领域SOAP仍然适用.