软件开发接口资料

接口技术福建富士通信息软件(ruǎnjiàn)有限公司FujianFujitsuCommunicationSoftwareCo.,Ltd.(FFCS)二〇一一年九月八日共七十六页主流(zhǔliú)接口技术123XML解析(jiěxī)技术Webservice介绍内容提要4Webservice框架共七十六页主流(zhǔliú)接口技术WEBServiceCorbaEJB消息(xiāoxi)队列FTPHTTPSocket中间表共七十六页WEBService基于HTTP传递xml定义的SOAP协议数据，是开放的标准，标准性高，扩展性好。优点:因为是基于HTTP协议，耦合度低，可以方便穿越防火墙，目前有大量成熟应用，接口开发有很多支持工具和环境，开发工作量较低。缺点:性能方面相对于中间件服务(fúwù)调用较低共七十六页Corba系统向外提供Corba服务，客户端直接调用。优点:跨平台、跨系统、跨语言，性能很高，比较稳定，扩展性良好。缺点:Corba产品不十分成熟、系统间耦合度增高，而且对于外部系统之间客户端开发接口以及调试(diàoshì)工作量相对大一些，适用于实时性要求比较高的场合接口共七十六页EJB系统向外提供服务供客户端直接调用。优点:性能很高，有成熟产品(chǎnpǐn)支持，可靠稳定，扩展性良好。缺点:系统间耦合度增高，而且对于外部系统之间客户端开发接口以及调试工作量相对大一些，十分适用于系统内部子系统之间的接口共七十六页中间(zhōngjiān)表这种方式是通过数据库中间表获取系统的数据，将相关的数据同步到其他系统。优点:接口实现简单，效率高，缺点:系统间耦合度较高，对双方(shuāngfāng)系统的稳定性以及接口的稳定性要求较高。共七十六页接口(jiēkǒu)分类接口调用方式同步：调用方在调用接口后必须在接口的结果返回后才可以继续执行自己的任务异步：调用方在调用接口后不需要等待接口的结果返回，可以继续执行自己的任务接口交互方式实时：接口的响应速度有很高要求，通常(tōngcháng)要求接口处理能在秒级完成非实时：调用者对接口执行速度要求不太高。接口数据量大数据量：指大量数据传输，通常是批量数据；小数据量：接口数据量偏小，一般小于100K的数据包接口频率非周期：接口不按固定周期交互，通常为事件触发，比如查询；周期：接口按固定周期，比如按日、按周、按月、按小时、按分钟或其他频率交互。共七十六页corba,ejb,webservice的区别(qūbié)Corba，EJB共同点：通过专有的网络协议通讯(tōngxùn)不能跨平台调用通过分布式对象调用来实现分布式架构,分布式架构是绑定在面向对象的机制上的分布式对象架构的缺陷在EJB2时代被充分暴露了出来webservices有一些明显不同于Corba和EJB分布式对象架构的特征：通过标准SOAP协议通讯，一般走HTTP通道能够跨平台调用通讯格式是xml文本，而不是二进制数据格式通过RPC（RemoteProcedureCallProtocol）机制来实现分布式调用，而不是通过面向对象机制实现分布式调用

RPC是一种通过网络从远程计算机程序上请求服务，而不需要了解底层网络技术的协议。共七十六页选择(xuǎnzé)接口技术同步(tóngbù)实时小数据量WEBSERVICE、CORBA异步非实时小数据量接口表、WEBSERVICE异步非实时大数据量接口表、FTP

共七十六页主流(zhǔliú)接口技术123XML解析(jiěxī)技术Webservice介绍内容提要4Webservice框架共七十六页XML解析(jiěxī)技术XML解析技术分析(fēnxī)

