本文主要和大家分享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，分别对应消息处理和错误处理。在开发拦截器的时候需要注意两点：
1)拦截器不是线程安全的，不建议在拦截器中定义实例变量并使用它。这一点跟JSP/Servlet中对于Filter的处理是一样的；
2)不要调用下一个拦截器的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消息处理链最基本的拦截器接口。
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
Message
由于Interceptor是针对Message来执行 处理的，当你打开Message这个类文件时，你会发觉在Message中定义了很多常量，同时你还可以从Message中获取到很多与Message操作有关 的信息。可以获取配置的对象有InterceptorChain Exchange Destination，还有获取配置 Content的泛型接口，是不是感觉Message和Bus差不多，都成了大杂货铺，一切与消息处理有关的信息都可以放在Message中。我想这也是咱CXF以Message处理为中心的设计思想的具体表现吧。
Exchange
AbstractFeature
为了简化配置Interceptor的复杂操作，在这里配置了AbstractFeature，通过Feature我们可以向Bus，Client，Endpoint配置不同功能的Interceptor组。这样可以极大减轻我们配置文件的体积。
官方API网址:http://cxf.apache.org/docs/cxf-architecture.html
以上官方API地址以现发布时间为准 文档属于API翻译版,如有翻译错误,请大家见谅!
相关推荐：
php开发环境一：Apache服务器安装与测试步骤图文实例详解
