Apache CXF 框架结构和基本原理

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

1.Bus

它是C X F架构的主干，为共享资源提供了一个可配置的场所，作用非常类似于S p r i n g的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.前端（Front End）

它为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
　　一、基本原理
　　下面看看CFX Interceptor在整个请求响应的处理流程 中所处的位置。





　　二、CFX Interceptor的核心API
　　先看拦截器核心包org.apache.cxf.interceptor的说明：Core interceptor interfaces which form the basis for message processing chains in CXF.
　　翻译：CXF消息处理链最基本的拦截器接口。
　　一下多个 的API的介绍和翻译来自互联网：
　　Interceptor
　　定义两个要领 ，一个处理消息 handleMessage， 一个是处理不正确 handleFault。别看Interceptor这么基本 ，这里须要 提醒留心的是，在执行具体的Interceptor的这两个要领中，千万别调用Interceptor内部的成员变量。这是由于Interceptor是面向消息来执行处理的，每个Interceptor都有可能运行在不同的线程中，如果调用了Interceptor中的内部成员变量，就有在Interceptor中造成临界资源的访问的情况，而这时的Interceptor也就不是线程安全的Interc eptor了。
　　在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操作有关的信息。可以获取配置的对象有InterceptorChain Exchange Destination，还有获取配置 Content的泛型接口，是不是感觉Message和Bus差不多，都成了大杂货铺，一切与消息处理有关的信息都可以放在Message中。我想这也是咱CXF以Message处理为中心的设计思想的具体表现吧。
　　Exchange
　　和Message打交道就离不开Exchange。Exchange建立In/Out，InFault/OutFault Message 之间的联系。你可以从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]