Java Web服务远端调用及发送SOAP请求的相关介绍与试用咨询

当年，微软带着.NET大力进入网络服务领域，SUN公司快速拿出Java WSDP工具包来应对，这场技术路线方面争斗产生了一个东西，那是Java Web服务远端调用，直到现在它依旧是企业级开发的基础，依靠一套严密的规范以及工具链，让各种不同语言、不同平台的系统通信变得跟调用本地方法那么轻松。

理解Web服务的核心机制

所谓Web服务，其本质乃是网络之上的程序接口。有一个商业客户，借助SOAP协议，将XML格式的请求发送至服务端，此服务端接收之后，便开始处理业务逻辑，随后又把结果进行打包，形成SOAP响应予以返回。这整个过程，并不关心客户端所使用的是何种操作系统，同样也不在乎服务端是以Java编写，亦或是用C#编写。正是这种松耦合的通信模式，使得不同企业间的系统集成成为了可行之事。

SOAP协议对消息封装结构以及编码规则予以了定义，当下JAX - RPC是基于SOAP1.1与HTTP1.1的，客户端发起的每一次调用都会被转变为契合规范的SOAP信封，借助HTTP协议传至指定URL，服务端收到之后进行解包、解析参数，接着执行实际的方法，响应消息同样以这样的格式返回，确保了交互的规范性。

描述与发现服务的标准

针对Web服务的自我描述文件是WSDL。它以XML格式将服务的名字、能够被调用的方法名称、每个方法的参数类型与返回值，还有服务的访问地址写明。当开发者拿到WSDL文件时，就相当于获取了调用服务的全部说明书。要是没有这个描述文件，远程调用就没办法进行，客户端不清楚该发送什么数据、应该发送到什么地方去。

黄页的角色由 UDDI 注册中心扮演，比方说一家有商品采购需求的商家，并非挨家挨户去询问供货商那里有此类采购供应，而是径直来到 UDDI 注册中心进行相关搜索，供货商会预先准备好把自身的 Web 服务诸多信息，诸如服务类型、联系方式、WSDL 地址等，注册到这个中心里面，客户借助 UDDI 找到合适的服务之后，还要依据 WSDL 去生成调用代码，最终达成交易。这样一种集中式的发现机制显著地降低了寻觅合作伙伴所需的成本。

JAX-RPC的工具链与开发流程

JAX - RPC里的关键工具为之xrpcc，它依据WSDL文件自主生成两类，其一为客户端的stub代理类，其二是服务端的tie代理类，stub担负着于客户端佯装成远程服务，致使开发者仿若于调用本地对象，tie则于服务端接纳请求，转而发送至实际的业务实现类，这般的自动代码生成规避了手动编写SOAP消息此项繁杂工作。

开发一项Web服务，仅需两个文件，其一为接口文件，用于声明哪些方法能够被远程调用，像假定的那样定义sayHello(String name)以及add(int a, int b)类似此类的方法，其中的String以及int是数据类型，name和a、b是变量名。其二是实现类，是真正去撰写业务逻辑代码的地方；需要明确编写业务逻辑代码的位置就在这里。定义好这两个文件之后，要对服务端容器进行配置，接着运用xrpcc去生成代理代码，如此一来，一个能够被远端调用的服务便宣告完成。

客户端调用与数据转换流程

客户端在调用远程服务之际，代码呈现出极为简洁的态势。其典型的写法是，先创建stub对象，接着设置服务端URI，随后如同调用普通Java方法那般，调用stub上的方法，就像hello.sayHello(“Duke”)这样。在这行代码的背后，JAX - RPC系统会将方法名以及参数值转化成SOAP消息，借助HTTP发送至服务器。开发者根本无需去操心XML拼接以及网络传输的细节。

服务器端处理流程是相反的那种情况。在收到SOAP消息之后，JAX - RPC系统是会把这个消息解析成方法调用的，之后会找到对应的tie对象，然后再去调用实际服务类里的方法。方法执行完的结果又会被包装成SOAP消息进行返回喽。整个这个过程总共涉及八步呢：从客户端调用stub方法开始算起，一直到最终拿到响应结果才结束，每一步都是由框架自动完成的哟。

平台无关性与协议支持

JAX-RPC最为突出的优势在于平台隔绝独立性，一个借助JAX-RPC达成的Java客户端，能够去调用部署于.NET平台之上的Web服务，反之亦是如此，这是源于底层通信全然是基于W3C的标准技术，即HTTP、SOAP以及WSDL，这些标准并不同任何编程语言或者操作系统相绑定，只要两端遵循同一组协议规范，便能够实现互通。

系统强大的扩展能力是由这种基于标准的架构所赋予的，企业能够把老旧系统逐步封装成Web服务并使之暴露出来，新开发的模块用JAX - RPC去调用这些服务，以此来实现渐进式替换，哪怕服务端从Windows更换为Linux，又或者从Java转变为Python，只要WSDL接口保持不变，客户端代码不用修改便能够继续运行。

实际运行的简化示例

服务端代码存有接口以及实现这两个部分，接口继承 Remote，定义像 public String sayHello(String s)这般的方法，实现类编写具体的返回逻辑，诸如 return “Hello ” + s，客户端代码借助 Service 构造 stub，设定服务地址，随后径直调用 hello.sayHello(“Duke”)，编译部署之后，运行 ant run 命令，控制台会输出服务端返回的结果。

这个简易的示范呈现出了远端调用的一整条完整路径，当客户端去启用stub的sayHello方法之际，JAX - RPC于背后产出SOAP消息，此消息涵盖方法名以及参数“Duke”，消息借由HTTP被传送到服务器，服务器在解析后从而执行实现类里面的sayHello方法，给出“Hello Duke”的回复，接着再度被打包成为SOAP响应而回传到客户端，整个进程对于调用者而言是透明的，达成了真切的分布式调用。

瞧见了这般诸多的技术细节后，你于实际的项目当中，是更偏向去运用传统的JAX - RPC，还是已然全面地转向了更为现代的JAX - WS？欢请在评论区域分享你作出选择的理由。