「webservice接口」Web service服务（接口）

webservice接口

Web service服务（接口）

一.定义

Web service是一个平台独立的，低耦合的，自包含的、基于可编程的web的应用程序，可使用开放的XML（标准通用标记语言下的一个子集）标准来描述、发布、发现、协调和配置这些应用程序，用于开发分布式的互操作的应用程序。

　WebService是一种能够使应用程序在不同的平台使用不同的编程语言进行通讯的技术规范，而这种技术规范的实现可以用不同的方法，比如使用基于XML形式的协议（SOAP）进行通讯或者是RESTFUL形式的。

二.webService分类(分为两种方式)：

<1.soap Webservice

1. soapwebService三要素

SOAP、WSDL(WebServicesDescriptionLanguage)、UDDI(UniversalDescriptionDiscoveryandIntegration)

soap用来描述传递信息的格式，

WSDL 用来描述如何访问具体的接口，

uddi用来管理，分发，查询webService 。

SOAP

SOAP即简单对象访问协议(Simple ObjectAccess Protocol)，它是用于交换XML（标准通用标记语言下的一个子集）编码信息的轻量级协议。它有三个主要方面：XML-envelope为描述信息内容和如何处理内容定义了框架，将程序对象编码成为XML对象的规则，执行远程过程调用(RPC)的约定。SOAP可以运行在任何其他传输协议上。例如，你可以使用 SMTP，即因特网电子邮件协议来传递SOAP消息，这可是很有诱惑力的。在传输层之间的头是不同的，但XML有效负载保持相同。

Web Service 希望实现不同的系统之间能够用“软件-软件对话”的方式相互调用，打破了软件应用、网站和各种设备之间的格格不入的状态，实现“基于Web无缝集成”的目标。

WSDL

Web Service描述语言WSDL　就是用机器能阅读的方式提供的一个正式描述文档而基于XML（标准通用标记语言下的一个子集）的语言，用于描述Web Service及其函数、参数和返回值。因为是基于XML的，所以WSDL既是机器可阅读的，又是人可阅读的。

UDDI

UDDI 的目的是为电子商务建立标准；UDDI是一套基于Web的、分布式的、为Web Service提供的、信息注册中心的实现标准规范，同时也包含一组使企业能将自身提供的Web Service注册，以使别的企业能够发现的访问协议的实现标准。

2. soapwebService三要素

几种流行Webservice框架性能对比（http://blog.csdn.net/thunder4393/article/details/5787121）

1 摘要

开发webservice应用程序中离不开框架的支持，当open-open网站列举的就有30多种，这对于开发者如何选择带来一定的疑惑。性能Webservice的关键要素，不同的框架性能上存在较大差异，而当前在官方网站、网络资料中可以方便的找到各自框架的介绍，但是很少有针对不同框架性能测试数据。本文选择了比较流行几个框架：Apache Axis1、Apache Axis2、Codehaus XFire、Apache CXF等，采用java作为测试用例，通过本机和远程两种进行测试方式，对这几种框架进行了性能测试，并对测试结果分析和性能比较，最后并对性能优异的框架进行了推荐。

关键词：Axis1、Axis2、XFire、CXF、Spring、SOAP、StAX、WSDL

2 框架介绍

2.1 Apache Axis1

Axis本质上就是一个SOAP引擎（Apache Axis isan implementation of the SOAP），提供创建服务器端、客户端和网关SOAP操作的基本框架。但Axis并不完全是一个SOAP引擎，它还包括：

l 是一个独立的SOAP服务器。

l 是一个嵌入Servlet引擎（例如Tomcat）的服务器。

l 支持WSDL。

l 提供转化WSDL为Java类的工具。

l 提供例子程序。

l 提供TCP/IP数据包监视工具。

2.2 Apache Axis2

Apache Axis2相比Apache Axis1更加有效、更加模块化、更加面向xml，支持容易插件模块扩展新功能和特性，例如安全和可靠。Apache Axis2是基于Apache AXIOM，它是一个高性能、pull-based XML对象模型。Apache Axis2的关键特性：

l 解析xml更快。采用自己的对象模型和StAX (Streaming API for XML)。

l 更低的内存占用。

l 支持热部署。新服务加入到系统，无需重启服务。

