在本章我会向大家介绍下jax-ws到底是个什么东西，另外也会用jax-ws做个简单的示例给大家看看。
[b]Java API for XML Web Services (JAX-WS)[/b]是Java程序设计语言一个用来创建Web服务的API。 JAX-WS是在[b]JAX-RPC 1.1[/b]的标准上实现的。JAX-RPC是 Java 方面的 Web 服务的原始标准。.[b]JAX-RPC 1.0[/b] 对 Web 服务功能的认识有一定的局限。从其名称可以看出，最初的目的是为了支持使用 XML 的[b]远程过程调用（Remote Procedure Call，RPC）[/b]操作。Java 当时已经有了一项面向 Java 应用程序间的 RPC 调用的现有技术，即[b]远程方法调用（Remote Method Invocation，RMI）[/b]。该规范团队选择了在现有 RMI 接口上对 JAX-RPC 进行建模。只要通过请求-响应操作使用 [b]rpc/enc SOAP[/b]，此模型就可相当接近地进行匹配，不过映射到异步操作或其他传输的效果并不理想。到 2003 年底，有关人员认识到，总要对 JAX-RPC 进行大幅修订，以处理这些问题和其他问题，因此 Sun 组成了一个专家组开始进行 JAX-RPC 2.0 规范的开发。
JAX-RPC 2.0 开发工作的主要目标是对各项标准进行更新，以支持 JAX-RPC 1.X 的强制要求（基于 Java 5 特性，如 Annotation 和泛型），改进消息传递支持（包括除 HTTP 外的异步操作和传输），并通过使用 JAXB 2.0 绑定替代 JAX-RPC 1.X 的简单（但局限性很强）内置绑定来改进模式支持。出于对更改范围的强调和其他原因，这个后续标准的名称更改成了 JAX-WS 2.0。
JDK5中提供的是jax-ws 2.0。JDK6中提供的jax-ws 2.1 ，现在jax-ws已经步入2.2版本，JDK7中即可支持。
[b]Java 中的webservice规范：[/b]
JAXM&SAAJ （比jax-ws暴露了更多底层的细节，例如可以更灵活的处理SOAP消息）
JAX-WS(JAX-RPC)
JAX-RS（针对[b]REST（表述性状态转移）式WebService [/b]所制定的规范）
[b]Jax-ws支持的数据类型[/b]
1：原始类型（任何Java支持的数据类型，如int）；
Java原始数据类型 XML 数据类型
boolean xsd:boolean
byte xsd:byte
short xsd:short
int xsd:int
long xsd:long
float xsd:float
double xsd:double
注意：这里的原始数据类型中没有char类型。
我们知道，在Java语言中，每个原始数据类型都有一个对应的Object类，如int和Integer对应，
但事实上如果它们表示同一个整数时对于XML来说是一样的，所以XML把它们统一对待。
2：标准java类
Java Class XML 数据类型
java.lang.String xsd:string
java.math.BigInteger xsd:integer
java.math.BigDecimal xsd:decimal
java.util.Calendar xsd:dateTime
java.util.Date xsd:dateTime
javax.xml.namespace.QName xsd:QName
java.net.URI xsd:anyURI
（注意：xml时间类型的数据转换成JAVA对象为javax.xml.datatype.XMLGregorianCalendar）
3：由支持的Java类型组成的数组（Array）
JAX-WS支持由JAX-WS支持的数据类型组成的数组。比如int[],String[]等。多维数组同样可以被支持，比如：int[][]，String[][]。
另外，byte[] 和 Byte[] 都映射为xsd:base64Binary 类型。
4:异常类
JAX-WS规定Web服务抛出的一样类必须直接或者间接从java.lang.Exception类继承，这个异常必须是可检查的异常（checked Exception），必须不能直接或者间接继承自java.lang. RuntimeException类。
异常和XML数据类型映射：
<complexType name="InvalidPointException">
<sequence>
<element name="message" type="string" nillable="true" />
</sequence>
</complexType>
可以看出，异常类实际上通过string类型来发送的，其实发送的string就是异常的
错误堆栈，在客户端获得XML形式的错误堆栈后，由可以通过这个错误堆栈重新构造一个新的异常类，它和服务端抛出的异常类是等价的。
5:JAX-WS值类型
JAX-WS值类型是能够在客户端和服务端点之间传递的Java类，它被映射为xsd:complexType。JAX-WS值类型必须遵守以下规则：
1：Java类必须提供默认的构造方法；
3：可以实现任何Java接口或者扩展自其它 类；
4：它可以包含公共的、私有的、受保护的字段，并且公共的字段必须是JAX-WS支持的数据类型；
5：Java类可以包含静态或者transient字段；
6：Java类可以包含一些方法；
7：Java类可能被设计成JavaBean。在这种情况下，JavaBean必须依照JavaBeans组件规则，为它的属性提供getter和setter方法；并且JavaBean的属性必须是JAX-WS支持的数据类型。
同时jax-ws还支持以下类型的序列化：
List（ArrayList、LinkedList、Stack、Vector）；
Map（HashMap、HashTable、Properties、TreeMap）；
Set（HashSet、TreeSet）。
[b]JAX-RPC 1.1为什么会被取代？[/b]
JAX-RPC会被舍弃主要是因为它采用的rpc/enc格式来就行SOAP的编码。SOAP 规范中由style与use这两个属性决定SOAP数据的编码样式。 style属性可是两个值中的一个： rpc 或 document 。当属性被设定为文档样式时，客户端使用 XML 模式调用约定；当属性设置成rpc，客户端使用远程过程调用约定。use属性值决定消息的编码方式：可以是encoded或者是 literal。encoded值表示使用Section 5编码（SOAP规范第五章定义的编码）进行xml的序列化和反序列化。Literal值表示根据具体的Schema将内存对象序列化成XML消息。
rpc/enc样式的缺点是耦合度高，跨平台的支持不是很好，另外rpc/enc样式下的SOAP协议栈除了单纯的XML处理之外，还要处理SOAP编码的逻辑，还原多引用的对象图。所以没有doc/lit简单快捷。
因为最近几年rpc/enc遭受了不少质疑和反对声浪。在WS-I 基本概要1.1（WS-I Basic Profile Version 1.1）中，已经禁止使用这种编码样式。WS-I 基本概要1.1要求使用 WSDL SOAP 绑定的 RPC/literal 或 Document/literal形式。WS-I 基本概要禁止对 soap:Envelope 或派生的 soap:Body 元素使用 soap:encodingStyle 属性。因此， RPC/literal 和 Document/literal 是 WS-I 标准唯一支持的 2 种格式。
(有兴趣的同学可以自己详细了解下rpc/enc与doc/lit的区别，在这我只是简单讲下)
[b]Document/literal wrapped[/b]
在标准Document/literal 方式下，程序员不得不处理所有的事务，包括基于 XML 的 SOAP 消息的序列化和逆序列化。标准的Document/literal不是面向RPC的，也没有定义与远程调用相关的信息，对仍然酷爱RPC调用的开发者来说无疑是欠缺的，在SOAP工具开发者看来Document/literal标准方式主要是缺乏函数的方法名。
于是微软提出了使用Document/literal模拟RPC的方法调用，定义了一种用特殊的Document/literal使用方法，有名称叫做Document/literal wrapped。其实就是故意在WSDL中定义一个复杂类型complexType节点，该节点的名称与远程调用的方法名相同，该节点把发送的所有参数再封装一层。这样，SOAP的开发工具可以在接受到XML消息的时候根据节点上的方法名将XML消息处理后分发到具体的处理函数中。
这种编码样式，兼顾了Document/literal和RPC的好处，具有更好的跨平台互操作性，目前许多类库都是采用这种方案，例如，大名鼎鼎的XFire。当然，这个方案肯定也有一些问题。
1、 这其实不是真正的RPC样式，方法名不能重载。
2、 WSDL文件比标准的Document/literal要复杂一些。
好了。。蹩脚的理论讲完了。现在做个简单的例子，我之所以选用jax-ws和XFire来做实例是因为myeclipse6.5及其以上版本都自带上面2个框架，非常容易创建项目。而且我觉得关于webservice的框架也不用学太多。因为webservice本身就是为了解决不同程序之间互相调用而产生。你完全可以不必理会你的服务器端或者客户端所用的webservice框架是否和你一样。能够熟练使用一种webservice框架进行webservice项目的开发就可以了。由于内容过长，所以讲示例放在第二小章。请大家谅解。
[b]Java API for XML Web Services (JAX-WS)[/b]是Java程序设计语言一个用来创建Web服务的API。 JAX-WS是在[b]JAX-RPC 1.1[/b]的标准上实现的。JAX-RPC是 Java 方面的 Web 服务的原始标准。.[b]JAX-RPC 1.0[/b] 对 Web 服务功能的认识有一定的局限。从其名称可以看出，最初的目的是为了支持使用 XML 的[b]远程过程调用（Remote Procedure Call，RPC）[/b]操作。Java 当时已经有了一项面向 Java 应用程序间的 RPC 调用的现有技术，即[b]远程方法调用（Remote Method Invocation，RMI）[/b]。该规范团队选择了在现有 RMI 接口上对 JAX-RPC 进行建模。只要通过请求-响应操作使用 [b]rpc/enc SOAP[/b]，此模型就可相当接近地进行匹配，不过映射到异步操作或其他传输的效果并不理想。到 2003 年底，有关人员认识到，总要对 JAX-RPC 进行大幅修订，以处理这些问题和其他问题，因此 Sun 组成了一个专家组开始进行 JAX-RPC 2.0 规范的开发。
JAX-RPC 2.0 开发工作的主要目标是对各项标准进行更新，以支持 JAX-RPC 1.X 的强制要求（基于 Java 5 特性，如 Annotation 和泛型），改进消息传递支持（包括除 HTTP 外的异步操作和传输），并通过使用 JAXB 2.0 绑定替代 JAX-RPC 1.X 的简单（但局限性很强）内置绑定来改进模式支持。出于对更改范围的强调和其他原因，这个后续标准的名称更改成了 JAX-WS 2.0。
JDK5中提供的是jax-ws 2.0。JDK6中提供的jax-ws 2.1 ，现在jax-ws已经步入2.2版本，JDK7中即可支持。
[b]Java 中的webservice规范：[/b]
JAXM&SAAJ （比jax-ws暴露了更多底层的细节，例如可以更灵活的处理SOAP消息）
JAX-WS(JAX-RPC)
JAX-RS（针对[b]REST（表述性状态转移）式WebService [/b]所制定的规范）
[b]Jax-ws支持的数据类型[/b]
1：原始类型（任何Java支持的数据类型，如int）；
Java原始数据类型 XML 数据类型
boolean xsd:boolean
byte xsd:byte
short xsd:short
int xsd:int
long xsd:long
float xsd:float
double xsd:double
注意：这里的原始数据类型中没有char类型。
我们知道，在Java语言中，每个原始数据类型都有一个对应的Object类，如int和Integer对应，
但事实上如果它们表示同一个整数时对于XML来说是一样的，所以XML把它们统一对待。
2：标准java类
Java Class XML 数据类型
java.lang.String xsd:string
java.math.BigInteger xsd:integer
java.math.BigDecimal xsd:decimal
java.util.Calendar xsd:dateTime
java.util.Date xsd:dateTime
javax.xml.namespace.QName xsd:QName
java.net.URI xsd:anyURI
（注意：xml时间类型的数据转换成JAVA对象为javax.xml.datatype.XMLGregorianCalendar）
3：由支持的Java类型组成的数组（Array）
JAX-WS支持由JAX-WS支持的数据类型组成的数组。比如int[],String[]等。多维数组同样可以被支持，比如：int[][]，String[][]。
另外，byte[] 和 Byte[] 都映射为xsd:base64Binary 类型。
4:异常类
JAX-WS规定Web服务抛出的一样类必须直接或者间接从java.lang.Exception类继承，这个异常必须是可检查的异常（checked Exception），必须不能直接或者间接继承自java.lang. RuntimeException类。
异常和XML数据类型映射：
<complexType name="InvalidPointException">
<sequence>
<element name="message" type="string" nillable="true" />
</sequence>
</complexType>
可以看出，异常类实际上通过string类型来发送的，其实发送的string就是异常的
错误堆栈，在客户端获得XML形式的错误堆栈后，由可以通过这个错误堆栈重新构造一个新的异常类，它和服务端抛出的异常类是等价的。
5:JAX-WS值类型
JAX-WS值类型是能够在客户端和服务端点之间传递的Java类，它被映射为xsd:complexType。JAX-WS值类型必须遵守以下规则：
1：Java类必须提供默认的构造方法；
3：可以实现任何Java接口或者扩展自其它 类；
4：它可以包含公共的、私有的、受保护的字段，并且公共的字段必须是JAX-WS支持的数据类型；
5：Java类可以包含静态或者transient字段；
6：Java类可以包含一些方法；
7：Java类可能被设计成JavaBean。在这种情况下，JavaBean必须依照JavaBeans组件规则，为它的属性提供getter和setter方法；并且JavaBean的属性必须是JAX-WS支持的数据类型。
同时jax-ws还支持以下类型的序列化：
List（ArrayList、LinkedList、Stack、Vector）；
Map（HashMap、HashTable、Properties、TreeMap）；
Set（HashSet、TreeSet）。
[b]JAX-RPC 1.1为什么会被取代？[/b]
JAX-RPC会被舍弃主要是因为它采用的rpc/enc格式来就行SOAP的编码。SOAP 规范中由style与use这两个属性决定SOAP数据的编码样式。 style属性可是两个值中的一个： rpc 或 document 。当属性被设定为文档样式时，客户端使用 XML 模式调用约定；当属性设置成rpc，客户端使用远程过程调用约定。use属性值决定消息的编码方式：可以是encoded或者是 literal。encoded值表示使用Section 5编码（SOAP规范第五章定义的编码）进行xml的序列化和反序列化。Literal值表示根据具体的Schema将内存对象序列化成XML消息。
rpc/enc样式的缺点是耦合度高，跨平台的支持不是很好，另外rpc/enc样式下的SOAP协议栈除了单纯的XML处理之外，还要处理SOAP编码的逻辑，还原多引用的对象图。所以没有doc/lit简单快捷。
因为最近几年rpc/enc遭受了不少质疑和反对声浪。在WS-I 基本概要1.1（WS-I Basic Profile Version 1.1）中，已经禁止使用这种编码样式。WS-I 基本概要1.1要求使用 WSDL SOAP 绑定的 RPC/literal 或 Document/literal形式。WS-I 基本概要禁止对 soap:Envelope 或派生的 soap:Body 元素使用 soap:encodingStyle 属性。因此， RPC/literal 和 Document/literal 是 WS-I 标准唯一支持的 2 种格式。
(有兴趣的同学可以自己详细了解下rpc/enc与doc/lit的区别，在这我只是简单讲下)
[b]Document/literal wrapped[/b]
在标准Document/literal 方式下，程序员不得不处理所有的事务，包括基于 XML 的 SOAP 消息的序列化和逆序列化。标准的Document/literal不是面向RPC的，也没有定义与远程调用相关的信息，对仍然酷爱RPC调用的开发者来说无疑是欠缺的，在SOAP工具开发者看来Document/literal标准方式主要是缺乏函数的方法名。
于是微软提出了使用Document/literal模拟RPC的方法调用，定义了一种用特殊的Document/literal使用方法，有名称叫做Document/literal wrapped。其实就是故意在WSDL中定义一个复杂类型complexType节点，该节点的名称与远程调用的方法名相同，该节点把发送的所有参数再封装一层。这样，SOAP的开发工具可以在接受到XML消息的时候根据节点上的方法名将XML消息处理后分发到具体的处理函数中。
这种编码样式，兼顾了Document/literal和RPC的好处，具有更好的跨平台互操作性，目前许多类库都是采用这种方案，例如，大名鼎鼎的XFire。当然，这个方案肯定也有一些问题。
1、 这其实不是真正的RPC样式，方法名不能重载。
2、 WSDL文件比标准的Document/literal要复杂一些。
好了。。蹩脚的理论讲完了。现在做个简单的例子，我之所以选用jax-ws和XFire来做实例是因为myeclipse6.5及其以上版本都自带上面2个框架，非常容易创建项目。而且我觉得关于webservice的框架也不用学太多。因为webservice本身就是为了解决不同程序之间互相调用而产生。你完全可以不必理会你的服务器端或者客户端所用的webservice框架是否和你一样。能够熟练使用一种webservice框架进行webservice项目的开发就可以了。由于内容过长，所以讲示例放在第二小章。请大家谅解。
扫一扫
4019
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