所有的XML处理都从解析开始，无论是使用XSLT或Java语言，第一步都是要读入XML文件，解码结构和检索信息等等，这就是解析，即把代表XML文档的一个无结构的字符序列转换为满足XML语法的结构化组件的过程。XML解析技术的分类面向文档的流式解析；面向文档的对象式解析；面向文档的指针式解析；面向应用的对象式解析；共七十六页面向文档的流式解析(jiěxī)技术流式解析是一种基于事件的解析过程，解析器顺序读取XML文档，产生一个对应的事件流，并向事件处理程序发送所捕获的各种事件，如元素开始和元素结束等，而事件处理程序则通过不同的方法处理这些事件。流式解析是将XML文档作为一个数据流来处理，因此，它具有类似于流媒体的优点，能够立即开始读取数据，而不是(bùshi)等待所有的数据被处理。而且，由于应用程序只是在读取数据时检查数据，不需要将整个文档一次加载到内存中，使得在处理大型文档时具有较好的时间和空间上的效率。然而效率的代价是易用性的降低，流式解析编程较为复杂，程序员需要负责更多的操作。并且由于应用程序没有以任何方式存储数据，所以使得更改数据或在数据流中往后移是不可能的。再加上它的单遍解析特性，意味着它也不支持随机访问。流式解析又分为两种解析方式：推式解析(SAX)和拉式解析(StAX)。这两种方式的主要区别在于是由解析器还是应用程序控制读循环(读入文件的循环)。拉式解析:在这种解析方式中，应用程序控制着读循环。循环中，应用程序负责反复调用解析器获得下一个事件，直到文档结束。推式解析:在这种解析方式中，解析器控制着读循环，在文档结束之前控制权不会返回给应用程序。解析器通过回调的方式进行数据处理。共七十六页java常用(chánɡyònɡ)的XML解析技术DOM(DocumentObjectModel)W3C里边一种成熟的标准。SAX(SimpleAPIforXML)一种被广泛接受的XML的API，成为事实上的标准。StAX(StreamingAPIforXML)在JSR-173中提到的一种很有前途的新型解析模型。按照解析方式可分为:基于(jīyú)树(tree-based),DOM基于事件(event-based),SAX,StAX共七十六页DOM解析(jiěxī)技术DOM解析是面向文档的对象式解析技术DOM解析器把XML文档转化为一个包含其内容的树，并可以对树进行遍历。DOM是用与平台和语言无关的方式表示XML文档的官方W3C标准。DOM是以层次结构组织的节点或信息片断的集合。这个层次结构允许开发人员在树中寻找特定信息。分析该结构通常需要加载整个文档和构造层次结构，然后才能做任何工作。由于它是基于信息层次的，因而DOM被认为是基于树或基于对象的。DOM以及广义的基于树的处理具有几个优点。首先，由于树在内存中是持久的，因此可以修改它以便应用程序能对数据(shùjù)和结构作出更改。它还可以在任何时候在树中上下导航，而不是像SAX那样是一次性的处理。DOM使用起来也要简单得多。DOM解析模型的优点是编程容易，开发人员只需要调用建树的指令，然后利用navigationAPIs访问所需的树节点来完成任务。可以很容易的添加和修改树中的元素。然而由于使用DOM解析器的时候需要处理整个XML文档，所以对性能和内存的要求比较高，尤其是遇到很大的XML文件的时候。由于它的遍历能力，DOM解析器常用于XML文档需要频繁的改变的服务中。共七十六页SAX解析(jiěxī)技术SAX采用了“推模式”（pushmodal）解析SAX解析器采用了基于事件的模型，它在解析XML文档的时候可以触发一系列的事件，当发现给定的tag的时候，它可以激活一个回调方法，告诉该方法制定的标签已经找到。SAX对内存的要求通常会比较低，因为它让开发人员自己来决定所要处理的tag.特别是当开发人员只需要处理文档中所包含的部分数据时，SAX这种扩展能力得到了更好的体现。但用SAX解析器的时候编码工作会比较困难，而且很难同时访问同一个文档中的多处不同数据。SAX处理的优点非常类似于流媒体的优点。分析能够立即开始，而不是等待所有的数据被处理。而且，由于应用程序只是在读取数据时检查数据，因此不需要将数据存储在内存中。这对于大型文档来说是个巨大的优点。事实上，应用程序甚至不必(bùbì)解析整个文档；它可以在某个条件得到满足时停止解析。一般来说，SAX还比它的替代者DOM快许多。共七十六页STAX解析(jiěxī)技术StAX是一种令人振奋的新型解析技术，和SAX一样(yīyàng)，它也采用了事件驱动模型。不过，在对于事件的处理上，SAX采用了“推模式”（pushmodal），而StAX则使用的是“拉模式”（pullmodel）。从这个原理来判断的话，StAX的实现显然要更加灵活，程序可以选择自己需要处理的部分，而SAX则一定会遍历整个文档。将StAX叫成“程序驱动模型”可能更利于理解一些。优点：接口简单，使用方便。采用流模型分析方式，有较好的性能。缺点：单向导航，不支持XPath，很难同时访问同一文档的不同部分。共七十六页技术有利局限适用于DOM1.易于上手

2.丰富的

API，易于访问

3.整棵树被载入内存，能随机访问节点

4读写1.整个文档必须一次解析完

2.载入文档树到内存代价昂贵

3.不利于实现对象类型绑定，需要给所有节点创建单独的类型需要修改xml或者用来处理XSLT（不要用在对XML只有读操作的程序中）SAX1.没有将整个文档读入内存，内存耗费较低

2.“

推模式

”

允许注册多种内容处理器

3只读1.没有内建的文档导航支持

2.不能随机访问

XML文档

3.不支持命名空间对XML只有读操作的程序（不要用来操作和修改XML文档）StAX1.有针对简单和性能的两种解析模式

2.由程序控制解析器，易于支持多输入（

easilysupportingmultipleinputs）

3.强大的过滤功能有利于数据检索

4读写

1.没有内建的文档导航支持

2.不能随机访问

XML文档需要对XML文档进行流处理而且支持命名空间的程序（不要用来操作和修改XML文档）共七十六页选择(xuǎnzé)解析技术为了比较这五种方式在解析XML文档时的性能表现，创建了三个不同大小的XML文档：（100KB）、（1MB）、（10MB）。分别用以上解析方式对这三个XML进行解析，然后打印出所有的用户信息，并分别计算它们所用的时间。测试代码会在文章后面的附件中给出，这里只比较它们的耗时。由上面的测试结果可以看出，性能表现最好的是SAX，其次是StAXStream和StAXEvent，DOM和DOM4J也有着不错的表现。性能最差的是JDOM。所以如果你的应用程序对性能的要求很高，SAX当然是首选。如果你需要(xūyào)访问和控制任意数据的功能，DOM是个很好的选择，而对Java开发人员来讲，DOM4J是更好的选择。如果只需要做XML文档解析的话，综合性能、易用性、面向对象特征等各方面来衡量，StAXEvent无疑是最好的选择。

单位：s（秒）

100KB

1MB

10MB

DOM

0.146s0.469s

5.876sSAX

0.110s0.328s

3.547sJDOM0.172s0.756s45.447sDOM4J

0.161s0.422s5.103sStAXStream

0.093s0.334s

3.553sStAXEvent

0.131s0.359s

