Apache CXF框架结构和基本原理(转)

原文链接:http://blog.sina.com.cn/s/blog_6182547f01017pak.html

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在整个请求响应的处理流程 中所处的位置。
Apache CXF框架结构和基本原理(转)

  二、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

上一篇:Docker入门第一章


下一篇:jquery mobile listview列表属性(搜索自动填充检索效果)