l 支持异步 webservice、

l MEP支持，灵活支持在WSDL 2.0定义的message Exchange Patterns(MEPs)

l 更加灵活。引擎给开发人员提供了充足的自由度可扩展客户头信息处理、系统管理、

l 更加稳定性。

l 传输框架不依赖于具体协议。为集成和传输协议（SMTP,FTP, message-oriented middleware, etc）有一个简单和抽象，引擎核心是完全独立于具体的传输协议。

l 支持WSDL。支持WSDL1.1、WSDL2.0。

l 方便集成其他组件（Add-ons）。几个web services已经被集成，包括：WSS4J for security(Apache Rampart),Sandesha forreliable messaging, Kandula whichis an encapsulation of WS-Coordination, WS-Atomictransaction andWS-BusinessActivity.

l 良好的扩展性。

2.3 Codehaus XFire

XFire核心是一个轻量的基于STAX消息处理模型，用来与SOAP消息交互，它支持不同类型的绑定机制、容器和传输协议。

支持webservice标准- SOAP, WSDL, WS-I Basic profile, WS-Addressing, WS-Security,etc.

l 高性能SOAP STACK

l 可插拔绑定POJOs, XMLBeans, JAXB 1.1, JAXB 2.0, and Castor support

l 通过Java1.5 和1.4(Commons attributes JSR181 syntax)使用JSR 181 API配置服务

l 支持多中传输协议- HTTP, JMS, XMPP, In-JVM, etc.

l 可嵌入的和直观的API

l 支持Spring, Pico, Plexus, and Loom

l 支持JBI

l 客户端和服务端stub代码生成

l 支持JAX-WS early access

2.4 Apache CXF

Apache CXF是一个开源服务框架。CXF可用前端编程APIs开发服务，比如：JAX-WS andJAX-RS，主要特性包括：

l 支持Web services标准。包括：SOAP、the WSI BasicProfile、WSDL、WS-Addressing、WS-Policy、WS-ReliableMessaging、WS-Security、WS-SecureConversation 和WS-SecurityPolicy.

l 支持不同类型前端开发模型。CXF实现了JAX-WS APIs，支持JAX-RS开发。

l 容易使用。CXF设计的简洁和直观，具有简洁APIs迅速的构建基于代码的服务，Maven插件使得工具集成更加容易、JAX-WS API支持、Spring 2.x XML使得配置更加容易。

l 支持二进制和遗留协议。CXF被设计为可插拔的架构，在不同的传输协议结合下，不仅支持XML，也支持非XML类型绑定，例如：JSON和CORBA。

<2.restful webservice

RESTful 简化了 web service 的设计，它不再需要 wsdl ，也不再需要 soap 协议，而是通过最简单的 http 协议传输数据 ( 包括 xml 或 json) 。既简化了设计，也减少了网络传输量（因为只传输代表数据的 xml 或 json ，没有额外的 xml 包装）。

RESTful 风格的 webservice 越来越流行了， sun 也推出了 RESTful WebService 的官方规范： JAX-RS ，全称：

Java API for RESTful WebService。该规范定义了一系列的注解

通常我们经常说的就是soap webService。

RESTful Webservice与soap Webservice区别

首先需要了解：REST是一种架构风格，其核心是面向资源；而webService底层soap协议，主要核心是面向活动；

相关概念：

SOAP

什么是SOAP，我想不用多说，Google一把满眼都是。其实SOAP最早是针对RPC的一种解决方案，简单对象访问协议，很轻量，同时作为应用协议可以基于多种传输协议来传递消息（Http,SMTP等）。但是随着SOAP作为WebService的广泛应用，不断地增加附加的内容，使得现在开发人员觉得SOAP很重，使用门槛很高。在SOAP后续的发展过程中，WS-*一系列协议的制定，增加了SOAP的成熟度，也给SOAP增加了负担。

REST

REST其实并不是什么协议也不是什么标准，而是将http协议的设计初衷作了诠释，在Http协议被广泛利用的今天，越来越多的是将其作为传输协议，而非原先设计者所考虑的应用协议。SOAP类型的WebService就是最好的例子，SOAP消息完全就是将Http协议作为消息承载，以至于对于Http协议中的各种参数（例如编码，错误码等）都置之不顾。其实，最轻量级的应用协议就是Http协议。Http协议所抽象的get,post,put,delete就好比数据库中最基本的增删改查，而互联网上的各种资源就好比数据库中的记录，对于各种资源的操作最后总是能抽象成为这四种基本操作，在定义了定位资源的规则以后，对于资源的操作通过标准的Http协议就可以实现，开发者也会受益于这种轻量级的协议。