3.641s共七十六页主流(zhǔliú)接口技术123XML解析(jiěxī)技术Webservice介绍内容提要4Webservice框架共七十六页WebService简介(jiǎnjiè)Webservice是描述一些操作（利用标准化的XML消息传递机制可以通过网络访问(fǎngwèn)这些操作）的接口。存在于互联网当中的组件，具有独立性，跨平台和技术，通过URL进行定位调用Webservice体系结构基于三种角色（服务提供者、服务注册中心和服务请求者）之间的交互。交互涉及发布、查找和绑定操作。共七十六页WebService的功能(gōngnéng)WebService是一种(yīzhǒnɡ)跨编程语言和跨操作系统平台的远程调用技术所谓远程调用，就是一台计算机a上的一个程序可以调用到另外一台计算机b上的一个对象的方法，譬如，银联提供给商场的pos刷卡系统（采用交互提问的方式来加深大家对此技术的理解）。远程调用技术有什么用呢？商场的POS机转账调用的转账方法的代码是在银行服务器上，还是在商场的pos机上呢？什么情况下可能用到远程调用技术呢？例如，amazon，天气预报系统，淘宝网，校内网，百度等把自己的系统服务以webservice服务的形式暴露出来，让第三方网站和程序可以调用这些服务功能，这样扩展了自己系统的市场占有率，往大的概念上吹，就是所谓的SOA应用。所谓跨编程语言和跨操作平台，就是说服务端程序采用java编写，客户端程序则可以采用其他编程语言编写，反之亦然！跨操作系统平台则是指服务端程序和客户端程序可以在不同的操作系统上运行。除了WebService外，常见的远程调用技术还有RMI（Remotemethodinvoke）和CORBA，由于WebService的跨平台和跨编程语言特点，因此比其他两种技术应用更为广泛，但性能略低。共七十六页WebService的调用(diàoyòng)原理WebService使用SOAP协议实现跨编程语言和跨操作系统平台WebService采用HTTP协议传输数据，采用XML格式封装数据（即XML中说明调用远程服务对象的哪个方法，传递的参数是什么，以及服务对象的返回结果是什么）。WebService通过HTTP协议发送请求和接收结果时，发送的请求内容和结果内容都采用XML格式封装，并增加了一些特定的HTTP消息头，以说明HTTP消息的内容格式，这些特定的HTTP消息头和XML内容格式就是SOAP协议(simpleobjectaccessprotocol,简单对象访问协议)。SOAP协议=HTTP协议+XML数据格式SOAP协议是基于HTTP协议的，两者的关系就好比高速公路是基于普通公路改造的，在一条公路上加上隔离栏后就成了高速公路。商店的服务员只要收到了钱就给客户提供货物，商店服务员不用关心客户是什么性质的人，客户也不用关心商店服务员是什么性质的人。同样，WebService客户端只要能使用HTTP协议把遵循某种格式的XML请求数据发送给WebService服务器，WebService服务器再通过HTTP协议返回遵循某种格式的XML结果数据就可以(kěyǐ)了，WebService客户端与服务器端不用关心对方使用的是什么编程语言。HTTP协议和XML是被广泛使用的通用技术，各种编程语言对HTTP协议和XML这两种技术都提供了很好的支持，WebService客户端与服务器端使用什么编程语言都可以完成SOAP的功能，所以，WebService很容易实现跨编程语言，跨编程语言自然也就跨了操作系统平台。共七十六页WebService框架的底层(dǐcénɡ)实现原理各类WebService框架的本质就是一个大大的Servlet，当远程调用客户端给它通过http协议发送过来soap格式的请求数据时，它分析这个(zhège)数据，就知道要调用哪个java类的哪个方法，于是去查找或创建这个对象，并调用其方法，再把方法返回的结果包装成soap格式的数据，通过http响应消息回给客户端。共七十六页WebService的工作(gōngzuò)过程UDDI注册(zhùcè)中心天气WebServiceWebService消费者1创建WebService,定义WSDL;

部署WebService,URI标识;股票WebService2把自己注册到UDDIviaSOAPWebService消费者3查找WebServiceviaSOAP4使用WebServiceviaSOAP（替代2和3）直接告知WSDL的URLWebService提供者共七十六页WebService的开发(kāifā)应用WebService开发可以分为服务器端开发和客户端开发两个方面：把公司内部系统的业务方法发布成WebService服务，供远程合作单位和个人调用。（借助一些WebService框架可以很轻松地把自己的业务对象发布成WebService服务，Java方面的典型WebService框架包括：axis，xfire，cxf等，javaee服务器通常也支持发布WebService服务，例如JBoss。这框架应用不是学习的重点，看看相关的技术手册都很轻松地掌握，关键还是要了解WebService的工作原理。）调用别人发布的WebService服务，大多数人从事的开发都属于这个(zhège)方面，例如，调用天气预报WebService服务。（使用厂商的WSDL2Java之类的工具生成静态调用的代理类代码；使用厂商提供的客户端编程API类；使用SUN公司早期标准的jax-rpc开发包；使用SUN公司最新标准的jax-ws开发包。）共七十六页WebService的客户端编程原理(yuánlǐ)我们给这各类WebService客户端API传递(chuándì)wsdl文件的url地址，这些API就会创建出底层的代理类，我调用这些代理，就可以访问到webservice服务。代理类把客户端的方法调用变成soap格式的请求数据再通过HTTP协议发出去，并把接收到的soap数据变成返回值返回。共七十六页WebService优缺点WebService优点Webservice的互操作性，平台无关性。Webservice的SOAP协议是基于XML和HTTP这些业界的标准的，得到了所有的重要公司的支持。由于使用了SOAP，数据是以ASCII文本的方式而非二进制传输，调试很方便； 并且由于这样，它的数据容易通过防火墙，不需要防火墙为了程序而单独开一个“漏洞”。WebService实现的技术难度要比CORBA和DCOM小得多。要实现B2B集成，EDI比较完善与比较复杂；而用WebService则可以低成本的实现，小公司也可以用上。在C/S的程序中，WebService可以实现网页无整体刷新的与服务器打交道并取数。

WebService缺点(quēdiǎn)

WebService使用了XML对数据封装，会造成大量的数据要在网络中传输。WebService规范没有规定任何与实现相关的细节，包括对象模型、编程语言，这一点，它不如CORBA。共七十六页

