BlogJava-少年阿宾-随笔分类-AXIS2

Soap中RPC-style和Document-style

abin — Tue, 02 Apr 2013 07:26:00 GMT

主要是思维方式的不同：

显然，RPC是以方法调用的方式描述WebSerivce的，也就是说，你要说清楚调用的那个方法，以及各个参数的名称和值。要描述这些东东，SOAP消息就要有一个统一的规范，指出那一部分是方法名，哪个部分是参数，哪个部分是返回值。换句话说，RPC方式调用的SOAP消息格式是有章可循的，固定的。（比如说，每个Parameter必须对应一个Part，Part的name必须和参数名一致）。

而Document则是以文档传输的方式描述WebService，只要你的SoapBody里面是一个可以用Schema描述的合法的Xml文档就行了，对具体的格式没有什么要求（Schema要在WSDL里面写）。

可以看出，Document形式要更加灵活——尤其是需要传输特定格式的Xml文档的时候，而RPC的Soap消息实际上也可以用Document形式模拟（只要Schema定义得当）。所以目前Document方式应用更广泛一些（也是.NET里面的缺省方式）。

对Namespace，我觉得两者应该没有明显的区别。主要是RPC通常与Encoding模式结合使用，这就要引用Soap的namespace了；而Document只要引用XmlSchema的Namespace定义类型就成了。

abin 2013-04-02 15:26 发表评论

SOAP风格中 RPC与Document的区别

abin — Tue, 02 Apr 2013 07:02:00 GMT

尽管是转载的，但是原文中几处错误或者不规范的表达，我已经进行了修改。

大部分 Web 服务都是围绕着远程过程调用而构建的，而 WSDL 规范允许另外一种 Web 服务体系结构：文档样式（ document style ）。在该体系结构中，整个文档在服务客户端和服务器之间进行交换。在本文中， James McCarthy 将向您解释文档样式以及应该何时使用它。

在 Web 服务描述语言（ Web Service Definition Language ， WDSL ）规范中隐含着一个非常巧妙的转换开关，它可以将 Web 服务的 SOAP 绑定从远程过程调用转换成 pass-through 文档。在 SOAP 协议绑定中的样式属性可以包含这两个值中的一个： rpc 或 document 。当属性被设定为文档样式时，客户端知道应该使用 XML 模式而不是远程过程调用约定。本文将提供对这个 WSDL 转换开关的说明，描述它的好处，并将解释应该何时使用 pass-through 文档。

首先，让我们简要地谈谈 WSDL 的一些要点，来理解这个巧妙的转换是如何发生的。 WSDL 是一项 XML 规范，它被用来描述Web服务以及对于到达端点（服务）的协议相关的需求。 WSDL 用抽象术语来描述服务；通过可扩展的绑定定义，它能够为使用具体术语调用服务定义协议和数据格式规范。下面的语法是直接从 WSDL 规范中摘录出来的，展示了在绑定中所包含的可扩展性元素：

<-- extensibility element (1) --> *

<-- extensibility element (2) --> *

<-- extensibility element (3) -->

<-- extensibility element (4) --> *

<-- extensibility element (5) --> *

WSDL 规范通常描述三种绑定扩展： HTTP GET/POST 、 MIME 以及 SOAP version 1.1 。 HTTP GET/POST 和 MIME 中定义的绑定扩展用来定义与标准的 Web 应用程序进行通信的需

求，这些应用程序可能返回（也可能不返回） XML 文档。在发送或返回 XML 文档时， HTTP GET/POST 绑定的扩展是隐式的文档样式。

SOAP 绑定扩展用来定义支持 SOAP 信封协议的服务。 SOAP 信封是一种简单模式，它设计成能包含 XML 消息，提供特定于应用程序的消息头和消息体。 SOAP 绑定的扩展使 WSDL 文档能够声明 SOAP 消息的需求，这样应用程序就能够与服务正确通信。 SOAP 扩展允许将 SOAP 消息的样式声明为文档或 RPC 。如果在 soap:binding 元素中声明了样式属性，那么该样式将成为所有没有显式声明的样式属性的 soap:operation 元素的缺省值。如果在 soap:binding 元素中没有声明样式属性，那么缺省的样式就是文档。下面是文档样式的显式声明：

