关于基于XFire的webservice实现和调用的疑惑

是这样的:关于基于XFire的webservice实现和调用的问题:
客户端调用服务的代码如下：（伪码示意一下）

public serviceClient(){
  String inXml = "一个XML格式的字符串";
  //返回一个XML格式的字符串
  String outXml service.invokeServiceA(inXml);
  DTO dto = util.parseXmltDtoByDomej(outXml);
  ....................
  ....................
}

我的困惑如下：
我们现在虽然是以XML格式传递参数，但它是一个java.lang.String,并不是真正意义上的XML。我现在客户端也是Java自然可以接收识别。但如果服务消费端是Delphi等写的，那如何接受这个String~~~~   我怀疑我们是不是不应该传递String,而是应该传递一真正意义上的XML作为参数呢？ 如果传Stirng的话，那和HttpInvoker，RMI等的实现岂不一点优势都没有了～？

重点理解：
"一个XML格式的字符串"

基本知识：
网络也好，内存也罢，或是硬盘， 都只能处理二进制流。

真正意义上的XML，也要转成字符串，再变成二进制才能传送。
之所以是字符串，应为它是最兼容各种操作系统，编程语言和运行环境的。

还是不理解:
书上都说，WebService是以XML格式作为参数传递的，而RMI,Spring-HttpInvoker是通过Java对象(二进制)来传递参数的，避免了解析XML的性能损耗。所以WebService的优势在于异构系统之间的集成，因为他基于XML.所以具备平台无关性。但是我就想不通过，我们做的其实传的是一个Strong,并不是XML啊。只不过这个String被拼成了XML格式而已。如果Delphi来调这个WebService方法，他所得到的是一各Java数据类型的反参，而不是一个XML.困惑！如果是这样返回一个String的话，何必用WebService.RMI也可以做到啊，而且性能方面是WebService所不能及的。或许你会说,RMI不容易穿透防火墙，但一般我们的业务应用都是在专用网里，整个网络环境我们是可控的，想要什么端口都可以打开，以保证RMI方式的网络通讯顺畅。即便，你硬是说我们的服务有可能在互联网上应用，无法保证RMI实现的网络通信。那么我们也可以用Spring提供的HttpInvoker作为我们的远程访问实现方案,此种方案是基于HTTP通信的。
[PS:Spring的HttpInvoker机制是和Spring绑定的，也就是说服务端和客户端都要基于Spring的应用,注意是基于Spring不是基与Java.Spring有.Net版本，也就是说HttpInvoker也有一定程度上的异构系统集成能力。但如果说服务消费端有delphi、PB等的话，那就非WebService莫属了]

> 而RMI,Spring-HttpInvoker是通过Java对象(二进制)来传递参数的，避免了解析XML的性能损耗。

以现在的CPU而言，这点性能损耗是忽略不计的。
而且，传送Java对象，至少两边都要部署相同的对象吧，
结果就又成了信息孤岛。

相反的，开放与互联才是主流，WS和SOA的流行是有原因的。

并发低而且XML数据量小结构简单的情况下可以忽略解析过程的性能损耗。反之，则不得不考虑。系统性能的提升不能完全依赖于N个CPU或MG的内存。作为一个程序员更应该忽略硬件环境从应用本身下手进行调优。
对于信息孤岛的理解：WebService是可以完全解决楼上所谓信息孤岛的问题。但我对于信息孤岛的理解是是这样的。每一个商用系统都基于某一个行业应用，也就是说信息孤岛是相对的。只要能满足自身架构中各个
业务系统的资源共享就可以不算孤岛。我没没必要追求某项所谓的时髦技术，也没必要在应用中冠以几个自己都道不明白v其中奥妙的词汇就以为自己的这个架构很是牛B!

不知道你写的是什么例子。

没错，这个xml是String方式传递的，但是关键在这个xml上，如果这个xml是用wsdl描述过的，那么客户端就可以解析这个xml，获得web service（各种语言对应的）

所以问题不在传递是String还是Object

性能调优原则：大局着眼，关键处下手。
为了几个毫秒的延迟，放弃开放性是不可想象的。

真的是高并发高性能系统（比如网络游戏的数据同步），
当然不会用web service， 甚至你会用JAVA写网络部分么？


反之若是数据量很小，则是另一回事了。