WEBSERVICE术语(shùyǔ)共七十六页XMLXML(eXtensibleMarkupLanguage)扩展标记语言XML是一种简单的数据存储语言，使用一系列简单的标记描述数据，而这些标记可以用方便(fāngbiàn)的方式建立。虽然XML占用的空间比二进制数据要占用更多的空间，但XML极其简单易于掌握和使用。共七十六页XSDXSD是XML结构定义(XMLSchemasDefinition)。XSD是DTD的替代品。描述了XML文档的结构。可以用一个指定的XSD来验证某个XML文档，以检查该XML文档是否符合其要求。文档设计者可以通过XSD指定一个XML文档所允许的结构和内容，并可据此检查一个XML文档是否是有效的。XSD本身是一个XML文档，它符合XML语法结构。可以用通用的XML解析器解析它。一个XSD会定义：文档中出现的元素、文档中出现的属性、子元素、子元素的数量、子元素的顺序、元素是否为空、元素和属性的数据类型、元素或属性的默认和固定值。XSD是DTD替代者的原因，一是据将来的条件可扩展，二是比DTD丰富和有用，三是用XML书写，四是支持数据类型，五是支持命名空间(kōngjiān)。XSD文件的后缀名为.xsd。共七十六页SOAPSOAP(SimpleObjectAccessProtocol)简单对象访问协议。SOAP是一种轻量的、简单的、基于XML的协议，它被设计成在Web上交换结构化的和固化的信息。SOAP可以和现存的许多因特网协议和格式结合使用，包括超文本传输协议(HTTP)，简单邮件传输协议(SMTP)，多用途网际邮件扩充协议(MIME)。它还支持从消息系统到远程过程调用(RPC)等大量的应用程序。SOAP包括三个部分：SOAP封装：它定义了一个框架,该框架描述了消息中的内容是什么(shénme)，谁应当处理它以及它是可选的还是必须的。SOAP编码规则：它定义了一种序列化的机制，用于交换应用程序所定义的数据类型的实例。SOAPRPC表示：它定义了用于表示远程过程调用和应答的协定。SOAP消息基本上是从发送端到接收端的单向传输，但它们常常结合起来执行类似于请求/应答的模式。所有的SOAP消息都使用XML编码。一条SOAP消息就是一个包含有一个必需的SOAP的封装包，一个可选的SOAP标头和一个必需的SOAP体块的XML文档。把SOAP绑定到HTTP提供了同时利用SOAP的样式和分散的灵活性的特点以及HTTP的丰富的特征库的优点。在HTTP上传送SOAP并不是说SOAP会覆盖现有的HTTP语义，而是HTTP上的SOAP语义会自然的映射到HTTP语义。在使用HTTP作为协议绑定的场合中，RPC请求映射到HTTP请求上，而RPC应答映射到HTTP应答。然而，在RPC上使用SOAP并不仅限于HTTP协议绑定。共七十六页WSDLWSDL（webservicedescriptionlanguage）是基于XML格式的，它是WebService客户端和服务器端都能理解的标准格式，其中描述的信息可以分为what,where,how等部分!好比我们去商店买东西，首先要知道商店里有什么东西可买，然后再来购买(gòumǎi)，商家的做法就是张贴广告海报。WebService客户端要调用一个WebService服务，首先要有知道这个服务的地址在哪，以及这个服务里有什么方法可以调用，所以，WebService务器端首先要通过一个WSDL文件来说明自己家里有啥服务可以对外调用，服务是什么（服务中有哪些方法，方法接受的参数是什么，返回值是什么），服务的网络地址用哪个url地址表示，服务通过什么方式来调用。WSDL文件保存在Web服务器上，通过一个url地址就可以访问到它。客户端要调用一个WebService服务之前，要知道该服务的WSDL文件的地址。WebService服务提供商可以通过两种方式来暴露它的WSDL文件地址：注册到UDDI服务器，以便被人查找直接告诉给客户端调用者，例如，在自己网站给出信息或邮件告诉。共七十六页UDDIUDDI（UniversalDescription,DiscoveryandIntegration）统一描述、发现和集成协议UDDI是为解决Web服务的发布和发现问题而制订的新一代基于Internet的电子商务技术标准。包含一组基于Web的、分布式的Web服务信息注册中心的实现标准，以及一组使企业(qǐyè)能将自己提供的Web服务注册到该中心的实现标准。共七十六页主流(zhǔliú)接口技术123XML解析(jiěxī)技术Webservice介绍内容提要4Webservice框架共七十六页

Apache-Axis2

(ApacheEXtensibleInteractionSystem)

Apache-Axis2共七十六页Axis2简介(jiǎnjiè)

ApacheAxis2是ApacheAxisSOAP项目的后继项目。此项目是Web服务核心引擎的重要改进，目标是成为Web服务和面向服务的体系结构（Service-OrientedArchitecture，SOA）的下一代平台。作为一个干净的可扩展的开放源代码Web服务平台，它正逐渐受到广泛的关注。Axis2的体系结构高度灵活，支持很多附加功能，如可靠消息传递和安全性等。Axis本质上就是一个SOAP引擎，提供创建服务器端、客户端和网关SOAP操作的基本框架。AXIS2支持更广泛的数据并对，如XMLBeans，JiBX，JaxMe和JaxBRI和它自定义的数据绑定ADB；Axis2支持多语言-除了Java,他还支持C/C++版本；Axis2允许自己作为独立的应用来发布WebService，并提供了大量的功能和一个很好的模型，这个模型可以通过它本身的架构（modulararchitecture）不断添加新的功能。Axis2将不会对Web服务概念进行验证，而将提供更好的SOAP处理模型，且与Axis1.x及其他现有Web服务引擎相比(xiānɡbǐ)，其速度和内容方面的性能都得到很大的提高。此外，它还为用户提供了方便的API，用于部署服务、扩展核心功能和新客户机编程模型。现在已经进入了Axis2的时代了。共七十六页Axis2体系结构Axis2具有模块化体系结构，由核心模块和非核心模块组成。据说，Axis2核心是纯SOAP处理引擎，并没有包含Java™APIforXML-basedRPC(JAX-RPC)概念作为其核心的一部分。Axis2体系结构的设计充分考虑了以下原则：逻辑和状态分离，以提供无状态处理机制，因为Web服务是无状态的。所有信息位于一个信息模型中，允许对系统进行挂起和恢复。能够在不更改核心体系结构的情况(qíngkuàng)下扩展功能，能以最小或没有核心更改的情况(qíngkuàng)下直接支持新Web服务规范。核心组件XML对象模型(AXIOM)SOAP处理模型：处理程序框架信息处理模型：上下文和描述其他组件部署模型传输客户机API核心生成模型Axis2体系结构关系(guānxì)图