不管 soap:binding 元素中的声明如何， soap:operation 元素可以覆盖每个操作的声明，就像这样的：

在声明了文档样式的 SOAP 消息中，原始（ as-is ）或编码（ encoded ）的消息被直接放置在 SOAP 信封的体部。

如果样式声明为 RPC ，消息就封装在包装器元素中，同时带有从操作名属性中提取的的元素的名称以及从操作名称空间属性中提取的名称空间。

勿庸置疑，使用 XML 调用跨平台的远程过程调用的能力是非常有用的，它是使用 Web 服务的非常有说服力的理由。但是如果 Web 服务仅仅局限于 RPC 消息传递，这项技术的影响将是有限的。幸运的是，开发人员可以选择是使用 RPC 还是文档样式的消息传递，并且能够使用适合的技术来完成他们面临的任务。

XML 规范开发用来使通常锁定于专有格式的常规数据可以以一种人易读的、自描述的、自验证的开放格式来描述。当 Web 服务使用文档消息传递时，它可以利用 XML 的全部能力来描述和验证高级业务文档。当服务使用 RPC 消息格式化时， XML 描述方法以及为方法调用编码的参数，但是却不能用来执行高级业务规则。为了执行这些规则， RPC 消息必须包含 XML 文档作为字符串参数并且在被调用的方法中隐藏验证。出于这个原因， XML 的某些好处就丧失了，或者至少是被隐藏在后台应用程序里了。

使用文档消息传递的另外一个原因在于，远程过程调用必须是相对静态的，并且对接口的任何变化都将破坏服务和应用程序之间的契约。如果服务是广泛分布的，那么很可能大量的应用程序已经从它的 WSDL 文档中产生了存根代码。改变 WSDL 将会导致所有依赖于特定方法签名的应用程序被破坏，而且许多支持行产生问题。好的设计要求 RPC 消息服务的方法签名不应该改变。使用文档消息传递，规则更严格，并且可以使 XML 模式得到显著增强和改变，同时又不会破坏调用应用程序。

当业务使用基于 Web 的应用程序通过 Internet 交换信息时，应用程序应该能够使用有保证的交付机制来提高它的可靠性、可伸缩性和性能。为了达到这个目的，应用程序通常将使用异步消息队列。由于文档消息通常是自包含的，所以它更适合于异步处理，并且可以直接放到队列中。之所以说应用程序的可靠性得到了提高，是因为即使目标应用程序当前不是活动的，消息队列也可以保证消息的交付；之所以说性能得到了提高，是因为 Web 应用程序只是把文档发送到队列中，然后便可以自由地执行其他的任务；之所以说可扩展性得到了提高，是因为文档被下传到一个或多个应用程序的实例以进行处理。

业务文档的设计通常很好地适于面向对象的体系结构。结果，两个应用程序可以设计成通过使用 XML 交换对象的状态。与对象序列化相比，在对象交换中，交换的每个端点都可以自由地设计它认为合适的对象，只要交换符合达成协议的 XML 文件格式即可。不使用对象序列化的一个原因是为了支持对象在客户端和服务器端的实现。许多现有的特定于行业的 XML 模式被设计成客户端 / 服务器体系结构，在这种体系结构中，在客户端上完成的处理与预定在服务器上完成的处理是分离的。通常的情况是，客户端仅仅以服务器要求的特定文档格式请求或保存信息。当然，这种类型的交换也能用 RPC 消息完成，但是这种消息的编码方式限制了每个端点上的对象的设计。在文档样式中就不会出现这些限制问题。

什么时候应该使用文档样式呢？简单地说：只要没有连接到已存在的远程过程调用，任何时候都可以使用文档方式。使用文档方式比起通常花费额外的工作来连接服务，好处要大得多。不过需要提醒的是：一般来说，构建一个使用文档消息传递的服务的工作量要比构建一个 RPC 消息服务所需的工作量大。这些额外的工作通常包括 XML 模式的设计或对已存在的模式的支持、以及从文档中提取相关的信息。模式设计是重要的，因为 XML 解析器使用这个模式来验证文档，支持预定的业务规则。服务需要进行额外的工作来从文档中提取用于处理请求的相关信息。相比之下， RPC 消息只需要设计方法的接口，通过方法的接口， RPC 消息就可以自动地编组和解组参数。