REST专门针对网络应用设计和开发方式，以降低开发的复杂性，提高系统的可伸缩性。REST提出设计概念和准则为：

1. 网络上的所有事物都可以被抽象为资源(resource)

2. 每一个资源都有唯一的资源标识(resource identifier)，对资源的操作不会改变这些标识

3. 所有的操作都是无状态的

REST简化开发，其架构遵循CRUD原则，该原则告诉我们对于资源(包括网络资源)只需要四种行为：创建，获取，更新和删除就可以完成相关的操作和处理。我们可以通过统一资源标识符（Universal Resource Identifier，URI）来识别和定位资源，并且针对这些资源而执行的操作是通过 HTTP 规范定义的。其核心操作只有GET,PUT,POST,DELETE。由于REST强制所有的操作都必须是stateless的，这就没有上下文的约束，如果做分布式，集群都不需要考虑上下文和会话保持的问题。极大的提高系统的可伸缩性。

SOAP webService有严格的规范和标准，包括安全，事务等各个方面的内容，同时SOAP强调操作方法和操作对象的分离，有WSDL文件规范和XSD文件分别对其定义。

如果从这个意义上讲，是否使用REST就需要考虑资源本身的抽象和识别是否困难，如果本身就是简单的类似增删改查的业务操作，那么抽象资源就比较容易，而对于复杂的业务活动抽象资源并不是一个简单的事情。比如校验用户等级，转账，事务处理等，这些往往并不容易简单的抽象为资源。

其次如果有严格的规范和标准定义要求，而且前期规范标准需要指导多个业务系统集成和开发的时候，SOAP风格由于有清晰的规范标准定义是明显有优势的。我们可以在开始和实现之前就严格定义相关的接口方法和接口传输数据。（很多情况下是为了兼容以前项目且前台调用逻辑代码都不能动的前提下，更改底层应用，一般就需要使用webService模式开发，因为老代码中已经有了明确的方法定义以及参数类型、个数等申明）

简单数据操作，无事务处理，开发和调用简单这些是使用REST架构风格的优势。而对于较为复杂的面向活动的服务，如果我们还是使用REST，很多时候都是仍然是传统的面向活动的思想通过转换工具再转换得到REST服务，这种使用方式是没有意义的。

SOAP Webservice和RESTful Webservice

WebService是一种能够使应用程序在不同的平台使用不同的编程语言进行通讯的技术规范，而这种技术规范的实现可以用不同的方法，比如使用基于XML形式的协议（SOAP）进行通讯或者是RESTFUL形式的。

　　既然我们知道可以使用上面的两种形式进行通讯，那么我们就需要对上面的两种形式进行描述，规范化。而这些规范化的工作sun已经帮我们完成了，也就是JAX-WS,JAX-RS这两种规范.

JAX-WS是一种规范，而在jdk1.6之后就有了自带的实现，但是这种实现是比较简单的，基本上就只能够传递SOAP协议格式的消息。这就是为什么我们可以在没有axis2或者CXF的情况下开发WebService。这时候我们就会想了，如果我们需要其他的服务，比如我想让JAX-WS与Spring集成。这种需求前辈都已经考虑过了，也实现了，不需要我们在去实现这样的需求。而这种需求的解决方案在JAX-WS中是采用框架。而JAX-WS的框架就有AXIS2和CXF。框架使用起来可能会更加灵活，功能更加强大。比如CXF不仅仅实现JAX-WS，也实现了JAX-RS规范。

那么选择SOAP Webservice和Restful Webservice的使用，首先需要理解就是SOAP偏向于面向活动，有严格的规范和标准，包括安全，事务等各个方面的内容，同时SOAP强调操作方法和操作对象的分离，有WSDL文件规范和XSD文件分别对其定义。而REST强调面向资源，只要我们要操作的对象可以抽象为资源即可以使用REST架构风格。

Web service服务（接口）