Edmund Smith是英格兰剑桥EMB公司的软件工程师，他最近与Steve Loughran(英格兰布里斯托尔市惠普实验室的科学家)合著了一个报告，叫做“重新思考Java SOAP堆栈”。在这个报告中，，作者讨论了基于XML的远程程序调用(RPC)中Java应用程序的编程界面(API)在根本上是有缺陷的(从前叫做JAX-RPC，而现在叫做JAX-WS)。而且，他们宣称，任何依赖于XML数据与本机语言目标之间完整的双途径映射SOAP API也存在缺陷。

　　作者提出了一种对于Jave可以选择的SOAP堆栈，即dubbed Alpine，这使得文档中心更加接近网络服务的发展。Alpine提供了使用现代的XML支持库技术来通向SOAP信息，而不是在XML和自定义Java类别之间进行规划。Alpine需要XML的理解，作者强调这需要健全的网络服务，并且提倡网络服务开发者应该掌握这种技术。

　　在网络服务发展方面，文档中心方法与PRC中心方法相比有什么优点和缺点?

　　Edmund Smith: 文档中心发展聚焦于信息的交换，特别强调对信息本身的理解和管理。当RPC中心的观点被应用于网络服务时，对信息的控制便由第三方来完成，包括促进开发者考虑调用的方法，并且在可能的情况下考虑作为远程对象的服务案例。

　　网络服务发展只是使用了注释的Java类别的发展，在促进开发者对这一点的思考方面，RPC中心方法并不能促进良好的服务架构，也不能促进容易维护的接口稳定性。熟悉的范式是一种诱饵，它吸引着开发者沿袭该路线，但是到了最后，发现熟悉其实是个错觉:网络服务本质上并不像目标例证那样可以经常置远程异常(RemoteExceptions)于不顾。

　　文档中心方法是否本来就不复杂?

　　Smith: 信息中心方法中越在前面的复杂性越高，但是在生产环境中参加工作的开发者将不再面对同样复杂性的问题。在RPC中心设计的最初阶段，其中会有很多附加的复杂性，因为有很多代码最初是隐藏在其中的。随后它们将面临着试图在更高的分离等级来控制这些信息的任务;在JAX-RPC 1.x中，不久之后你就会感觉这就像是戴着拳击手套做针线活，当然开始的时候你一定不会受伤，但是要想超越其他模式就变得相当困难。

　　是什么促成了这个报告?

　　Smith: Steve Loughran曾经是Apache的Axis计划的捐助者，而我则在开发建立于Axis之上的网格服务的测试框架方面上花费了一些时间。写这个报告的想法来源于我和Steve为网络服务API所做的一些工作，这个工作是为配置描述、部署与生命周期管理(CDDLM)而做的，CDDLM是全球网格论坛(GGF)的一个工作团队。在JAX-RPC内使用服务发展的标准方法我们失败了，这最终导致了这个报告开始撰写。

　　你认为迄今为止大家对这个报告的反应如何?

　　Smith:　我认为大家目前对报告的反应一直都很积极。不去考虑我是否同意或不同意一些在线的评论，我认为我们所引发的关于Jaba网络服务发展方向的讨论应该能给社会带来好处。很明显，在那些觉得网络服务应该尽可能畅通无阻的人和那些担心我们会失去使得网络服务属于首位的引人注目的协同工作能力和灵活性的人之间存在着紧张的关系。

　　Alpine能主动改变我们对于像SOAP这样的网络服务通信及标准的思考方式吗?能是为什么?不能又是为什么?

　　很明显，目前思考网络服务的方式不止一种，并确这些思考在近期不可能有什么变化。Alpine提出了很符合逻辑的关于一种思考方式的结论，关注于包含于通信本身的信息。如果Alpine是成功的，那么可能有更多的人将会通过这种以文档和消息为中心的发展模式所带来的好处中获得成功。

　　JAX-WS 2.0 (Java API for XML Web Services), 从前叫做JAX-RPC 2.0，据说它是更加以文档为中心的。你有何回答?

　　Smith: 当前关于JAX-WS标准的草案似乎增大了对于更大程度的文档中心用途的潜力;事实上，针对Alpine所提出的功能可能是来自于JAX-WS标准的适当子集。这看起来并不是说重点已经转移到文档中心的观点上，更多的是文档中心发展将不会再被破坏。

　　最后，JAX-WS仍然保留了把服务调用作为调用方法的范式，并自动产生服务接口，这使得JAX-RPC存在了缺陷。当然它不再必须使用这种功能，但这样做与让它变得更安全一些是两码事。

　　当你七月份把这份报告提交给IEEE之后会发生什么?

　　Smith: 我们早就开始着手Alpine的设计工作，而且我们期待在不远的将来这种努力还能够继续下去。把报告提交给国际网络服务大会(ICWS)将会有机会讨论网络服务堆栈应该前进的方向。我们目前还没有关于Alpine发展的任何时间表。