当您决定发布一项服务时，您可能应该考虑下列问题。我将在下面的部分中分析您的答案的结果。

这项服务是连接到已存在的过程调用，并且这个过程调用是无状态的吗？
这项服务是仅在您的组织内部使用，还是也可以被外部用户所使用？
参数之一仅仅是 XML 文档规范吗？
这项服务需要请求 / 响应体系结构吗？
参数表示了可以从用于验证的 XML 文档模式受益的复杂结构吗？
所有需要进行交换的信息都能够合理地存放在内存中吗？

如果必须以特定的顺序调用多个过程来维护应用程序状态，您应该考虑在您的服务中使用文档体系结构。如果需要多个过程调用，那么过程就不是无状态的，并且服务必须维护应用程序状态。在 Web 服务中维护状态可能是困难的；在远程过程调用的情况下，很少有客户端平台会产生能够支持状态信息的存根代码。一个可能的解决方案是使用文档体系结构，并在文档内部传送整个事务的内容。在这种情况下，服务将执行调用，以确保服务内部保持正确的顺序，并且状态信息的维护不超出单个事务的范围。如果仍然需要状态信息，可以将状态信息记录在最终得到的文档中，客户端应用程序也可以维护一个用于服务识别它的状态的令牌。

如果一个应用程序被发布到组织以外，发布者就很难控制谁正依赖于这个服务，以及如果做出任何改动后果会怎样。在这种情况下，使用文档消息传递和支持像 ebXML 这样的通用交换协议可能更加有利。通用交换协议正发展成能改善外部交换的管理，因此新的贸易合作伙伴协定就可以快速地部署。同样，如果您的服务不需要请求 / 响应体系结构，那么通用交换协议就可以更好地设计来处理认证、可靠消息交付以及异步请求 / 响应。

如果您的服务正使用字符串参数来传递或返回 XML 文档，或者它的参数之一是一个具有复杂结构且需要自定义处理的对象，那么文档消息传递就可能是较好的选择。将参数的真实含义隐藏在字符串里经常会导致带有无效参数的有效调用。如果服务发布了 XML 文档模式，那么在调用服务之前根据这个模式进行验证就会更加容易。复杂结构经常用来传递组成完整事务的数百条信息。在处理复杂的结构时，远程过程服务可能不得不处理自定义的编组代码，同时应用程序仍然负责仔细地验证结构的每个元素。如果使用文档消息传递，那么应用程序程序员就可以使用 XML 模式来将验证下传到文档设计器，并且不需要自定义的编组代码。

择使用文档样式的消息传递还是 RPC 样式的消息传递时，需要考虑的最后一个因素是需要处理的信息量大小。由于采用 RPC 样式的消息传递来编组参数的大部分（如果不是全部的话）实现都是在内存中执行这项操作，所以内存约束可能会使得 RPC 消息传递行不通。许多文档消息传递服务能够选择是用 DOM 还是用 SAX 来处理文档，因而能够最小化内存中的处理。这对于 Web 服务尤为关键，因为它可能需要处理成千上万的请求，而且其中许多是同时发生的。

在您设计下一个 Web 服务时，您需要考虑当前的 WSDL 规范为您提供的所有选择。在开始创建过程性的接口之前，考虑好将如何使用服务，谁将使用它，以及需要交换的数据的类型和数量。设计开发文档样式的 Web 服务可能需要稍多一些的工作量，但是在很多情况下，这些额外的工作量将会换取更高的信息质量和更可靠的交换性能。

abin 2013-04-02 15:02 发表评论

axis2 客户端调用服务器端

abin — Sun, 20 Jan 2013 15:26:00 GMT

//方法一：
package com.abin.lir.axis2.client;

import org.apache.axiom.om.OMAbstractFactory;

import org.apache.axiom.om.OMElement;