共七十六页Axis2主要(zhǔyào)特性Axis2不仅是Apache的新Web服务框架。它还体现了从Axis1.x系列获得的经验和最近两年在Web服务领域(lǐnɡyù)的发展。推出Axis2的主要原因之一是从速度和内存方面获得更好的性能——不过还添加了一些新特性和功能。大部分新特性都是为了提高Axis2的易用性，并同时保留通过各种方式扩展功能的空间。大部分新功能所添加到的主要领域如下所示：新XML对象模型(AXIOM) AXIOM是一个XML对象模型，设计用于提高XML处理期间的内存使用率和性能，基于Pull解析。通过使用StreamingAPIforXML(StAX)Pull解析器，AXIOM（也称为OM）可以控制解析过程，以提供延迟构建支持。延迟构建是指AXIOM不完全构建对象模型，模型的其余部分基于用户的需求构建。基于消息传递的核心 Axis2是一个纯SOAP处理器，并不依赖于任何Java特定的规范。例如，JAX-WS将作为Axis2上的一个层实现，而不会进入核心部分中。共七十六页Axis2主要(zhǔyào)特性经过改进的部署模型 Axis2现在支持将服务热部署到Axis2引擎中。这就允许用户在不用重新启动服务器的情况下部署服务。服务应该存档为ZIP文件，且在文件名中使用.aar（Axis2存档，Axis2archive）作为扩展名。可插入模块体系结构 模块为服务器提供了一个扩展机制。Axis2中的每个模块都包含一组相关的处理程序。例如，WS-Addressing模块将包含一组为Axis2引擎提供WS-Addressing支持的处理程序。Axis2管理员可以下载WS-Addressing模块，并将其部署到Axis2引擎中，从而为Axis2引擎添加WS-Addressing支持。module.xml文件包含指定处理程序应属于哪个管道和阶段的规则。可插入数据绑定 在纯SOAP级别上工作有时候比较麻烦，因此大部分用户更喜欢使用Java代码，而让框架处理XML和Java代码间的转换。这称为数据绑定。有很多数据绑定框架可用，用户会因为各种不同的原因而偏好使用某个框架。Axis2支持目前(mùqián)可用的大部分数据绑定框架，而且没有任何限制。例如，Axis2内置了对XMLBeans、JAXB和JiBX的支持，用户可以选择使用其中任何一个。任何其他数据绑定框架都可以方便地插入。共七十六页Axis2主要(zhǔyào)特性新客户机API Axis2可以采用两种方式调用Web服务。ServiceClientAPI是最简单的方法，但为用户提供的控制较少。OperationClientAPI在调用期间提供了大量(dàliàng)的控制。这两个API都内置了基本In-Out和In-OnlyMEP。Axis2现在同时支持阻塞和非阻塞调用模型。非阻塞调用在设计用户界面时以及服务调用非常费时的情况下很有用。REST支持 随着Web2.0的推出，代表性状态传输（REpresentationalStateTransfer，REST）得到了认可。一段时间以来，REST阵营和SOAP阵营一直在就使用哪个规范进行激烈的争论。我们尝试在Axis2中同时支持二者，采用了WSDL2.0中将REST与Web服务结合的工作成果。在Axis2中，用户可以调用Axis2引擎中采用REST方式部署的所有Web服务，但受到WSDL2.0HTTPBindings规范中定义的约束的限制。共七十六页

sun

JAX-WS

sun

JAX-WS共七十六页概述(ɡàishù)

JAX-WS2.0(JSR224)是Sun新的webservices协议栈，是一个完全基于(jīyú)标准的实现。在binding层，使用的是theJavaArchitectureforXMLBinding(JAXB,JSR222)，在parsing层，使用的是theStreamingAPIforXML(StAX,JSR173)，同时它还完全支持schema规范。Sun最开始的webservices的实现是JAX-RPC1.1(JSR101)。这个实现是基于Java的RPC,并不完全支持schema规范，同时没有对Binding和Parsing定义标准的实现。JAX-WS规范是一组XMLwebservices的JAVAAPI。JAX-WS允许开发者可以选择RPC-oriented或者message-oriented来实现自己的webservices。在JAX-WS中，一个远程调用可以转换为一个基于XML的协议例如SOAP。在使用JAX-WS过程中，开发者不需要编写任何生成和处理SOAP消息的代码。JAX-WS的运行时实现会将这些API的调用转换成为对应的SOAP消息。在服务器端，用户只需要通过Java语言定义远程调用所需要实现的接口SEI

（serviceendpointinterface），并提供相关的实现，通过调用JAX-WS的服务发布接口就可以将其发布为WebService接口。在客户端，用户可以通过JAX-WS的API创建一个代理（用本地对象来替代远程的服务）来实现对于远程服务器端的调用。当然JAX-WS也提供了一组针对底层消息进行操作的API调用，你可以通过Dispatch直接使用SOAP消息或XML消息发送请求或者使用Provider处理SOAP或XML消息。通过webservice所提供的互操作环境，我们可以用JAX-WS轻松实现JAVA平台与其他编程环境（.net等）的互操作。

JAX-WS(JSR-224)是JavaArchitectureforXMLWebServices的缩写,简单说就是一种用Java和XML开发WebServices应用程序的框架,目前版本是2.0,它是JAX-RPC1.1的后续版本,J2EE1.4带的就是JAX-RPC1.1,而JavaEE5里面包括了JAX-WS2.0,但为了向后兼容,仍然支持JAX-RPC.现在,SUN又把JAX-WS直接放到了JavaSE6里面,由于JAX-WS会用到CommonAnnotation(JSR250),JavaWebServicesMetadata(JSR181),JAXB2(JSR222),StAX(JSR173),所以SUN也必须把后几个原属于JavaEE范畴的Components下放到JavaSE,现在我们可以清楚地理解了为什么Sun要把这些看似跟JavaSE没有关系的Components放进来,终极目的就是要在JavaSE里面支持WebServices.

共七十六页JAX-WS2.0的架构(jiàɡòu)JAX-WS不是一个孤立的框架,它依赖于众多其他的规范,本质上它由以下几部分组成用来开发WebServices的JavaAPI用来处理(chǔlǐ)Marshal/Unmarshal的XMLBinding机制,JAX-WS2.0用JAXB2来处理JavaObject与XML之间的映射,Marshalling就是把JavaObject映射到XML,Unmarshalling则是把XML映射到JavaObject.之所以要做JavaObject与XML的映射,是因为最终作为方法参数和返回值的JavaObject要通过网络传输协议(一般是SOAP)传送,这就要求必须对JavaObject做类似序列化和反序列化的工作,在SOAP中就是要用XML来表示Javaobject的内部状态众多元数据(Annotations)会被JAX-WS用来描述WebServices的相关类,包括CommonAnnotations,WebServicesMetadata,JAXB2的元数据和JAX-WS2.0规范自己的元数据.AnnotationProcessingTool(APT)是JAX-WS重要的组成部分,由于JAX-WS2.0规范用到很多元数据,所以需要APT来处理众多的Annotations.在<JDK_HOME>/bin下有两个命令wsgen和wsimport,就是用到APT和CompilerAPI来处理碰到的Annotations,wsgen可以为WebServicesProvider产生并编译必要的帮助类和相关支持文件,wsimport以WSDL作为输入为WebServiceConsumer产生并编译必要的帮助类和相关支持文件.JAX-WS还包括JAX-WSRuntime与应用服务器和工具之间的契约关系

