Apache CXF 框架结构和基本原理

CXF旨在为服务创建必要的基础设施，它的整体架构主要由以下几个部分组成：

1.Bus

它是CXF架构的主干，为共享资源提供了一个可配置的场所，作用非常类似于Spring的ApplicationContext。这些共享资源包括WSDL管理器、绑定工厂等。通过对Bus进行扩展，可以方便地容纳自己的资源，或替换现有的资源。默认Bus实现是基于Spring的，通过依赖注入，将运行时组件串起来。Bus的创建由BusFactory负责，默认是SpringBusFactory，对应于默认Bus实现。在构造过程中，SpringBusFactory会搜索META-INF/cxf（就包含在CXF的Jar中）下的所有Bean配置文件，根据它们构建一个ApplicationContext。开发者也可提供自己的配置文件来定制Bus。

2.消息传递和拦截器（Interceptor）

CXF建立于一个通用的消息层之上，主要由消息、拦截器和拦截器链（InterceptorChain）组成。CXF是以消息处理为中心的，熟悉JSP/Servlet的开发者可以将拦截器视为CXF架构中的“Filter”，拦截器链也与“FilterChain”类似。通过拦截器，开发者可以方便地在消息传递、处理的整个过程中对CXF进行扩展。拦截器的方法主要有两个：handleMessage和handleFault，分别对应消息处理和错误处理。在开发拦截器的时候需要注意两点：

拦截器不是线程安全的，不建议在拦截器中定义实例变量并使用它。这一点跟JSP/Servlet中对于Filter的处理是一样的；

不要调用下一个拦截器的handleMessage或handleFault，这个工作由InterceptorChain来完成。

3.前端（FrontEnd）

它为CXF提供了创建服务的编程模型，当前主要的前端就是JAX-WS。

4.服务模型

CXF中的服务通过服务模型来表示。它主要有两部分：ServiceInfo和服务本身。ServiceInfo作用类似WSDL，包含接口信息、绑定、端点（EndPoint）等信息；服务则包含了ServiceInfo、数据绑定、拦截器和服务属性等信息。可使用Java类和WSDL来创建服务。一般是由前端负责服务的创建，它通过ServiceFactory来完成。

5.绑定（Binding）

绑定提供了在传输之上映射具体格式和协议的方法，主要的两个类是Binding和BindingFactory。BindingFactory负责创建Binding。

6.传输（Transport）

为了向绑定和前端屏蔽传输细节，CXF提供了自己的传输抽象。其中主要有两个对象：Conduit和Destination。前者是消息发送的基础，后者则对应消息接收。开发者还可以给Conduit和Destination注册MessageObserver，以便在消息发送和接收时获得通知。

CXF的拦截器是CXF功能最主要的扩展点。通过自定义的Interceptor，可以改动请求和响应的一些消息处理，其中最基本的原理还是一个动态代理。

Interceptor是CXF架构中一个很有特色的模式。你可以在不对核心模块执行修改的情况下，动态添加很多功能。这对于CXF这个以处理消息为中心的服务框架来说是非常有用的，CXF通过在Interceptor中对消息执行特殊处理，实现了很多主要功能模块，例如：日志记录，Soap消息处理，消息的压缩处理。

如果你想对CXF执行扩展，建议你先从interceptor开始。

为了更好的学习和运用CXF，最好先阅读官方的用户手册：

http://cwiki.apache.org/CXF20DOC/index.html

一、基本原理

下面看看CFXInterceptor在整个请求响应的处理流程中所处的位置。

二、CFXInterceptor的核心API

先看拦截器核心包org.apache.cxf.interceptor的说明：CoreinterceptorinterfaceswhichformthebasisformessageprocessingchainsinCXF.

翻译：CXF消息处理链最基本的拦截器接口。

一下多个的API的介绍和翻译来自互联网：

Interceptor

定义两个要领，一个处理消息handleMessage，一个是处理不正确handleFault。别看Interceptor这么基本，这里须要提醒留心的是，在执行具体的Interceptor的这两个要领中，千万别调用Interceptor内部的成员变量。这是由于Interceptor是面向消息来执行处理的，每个Interceptor都有可能运行在不同的线程中，如果调用了Interceptor中的内部成员变量，就有在Interceptor中造成临界资源的访问的情况，而这时的Interceptor也就不是线程安全的Interceptor了。

在CXF中最常运用的Interceptor都放在cxf-rt-core中的org.apache.cxf.interceptor中，有兴趣的朋友可以研究一下。

InterceptorChain

单个的Interceptor功能有限，CXF要实现一个SOAP消息处理，须要将许许多多的Interceptor组合在一起运用。因此设计了InterceptorChain，在我看了InterceptorChain就像是一个Interceptor的小队长。小队长有调配安置Interceptor的权力（add，remove），也有控制消息处理的权力（doInterceptor，pause，resume，reset，abort），同时也有交付不正确处理的权力（{getset}FaultObserver）。更有意思的是为灵活控制Interceptor的处理消息顺序（doInterceptStartingAt，doInterceptorStartingAfter），这也是InterceptorChain比较难理解的地点。

有兴趣的朋友可以跟踪一下，CXF的Client与Server之间通讯是走过哪些Interceptor，这些Interceptor是如何被调用的。

Fault

定义了CXF中的不正确消息。

InterceptorProvider

这里定义了Interceptor的后备保证部队。我们可以在InterceptorProvider中配置In，Out，InFault，OutFault后备小分队，添加我们所希望添加的Interceptor。而InterceptorChain会根据这些后备小分队，组建自己的小分队实例，完成具体的作战功能任务。

AbstractAttributedInterceptorProvider

InterceptorProvider实现的抽象类，由于这个类来继承了HashMap，我们可以像这个类中存储一些属性信息。

AbstractBasicInterceptorProvider

与AbstractAttributedInterceptorProvider不同，这个Interceptor只是基本实现了InterceptorProvider的功能，并不提供对其属性存储的扩展。

Message

由于Interceptor是针对Message来执行处理的，当你打开Message这个类文件时，你会发觉在Message中定义了很多常量，同时你还可以从Message中获取到很多与Message操作有关的信息。可以获取配置的对象有InterceptorChainExchangeDestination，还有获取配置Content的泛型接口，是不是感觉Message和Bus差不多，都成了大杂货铺，一切与消息处理有关的信息都可以放在Message中。我想这也是咱CXF以Message处理为中心的设计思想的具体表现吧。

Exchange

和Message打交道就离不开Exchange。Exchange建立In/Out，InFault/OutFaultMessage之间的联系。你可以从Exchange中获取到与消息传输有关的Conduit，Destination的信息，同时也可以配置和Session有关的其他信息，以及知道能不能是OneWay的消息。

AbstractFeature

为了简化配置Interceptor的复杂操作，在这里配置了AbstractFeature，通过Feature我们可以向Bus，Client，Endpoint配置不同功能的Interceptor组。这样可以极大减轻我们配置文件的体积。

官方API网址:http://cxf.apache.org/docs/cxf-architecture.html

以上官方API地址以现发布时间为准文档属于API翻译版,如有翻译错误,请大家见谅!

2013年5月20日15:15:34

[size=medium][size=x-small][/size][/size]