import org.apache.axiom.om.OMFactory;

import org.apache.axiom.om.OMNamespace;

import org.apache.axis2.AxisFault;

import org.apache.axis2.addressing.EndpointReference;

import org.apache.axis2.client.Options;

import org.apache.axis2.client.ServiceClient;

public class UserClient {

public static void main(String[] args) {

try {

ServiceClient sc = new ServiceClient();

Options opts = new Options();

opts.setTo(new EndpointReference("http://localhost:9090/universal/services/play"));

opts.setAction("urn:echo");

opts.setTimeOutInMilliSeconds(10000);

sc.setOptions(opts);

OMElement res = sc.sendReceive(createPayLoad());

System.out.println(res);

} catch (AxisFault e) {

e.printStackTrace();

}

public static OMElement createPayLoad(){

OMFactory fac = OMAbstractFactory.getOMFactory();

OMNamespace omNs = fac.createOMNamespace("http://localhost:9090/universal/services/play", "nsl");

OMElement method = fac.createOMElement("getPassengerInfos",omNs);

OMElement value = fac.createOMElement("userID",omNs);

value.setText("1024");

method.addChild(value);

return method;

}

}

//方法二

package com.abin.lir.axis2.client;

import javax.xml.namespace.QName;

import org.apache.axis2.AxisFault;

import org.apache.axis2.addressing.EndpointReference;

import org.apache.axis2.client.Options;

import org.apache.axis2.rpc.client.RPCServiceClient;

public class RPCClient {

public static void main(String[] args) throws AxisFault {

// 使用RPC方式调用WebService

RPCServiceClient serviceClient = new RPCServiceClient();

Options options = serviceClient.getOptions();

// 指定调用WebService的URL

EndpointReference targetEPR = new EndpointReference(

"http://localhost:9090/universal/services/play");

options.setTo(targetEPR);

// 指定方法的参数值

Object[] requestParam = new Object[] {"1024"};

// 指定方法返回值的数据类型的Class对象

Class[] responseParam = new Class[] {String.class};

// 指定要调用的getGreeting方法及WSDL文件的命名空间

QName requestMethod = new QName("http://localhost:9090/universal/services/play", "getPassengerInfos");

// 调用方法并输出该方法的返回值

try {

System.out.println(serviceClient.invokeBlocking(requestMethod, requestParam, responseParam)[0]);

} catch (AxisFault e) {

e.printStackTrace();

}

//方法三

package com.abin.lir.axis2.client;

import org.apache.axiom.om.OMAbstractFactory;

import org.apache.axiom.om.OMElement;

import org.apache.axiom.om.OMFactory;

import org.apache.axiom.om.OMNamespace;

import org.apache.axis2.Constants;

import org.apache.axis2.addressing.EndpointReference;

import org.apache.axis2.client.Options;

import org.apache.axis2.client.ServiceClient;

public class AXIOMClient {

private static EndpointReference targetEPR = new EndpointReference(

"http://localhost:9090/universal/services/play");

public static OMElement getPassengerInfos(String symbol) {

OMFactory fac = OMAbstractFactory.getOMFactory();

OMNamespace omNs = fac.createOMNamespace(

"http://localhost:9090/universal/services/play",

"tns");

OMElement method = fac.createOMElement("getPassengerInfos", omNs);

OMElement value = fac.createOMElement("userID", omNs);

value.addChild(fac.createOMText(value, symbol));

method.addChild(value);

return method;

}

public static void main(String[] args) {

try {

OMElement getPassenger = getPassengerInfos("1024");

Options options = new Options();

options.setTo(targetEPR);

options.setTransportInProtocol(Constants.TRANSPORT_HTTP);

ServiceClient sender = new ServiceClient();

sender.setOptions(options);

OMElement result = sender.sendReceive(getPassenger);

String response = result.getFirstElement().getText();

System.err.println("Current passengers: " + response);

} catch (Exception e) {

e.printStackTrace();

}

abin 2013-01-20 23:26 发表评论

axis2 客户端

abin — Sun, 20 Jan 2013 15:23:00 GMT

http://blog.csdn.net/leo821031/article/details/1545974
http://zhangjunhd.blog.51cto.com/113473/25592/
http://hi.baidu.com/lennydou/item/b57032c0ceb6f5b00c0a7b08
http://www.cnblogs.com/markxue/archive/2012/09/01/2667123.html
http://www.blogjava.net/zhaozhenlin1224/archive/2010/02/03/311783.html
http://blog.csdn.net/yhhah/article/details/4158487

abin 2013-01-20 23:23 发表评论

Axis2生成客户端方式 Axis2提供的四种调用模式

abin — Sun, 20 Jan 2013 12:13:00 GMT

Axis2生成客户端方式

基于StockQuoteService类创建客户端的四种方式

构建基于AXIOM的客户端；

使用Axis2 Databinding Frame work(ADB)生成客户端；

使用XMLBeans生成客户端；

使用JiBX生成客户端。

ADB：最简单的生成Axis客户端的方法。大部分情况下，这些主要的类都会以内部类的形式创建在stub类中。It is not meant to be a full schema bindingapplication, and has difficulty with structures such as XML Schema element extensions and restrictions。 be meant to：有意要、打算
XMLBeans:与ADB不同，他是一个全功能的schema编译器。他没有ADB的限制。然而，他也比ADB用起来更复杂。他会产成大量的文件，编程模型不如ADB直观。
JiBX:他是一个数据绑定框架。他不仅提供了WSDL－JAVA的转换，而且提供了JAVA－XML的转换。JiBX相当灵活，允许你选择类来代表你的实体，但是这个却不好做，但还句话说，如果这些都能建好，那么使用JiBX就更使用ADB一样容易。

对于简单应用来说ADB已经够用了，如果想用更加强大更加灵活的功能，那么你可能需要使用其他两种方式。

Axis2提供的四种调用模式

Web services可以用来为用户提供广泛的功能，从简单的、少时间消耗的功能到多时间消耗的业务服务。当我们使用（调用客户端的应用程序）这些Web Service时，我们不能用简单的调用机制来针对那些对时间消耗有很大要求的服务操作。例如，如果我们使用一个简单的传输通道（如HTTP）并使用IN-OUT模式来调用一个需要很长时间来完成的Web Service，那么多数情况下，我们得到的结果将是"connection time outs"。另一方面，如果我们从一个简单的客户端应用程序调用一个同步的服务，使用"blocking"的客户端API将会降低客户端应用程序的性能。现在来分析一下一些常用的服务调用形式。

许多Web Service引擎提供给客户Blocking和Non-Blocking的客户端APIs。

1）Blocking API-一旦服务被启用，客户端的应用程序将被挂起，直到operation被执行完毕（表现为收到一个response或fault），才能重新获得控制权。这是调用Web Service最简单的方式，并且这种方式适用于多数业务情形。

2）Non-Blocking API-这是一个回叫或轮询机制的API。因此，一旦服务被起用，客户端应用程序马上得到控制权，通过使用一个callback对象来获得response。这种方式使得客户端应用程序可以很方便的同步启用多个Web Service。

这两种机制都是工作在API层面上的。称将通过使用Non-Blocking API而产生的异步行为方式为API Level 异步。这两种机制都使用单一的传输连接来发送request和接收response。它们的性能远远落后于使用两个传输连接来发送request和接收response（不管是单工还是双工）。所以这两种机制都不能解决需要长时间处理的事务的传输问题（在operation处理完成之前，很有可能你的连接已经超时了）。一种可能的解决方法是使用两个独立的传输连接来发送和接收request&response。这种异步行为，我们称为Transport Level 异步。

通过组合API Level异步和Transport Level 异步，我们可以得到四种调用模式。如下所示。

API (Blocking/Non-Blocking)	Dual Transports (Yes/No)	Description
Blocking	No	最简单和常用的调用模式
Non-Blocking	No	使用回叫或轮询机制
Blocking	Yes	在单工模式下，service operation为IN-OUT时，很有用。（如SMTP）
Non-Blocking	Yes	此模式下的异步效果最大

Axis2提供了所有上述4种调用Web Service的实现方式。

abin 2013-01-20 20:13 发表评论