共七十六页JAX-WS2.0特性(tèxìng)加固数据绑定以前，在theJAXB(JavaAPIforXMLBinding)和JAX-RPC(JavaAPIforXMLRemoteProcedureCalls)中都有数据绑定工具。这显然是混淆的，因此JAX-WS只选择了JAXB2.0.我以前对JAXB有更详细的文章。支持不断演化的标准尽管很多现在的Webservices选择了SOAP1.1标准作为协议、格式和Webservice消息的语法，但SOAP1.2标准已经出台了一段时间，而且应该会被越来越多的应用。JAX-WS将支持SOAP1.2，并且支持早期的SOAP1.1。由于SOAP1.2改变了一些SOAP消息的语法，所以这不是个小问题。当SOAP刚出现时，它被SimpleObjectAccessProtocol支持。但由于很多人觉得SOAP并不简单，而且对对象并没什么用，我们只称它为SOAP，而不附加什么含义。

类似的演化标准还有WSDL(WebServiceDescriptionLanguage),它被广泛用在各种Webservices中。WSDL文档是一个XML格式的文件，描述了与一个Webservice联系所需要的细节。当前在用的版本是1.1版，它并非是真正的W3C标准。尽管W3C最近批准了2.0版本，但JAX-WS最近还没有打算支持它。

另一个在演化的标准是WebServicesInteroperabilityOrganization。WS-IBasicProfile已经发展了，因为SOAP标准不足以良好定义来确保所有(suǒyǒu)的Webservice工具集都可以彼此交互。JAX-WS会顺应该领域的发展。

共七十六页JAX-WS2.0特性(tèxìng)利用Java语言的高级特性

Java能够为源代码提供某种形式的注释，即用javadoc工具处理一套以@开头的注释关键字，生成HTML格式的文档。这些文档注释不会在已编译的Java类中消失。

最新版本的Java5或Java1.5能够在你关注的文档处添加一种重要的新特性。这是一种可以被编译到类中并能在运行时访问的注释。你可以把这些注释想象成描述一个类如何被使用的元数据。例如，它如何被作为Webservice访问。

下面JAX-WS样例Java源文件AddNumbersIF.java中的是两个注释，它让一个Webservice返回(fǎnhuí)两个数的和。

@WebService(targetNamespace=“”,name=“AddNumbers”)

@WebMethod(operationName=“add”,action=“urn:addNumbers”)

由于这些注释生成在已编译的类中，因此处理已编译的Java类的JAX-WS工具能用Java反射机制获取程序员设计这些类的意图的额外信息。独立传输

由于我们正在探讨Webservice，人们就会忘记SOAP消息传输并没有被HTTP限制。已经有很多利用email或者JavaMessageService来传输的应用了。JAX-WSAPI文档指出，它想要改进在XML消息格式和低层传输机制之间的隔离，进而用非HTTP传输简化JAX-WS的使用。使用其它传输机制的样例看起来落后于HTTPWebservice样例的开发，但我已经在Glassfish项目中找到了使用JavaMessageService的一个例子。

共七十六页WebService框架(kuànɡjià)-

JAX-WSJAX-WS2.0是JAX-RPC1.1的后续版本JAX-WS的模型使用新的Java5.0功能，引入了异步功能。动态(dòngtài)编程模型JAX-WS的动态客户机模型与JAX-RPC的对应模型差别很大。很多更改都是为了认可行业需求：引入了面向消息的功能。引入了动态异步功能。JAX-WS还添加了动态服务器模型，而JAX-RPC则没有此模型。消息传输优化机制（MessageTransmissionOptimizationMechanism，MTOM）JAX-WS通过JAXB（JavaArchitectureforXMLBinding)

添加了对新附件规范MTOM的支持。Microsoft从来没有给SOAP添加附件规范；但似乎大家都支持MTOM，因此应该能够实现附件互操作性。共七十六页

codeHaus-XFire

codeHaus-XFire

共七十六页概述(ɡàishù)XFire是codeHaus组织提供的一个开源框架，它构建了POJO和SOA之间的桥梁，主要(zhǔyào)特性就是支持将POJO通过非常简单的方式发布成Web服务，这种处理方式不仅充分发挥了POJO的作用，简化了Java应用转化为Web服务的步骤和过程，也直接降低了SOA的实现难度，为企业转向SOA架构提供了一种简单可行的方式。XFire中另一块核心的思想，就是其灵活而强大的binding机制，负责完成Java类型与SOAP消息的双向转换。XFire仅仅内建就支持POJO(Aegis),Castor,JAXB1.1,JAXB2.0和XMLBeans多种模式，你可以根据需求选择从全自动POJO生成，到全手工xsd文件定义的不同方式。

共七十六页XFire架构(jiàɡòu)

Service层Service层是XFire架构的静态基础，负责完成对服务的注册及其管理。核心的ServiceRegistry接口完成对服务自身的生命期管理，如注册/注销/获取等等；而ServiceFactory接口则负责从具体的POJO类型(lèixíng)，生成实现

Service接口的可被管理的服务代理。Transport层Transport层则是XFire的外部IO处理系统。由TransportManager接口对具体的Transport接口实现进行管理，默认提供了基于pipe的LocalTransport和基于Http协议的SoapHttpTransport。理论上可以任意进行扩展，例如XFire发布包中还提供了基于JMS和XMPP的实现。Invoker层Invoker则是XFire的动态调用层，负责在Transport层接受到请求后，解析内容、调用合适服务并最终返回SOAP封包给调用者。运行时Invoker负责维系Service和Transport之间的联系。共七十六页主要(zhǔyào)特性支持将Web服务绑定到POJO、XMLBeans、JAXB1.1、JAXB2.0和Castor；支持基于(jīyú)HTTP、JMS、XMPP等多种协议访问Web服务；支持多种Web服务业界重要标准如SOAP、WSDL、Web服务寻址（WS-Addressing）、Web服务安全（WS-Security）等；支持JSR181，可以通过JDK5配置Web服务；高性能的SOAP实现；服务器端、客户端代码辅助生成；对Spring、Pico、Plexus等项目的支持等。

