阅读(351)

详解Apache CXF 框架结构和基本原理

最后一次修改 2017年12月27日

本文主要和大家分享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在整个请求响应的处理流程 中所处的位置。 

20171227142742386.jpg 
二、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服务器安装与测试步骤图文实例详解

php开发环境(二):PHP与Apache整合图文详解

Apache的对象复制实例教程实例详解