为 Web服务创建Java客户端2

　　协议类代理类，我们的例子中是RegisterPersonSoap，定义了精确反映Web服务操作的stub方法。通常，proxy方法被称为stub方法，因为它们实际上并没有做真正的方法应该做的事情，而是调用远程方法来完成真正的任务。由于示例Web服务定义了一个setPerson方法，所以SOAP类代理类也定义了一个setPerson stub方法。为了调用Web服务的setPerson方法，首先应该调用代理的setPerson stub方法。

　　记住这个看似简单的方法调用实际上为你做了不少事情。它将方法的所有参数编组，以组成一个适当地格式化过的SOAP消息(意味着它将参数从Java类型转换成XML类型)，再将这个消息发送给Web服务，然后等待SOAP响应消息，最后解分组响应消息中的数据并把这些数据作为Java类型返回给你。

　　对RegisterClient.java中setPerson的调用发生在第278行。

　　m_proxy.setPerson(p, startHeader);

　　这里，p是一个Person对象，startHeader是一个会话头部(本文后面会解释)。

　　客户端的Java类路径

　　RegisterClient.java示例中包含了一个可用来编译客户端的build.xml ant script，以及可分别在Windows和Linux/UNIX机器上执行客户端的run.bat和run.sh文件。可以检查这些文件来查看客户端使用的类路径。简单地说，类路径必须包括:

　　· 客户端类本身

　　· 使用clientgen创建的或者通过Java Proxy链接从WebLogic Workshop的测试视图中得到的客户端代理JAR文件

　　· 通用Web服务客户端支持JAR文件webserviceclient.jar，该文件可以在BEA WebLogic Platform 7.0安装文件下的WL_HOME/server/lib目录中找到，也可以通过Proxy Support Jar链接从WebLogic Workshop测试视图中获得。

　　在webserviceclient.jar中发现的支持类也可以在weblogic.jar中找到，但是类路径中包含的weblogic.jar在测试时容易混淆。你的客户端应该在那些能够访问目标Web服务主机的主机中工作，不管这些主机是否安装了WebLogic Platform。

　　这(几乎)就是全部事情了

　　这样说很有道理。Clientgen产生的客户端JAR文件以及底层的JAX-RPC基础使从Java代码中调用Web服务变得很容易。

　　"等一会儿"，你会说，"Person类是从哪里来的，会话头部又是什么"?不要着急，请继续往下看。

　　Web服务接口中的复杂Java类型

　　SOAP规范定义了如何将参数构建成一个方法，而WSDL规范则使用XML Schema类型定义了如何在XML中表示Java类型。当为Web服务生成一个WSDL文件时，Web服务操作期望的参数XML Schema被包含在WSDL文件中。当客户端支持代码被生成时，比如说是由clientgen生成的吧，这时clientgen工具就可以从WSDL文件中精确地判断出要在客户端语言中生成何种类型，以便通过客户端代码构建操作参数。至于JAX-RPC，Web服务接口中提到的所有类型都被生成了一个Java类。

　　在RegisterPerson.jws中，Web服务用到了两个Java类:Person和Contact。它们是在WSDL文件中描述的，并且clientgen为客户端JAR文件生成了具有代表性的类。

　　客户端JAR文件中的类和Web服务中的类是不一样的，知道这一点很重要。它们只不过是方便创建必需的数据结构以往Web服务的操作中传送数据的类而已。如果检查这些类，就会注意到它们除用来设置和获得类的数据成员所必需的accessor和mutator之外，不包含其他任何方法。它们不包含(也不能)Web服务使用的实际类的任何逻辑，因为代理类是从WSDL文件创建的，而该文件只包含类型和结构信息。

　　默认情况下，代理类是使用反映了Web服务(或者XML映像中相应的元素，当存在时)的XML命名空间的包分层生成的。RegisterPerson.jws使用WebLogic Workshop的默认命名空间http://www.openuri.org，所以代理类是在org.openuri.www包中生成的。

　　org.openuri.www.Person

　　org.openuri.www.Contact

　　对于那些使用document literal编码方式的Web服务来说，这些类被用来向proxy stub方法传送参数。想知道如何处理各种不同的SOAP编码方式，请继续往下读。

　　记住当你使用Java Proxy链接来从WebLogic Workshop的测试视图中获取Web服务的客户端JAR文件时，WebLogic Workshop按照默认设置为你调用了clientgen。如果你手工调用clientgen，可能还提供了自定义clientgen行为的参数。例如，你可以控制生成类的包层次。

SOAP document/literal与SOAP-RPC的比较

　　本文刚开始的时候，我就提到了SOAP规范中定义的两种消息编码样式:document literal和SOAP-RPC。WebLogic Workshop Web服务使用document literal作为默认的编码方式，但是在每Web服务(per-Web-service)或者每方法(per-method)基础中可以忽略这种规定。WebLogic Server (servicegen) Web服务只使用SOAP-RPC。