共七十六页主要(zhǔyào)特性

1、支持一系列WebService的新标准--JSR181、WSDL2.0、JAXB2、WS-Security等；

2、使用Stax解释XML,性能有了质的提高。XFire采用Woodstox作Stax实现；

3、容易(róngyì)上手，可以方便快速地从pojo发布服务；

4、Spring的结合；

5、灵活的Binding机制，包括默认的Aegis,xmlbeans,jaxb2,castor。

共七十六页

ApacheCXFApacheCXF共七十六页概述(ɡàishù)

CXF继承了Celtix和XFire两大开源项目的精华，提供了对JAX-WS全面的支持，并且提供了多种Binding、DataBinding、Transport以及各种Format的支持，并且可以根据实际项目的需要，采用(cǎiyòng)代码优先（CodeFirst）或者WSDL优先（WSDLFirst）来轻松地实现WebServices的发布和使用。ApacheCXF是一个开源的Services框架，CXF帮助您利用Frontend编程API来构建和开发Services，像JAX-WS。这些Services可以支持多种协议，比如：SOAP、XML/HTTP、RESTfulHTTP或者CORBA，并且可以在多种传输协议上运行，比如：HTTP、JMS或者JBI，CXF大大简化了Services的创建，同时它继承了XFire传统，一样可以天然地和Spring进行无缝集成。

共七十六页特性(tèxìng)

支持WebServices标准：CXF支持多种WebServices标准，包含SOAP、BasicProfile、WS-Addressing、WS-Policy、WS-ReliableMessaging和WS-Security。Frontends：

CXF支持多种“Frontend”编程模型，CXF实现了JAX-WSAPI（遵循JAX-WS2.0TCK版本(bǎnběn)），它也包含一个“simplefrontend”允许客户端和EndPoint的创建，而不需要Annotation注解。CXF既支持WSDL优先开发，也支持从Java的代码优先开发模式。容易使用：

CXF设计得更加直观与容易使用。有大量简单的API用来快速地构建代码优先的Services，各种Maven的插件也使集成更加容易，支持JAX-WSAPI，支持Spring2.0更加简化的XML配置方式，等等。支持二进制和遗留协议：

CXF的设计是一种可插拨的架构，既可以支持XML，也可以支持非XML的类型绑定，比如：JSON和CORBA。共七十六页特性(tèxìng)支持多种标准:

支持JAX-WS、JAX-WSA、JSR-181和SAAJ；

支持SOAP1.1、1.2、WS-IBasicProfile、WS-Security、WS-Addressing、WS-RM和WS-Policy；

支持WSDL1.1、2.0；支持MTOM；多种传输方式、Bindings、DataBindings和Format:

Bindings：SOAP、REST/HTTP；

DataBndings：目前支持JAXB2.0、Aegis两种，默认是JAXB2.0。XMLBeans、Castor和JiBX数据绑定方式将在CXF2.1版本中得到(dédào)支持；

格式（Format）：XML、JSON；

传输方式：HTTP、Servlet、JMS和Jabber；

可扩展的API允许为CXF增加其它的Bindings，以能够支持其它的消息格式，比如：CSV和固定记录长度。灵活部署

轻量级容器：可在Tomcat或基于Spring的容器中部署Services；

集成JBI：可以在如ServiceMix,OpenESBorPetals等等的JBI容器中将它部署为一个服务引擎；

集成SCA：可以部署在如Tuscany之类的SCA容器中；

集成J2EE：可以在J2EE应用服务器中部署Services，比如：Geronimo、JOnAS、JBoss、WebSphereApplicationServer和WebLogicApplicationServer，以及Jetty和Tomcat；独立的Java客户端／服务器。共七十六页特性(tèxìng)支持(zhīchí)多种编程语言

全面支持JAX-WS2.0客户端／服务器编程模型；

支持JAX-WS2.0synchronous、asynchronous和one-wayAPI‘s；

支持JAX-WS2.0DynamicInvocationInterface(DII)API；

支持wrappedandnon-wrapped风格；

支持XMLmessagingAPI；

支持JavaScript和ECMAScript4XML(E4X)，客户端与服务端均支持；通过Yoko支持CORBA；通过Tuscany支持SCA；通过ServiceMix支持JBI；代码生成

JavatoWSDL；

WSDLtoJava；

XSDtoWSDL；

WSDLtoXML；WSDLtoSOAP；

WSDLtoService；共七十六页WebService框架(kuànɡjià)-XFIRE(ApacheCXF)支持一系列WebService的新标准--JSR181、WSDL2.0、JAXB2、WS-Security等；使用Stax解释XML,性能有了质的提高。XFire采用Woodstox作Stax实现；开发方便(fāngbiàn)，配置简单，容易上手，与spring无缝集成，可以方便快速地从pojo发布服务支持Spring、Pico、Plexus、Loom等容器；灵活的Binding机制，包括默认的Aegis,xmlbeans,jaxb2,castor；高性能的SOAP栈设计；XFire比Axis1.3快2-6倍,响应时间是Axis1.3的1/2到1/5。共七十六页Axis2,CXF的比较(bǐjiào)ApacheCXF支持WS-Addressing、WS-Policy、WS-RM、WS-Security和WS-IBasicProfileAxis2支持WS-Addressing、WS-RM、WS-Security和WS-IBasicProfile，WS-Policy将在新版本里得到支持ApacheCXF是根据Spring哲学来进行编写的，即可以无缝地与Spring进行整合(zhěnɡhé)

Axis2支持更多的databindings，包括XMLBeans、JiBX、JaxMe和JaxBRI，以及它原生的databinding（ADB）。ApacheCXF目前仅支持JAXB和Aegis，并且默认是JAXB2.0，与XFire默认是支持Aegis不同，XMLBeans、JiBX和Castor将在CXF2.1版本中得到支持，目前版本是2.0.2Axis2支持多种语言，它有C/C++版本。ApacheCXF提供方便的Spring整合方法，可以通过注解、Spring标签式配置来暴露WebServices和消费WebServices

共七十六页Axis2,CXF的比较(bǐjiào)在特性方面：CXF支持WS–Addressing、WS-Policy、WS-RM、WS-Security和WS-IBasicProfile。Axis2支持除了WSPolicy之外的所有(suǒyǒu)这些标准，WS-Policy预计会在未来版本中得到支持；CXF可以方便地和Spring集成在一起，Axis2不行;Axis2支持范围更广的数据绑定，包括XMLBeans、JiBX、JaxMe、JaxBRI，以及它自己的数据绑定ADB。在Axis21.2版中，JaxME和JaxBRI尚处于试验阶段。目前，CXF只支持JAXB和Aegis，对XMLBeans、JiBX和Castor的支持将在CXF2.1版中实现；Axis2支持多语言，除了Java版本，尚有C/C++版本。共七十六页Axis2,CXF的比较(bǐjiào)在开发方面：Axis2更像一个微型服务器。Axis2被打包成一个WAR，可部署到任何Servlet容器中，为了更方便地在运行中管理和部署服务进行专门的设计(shèjì)。CXF更专注于对开发人员友好及可嵌入性。大部分配置只需使用API即可完成，与Spring紧密集成。CXF强调代码优先的服务开发方式。共七十六页XFire与Axis2比较(bǐjiào)

虽然XFire与Axis2都是新一代的WebService平台，但是Axis2的开发者太急于推出1.0版本，所以1.0还不是一个稳定的版本，它的开发者宣称1.1版本即将推出，希望1.1版本会是个稳定的版本。在XFire捐献给apache后有人认为Axis2将会灭亡。其实在很多人眼里，Axis2并不是pojo形式，DanDiephouse证明了XFire比Axis更有市场，我也发现了有很多人开始从Axis转向XFire，包括我也在说服身边的人转向利用XFire进行WebService的开发，很典型的是我可以在几分钟之内教会我的团队实用XFire来发布一个他自己的Web服务(fúwù)。本人倾向于XFire确实比Axis2简单很多共七十六页选择(xuǎnzé)axis2,cxf的建议如果需要多语言支持，那么就采用Axis2；如果考虑到使用Java、与Spring集成，或将服务嵌入到其他程序中，那么CXF更好。当然，并不是所有人都说好。例如，在国内的一些论坛上，就有开发者抱怨CXF的入门比起XFire来要复杂得多。这是可以理解的，毕竟CXF本身(běnshēn)也比XFire要复杂得多。为了帮助Celtix和XFire的开发者向新工具的迁移，其官方网站也提供了相应的迁移指南。另外一个常见的问题是和SpringAOP相关的（如事务、安全），这在官方网站的FAQ中也有说明。共七十六页选择(xuǎnzé)axis2,cxf的建议CXF的功能特性非常多，要熟练(shúliàn)使用它非得花些功夫才行。熟悉工具涉及领域的协议是个不错的主意。虽然CXF提供了简化服务创建的编程模型，但是如果不了解WS-*协议，在遇到问题调试时必然会花不少时间。尤其是在SOA的环境中，客户端和服务不一定是使用同一语言、同一工具实现的情况下，互操作问题经常是由于对协议的不同支持造成的；作为CXF实现内容的一个重点，JAX-WS是值得关注的；在Java的环境中，Spring几乎已经成为开发服务器端应用的首选，应重点关注CXF和Spring的配合使用；近些年来，Java世界的动态语言旋风愈演愈烈。Groovy由于其语法和Java兼容且提供了不少方便的语法，吸引了不少Java开发者。更何况新兴的Grails框架逐渐引人注目，其前途不可限量。GroovyWS专为Groovy开发，且底层就是CXF，作为CXF的开发者，没有理由不去使用可以使自己生活过得舒适的工具；CXF携带了大量的例程，它们是熟悉和了解CXF的大门的；参与社区，参与讨论，往往比起自己单干要有用得多。共七十六页性能(xìngnéng)对比

远程测试结果（单位：ms）服务器端axis2axis1xfirecxf客户端axis2axis1axis1axis2xfire+springaxis1cxfaxis1客户端初始化672.81040axis1772029942584421.610次中的初次调用值645.8606684.4427.810101190296.8321.810次平均值71.5870.3697.8260.28117.2139.135.343.37后9次平均值7.7810.5832.6419.4418.0427.136.24414.22从数据可以看出，有下面几个特点：客户端初次调用，初始化客户端stub对象时，大约在：600ms～2500ms。由于需要建立网络连接，初始化java相关对象，因此耗时较长。客户端初始化stub后，接口初次调用，大约在：400ms～1000ms。相比后续的接口调用时间最长。在第一次调用完毕后，随后的调用中，性能都明显提升。大约在：7ms～30ms。本机测试与远程测试，性能上差距很微小，在高速的局域网内，性能差别几乎可以忽略。在相同的服务端下，采用不同框架生成(shēnɡchénɡ)的stub代码调用时，时间上也存在一定的差异。最优组合是最差组合性能的5倍多。最优的组合为：cxf客户端+cxf服务端，6ms左右。最差的组合为：axis1客户端+axis1服务端，32ms左右。CXF作为服务端，对于不同的客户端调用时，性能最佳。共七十六页数据(shùjù)绑定对比DataBndings

XMLBeansJAXB1.1JAXB2.0CastorAegis(POJO)JiBXJaxMeJaxBRIADBxfire★★★★★

cxf2.0.2

★★

★

cxf2.1★★★★★★

Axis2★

★★★共七十六页选择(xuǎnzé)框架如果应用程序需要多语言的支持，Axis2应当是首选了；如果应用程序是遵循Spring哲学路线的话，ApacheCXF是一种更好的选择，特别对嵌入式的WebServices来说；如果应用程序没有新的特性(tèxìng)需要的话，就仍是用原来项目所用的框架，比如Axis1，XFire，Celtrix或BEA等等厂家自己的WebServices实现共七十六页数据(shùjù)绑定