　　虽然不同的SOAP编码方式说明了用来调用Web服务操作的SOAP消息也必须以不同的方法格式化，但JAX-RPC隐藏了大部分的区别。作为Web服务客户端的开发者，你能看到的唯一区别在于由代理类生成的包。

　　在RegisterPerson.jws中，我囊括了setHomeContact和setWorkContact方法的document literal和SOAP-RPC两种版本。这些方法的SOAP-RPC版本被分别命名为setHomeContactRPC和setWorkContactRPC。

　　org.openuri.www.encodedTypes.Contact

　　用于document literal 和SOAP-RPC的proxy stub方法除了用于传递参数的代理类外是完全一样的。对于SOAP-RPC方法来说，代理类在包分层中生成了一层。在SOAP-RPC方法中只用到了Contact类，生成的代理类为:

　　org.openuri.www.encodedTypes.Contact

　　由于这个类表示的Web服务内部类和org.openuri.www.Contact表示的一样，它们具有同样的接口，所以必须严格地用相同的方法来使用它。RegisterClient.java中的示例在第343行。

　　m_proxy.setHomeContactRPC(soapRPCContactB, contHeader);

　　会话Web服务

　　在其他应用中，Web服务可能被用于展示一些业务操作，这些操作是那些可能是长时间的业务处理中的步骤。不同的操作可能需要不同的反应时间。有些操作甚至还需要人来查看数据并作出决策，这比起全自动的操作来慢多了。这种不可预测的发应时间要求Web服务必须能记录状态--当正在等待的慢操作完全结束时，Web服务要正确地记住它们的状态。不幸的是，Web服务默认的协议HTTP是一种无状态协议。Web服务器和浏览器通过cookie来逃避这个问题，但是Web服务体系结构并不能指望客户端可以管理cookie。

　　为了解决这个问题，WebLogic Workshop引入了会话式Web服务这个概念。Web服务的每个操作都被标识成一个会话的开始、继续和结束。无论会话处在哪个阶段，Web服务的状态(包括创建Web服务的人所需的数据)都是自动保持的。将Web服务操作标识为一个会话的某个参与阶段就像为一个操作设置属性一样简单。

　　每个会话都由一个独一无二的会话ID来标识。当Web服务客户端调用一个会话开始操作时，该客户端就负责生成一个惟一的会话ID，并且当客户端需要调用在同一个会话中执行的以后的Web服务操作时，客户端必须具有同样的会话ID。会话ID是一个字符串。在本例中的客户端，我使用了一种简单的策略来设计会话ID:先将当前的日期和时间表示成long型的值，然后转换成字符串。在RegisterClient.java中，会话头部在第264-266行被初始化:

　　java.util.Date now = new Date();

　　startHeader = new StartHeader((new Long(now.getTime())).toString(), null);

　　contHeader = new ContinueHeader((new Long(now.getTime())).toString());

　　注意到，继续头部与开始头部一样，都有相同的会话ID。因为我希望这个客户端的所有操作都在同一会话中发生。

　　如果Web服务操作被标识为会话开始操作(在JWS文件中)，则代理stub方法将接收一个StartHeader对象作为一个额外参数。如果Web服务操作被标识为会话继续或会话结束操作，那么stub方法将接收一个ContinueHerder对象作为一个额外参数。正如前面我们在本文中对复杂类型所作的描述那样，Java包层次(其中定义了这些头部类)起源于WSDL文件中的数据结构的XML命名空间。对于这些会话头部类，包层次(以及命名空间)还包括版本信息。开始头部的完整的Java类是这样的:

　　org.openuri.www.x2002.x04.soap.conversation.StartHeader

　　从中可以得出，在WSDL文件中，会话头部的XML命名空间如下:

　　http://www.openuri.org/2002/04/soap/conversation/

　　构造了会话头部对象后，就将其传给需要这个对象的代理stub方法。在RegisterClient.java中，每个代理stub方法都需要重复这一过程。在321行就有这样的例子:

　　m_proxy.setHomeContact(soapLiteralContactA, contHeader);

　　你可能会问:"为什么它们叫做'头部'呢?"这里之所以将它们作为头部来讲，是因为它们将作为另一部分SOAP消息的SOAP头部。另一方面，stub方法所带的参数将被传给SOAP的主体。

　　会话和用于管理来自客户端的会话的SOAP头部机制是一种仅仅WebLogic Workshop Web服务才有的概念。然而，所有的Web服务都会被要求能够参与长时间运行的、异步的业务处理。EBA Systems公司正在与工业组织和标准化组织一道，致力于会话这一概念的发展。

　　总结

　　在最底层，调用一个Web服务操作是件相当复杂的事情，涉及到网络连接管理和数据的编组和解编组，数据的编组和解编组又牵涉到广义Java-XML转换。但是，正如我在此所作的演示那样，有了JAX-RPC API以及WebLogic Server所提供的clientgen工具，为Web服务编写Java客户端不是什么难事。虽然我在这里举的例I正好是一个WebLogic Workshop Web服务，你也应该可以将这些概念应用于为任意Web服务创建Java客户端。