Apache CXF软件架构指南-中文

http://cxf.apache.org/docs/cxf-architecture.html#CXFArchitecture-TableofContents

http://cxf.apache.org/docs/cxf-architecture.html

本文档提供了一个架构的概述Apache CXF服务框架

Table of Contents

• Apache CXF Software Architecture Guide
  • Table of Contents
  • Architectural Goals and Constraints
  • CXF-API
    • Bus
    • How service calls are processed
    • Front-ends
    • Messaging & Interceptors
    • The Service Model
    • Data Bindings
    • Protocol Bindings
    • Transports
    • A JAX-WS example
  • Dependencies
  • Quality
    • References

Architectural Goals and Constraints(架构目标和约束)

The Apache CXF services framework seeks to build the necessary infrastructure components for services. Goals for CXF are many and include:

Apache CXF服务框架试图建立必要的基础设施组件的服务。目标为CXF很多,包括:

• Embeddable
• High performance
• Easy configuration
• Intuitive and easy to use
• Clean separation of front-ends from the core code
• Data formats support
• Data bindings support
• Protocol bindings support
• Multiple transports support
• Multiple Programming Languages Support
• WS-* and related specifications support
• Tools for code generation and WSDL validation
• Flexible deployment

        可嵌入

        高性能

        容易配置

        直观和容易使用

        清洁分离前端从核心代码

        数据格式支持

        数据绑定支持

        协议绑定支持

        多种传输支持

        多种编程语言的支持

        WS - *和相关规范的支持

        代码生成工具和WSDL验证

        灵活部署

CXF-API

The overall CXF architecture is primarily made up of the following parts:

整体建筑主要由CXF的以下部分:

1. Bus: Contains a registry of extensions, interceptors and Properties
2. Front-end: Front-ends provide a programming model to create services.
3. Messaging & Interceptors: These provide the low level message and pipeline layer upon which most functionality is built.
4. Service Model: Services host a Service model which is a WSDL-like model that describes the service.
5. Pluggable Data Bindings: ...
6. Protocol Bindings: Bindings provide the functionality to interpret the protocol.
7. Transports: Transportfactory creates Destinations (Receiving) and Conduits (Sending)

1. 总线:包含一个注册表的扩展,拦截器和属性
2. 前端:前端提供一种编程模型来创建服务。
3. 消息传递和拦截器:这些提供低水平信息和管道层在大多数功能是建立。
4. 服务模式:服务主机服务模型,这是一个wsdl喜欢模型,该模型描述服务。
5. 可插入的数据绑定:……
6. 协议绑定:绑定提供功能来解释协议。
7. 传输:Transportfactory创建目的地(接收)和管道(发送)

In the upcoming sections, we'll take a look at each layer in turn and examine how they work together.  

在后面的小节中,我们将看看每一层反过来并检查他们是如何一起工作的。

Bus(总线)

The bus, being CXF's backbone, is a provider of shared resources to the CXF runtime. Examples for such shared resources include WSDL managers and binding factory managers. The bus can easily be extended to include your own custom resources or services, or you can replace default resources like the HTTP destination factory (based on Jetty) with your own (possibly based on another web container such as Apache Tomcat).

这个总线,是CXF的脊梁,是一个运行时提供共享资源来CXF应用。例子包括WSDL等共享资源管理者和绑定工厂管理。总线可以很容易地进行扩展,以包括您自己的自定义的资源或服务,或者你可以替换默认的资源(如HTTP描述工厂(基于Jetty)与您自己的(可能是基于另一个web容器如Apache Tomcat)集成。

这种可扩展性可以通过依赖注入;数据总线是基于spring框架实现的,在服务运行时组件组合在一起

This extensibility is made possible by dependency injection; the default bus implemenation is based on  Spring Framework, which wires the runtime components together for you.

这个扩展是通过依赖注入运行的；总线实现基于Spring框架进行开发，which wires the runtime components together for you.

The SpringBusFactory searches for all bean configuration files in the META-INF/cxf directories on your classpath, and builds an application context from them. The bean configuration files included in the application context construction are:

所有的bean的配置文件在这个/ CXF目录在你的类路径中的springbusfactory搜索，并建立一个应用程序上下文的。bean配置文件包含在应用程序环境的建设

• META-INF/cxf/cxf.xml (e.g., in cxf-rt-core only)
• META-INF/cxf/cxf-extension.xml (e.g. in cxf-rt-bindings-soap)
• META-INF/cxf/cxf-property-editors.xml (e.g. in cxf-rt-transports-http)

See  Configuration of the Bus for an example of how to customize the bus by supplying your own bean configuration file and  Configuration of Runtime Constructed Objects for more information on the special case of injecting into objects created by the runtime (as opposed to objects created by the IoC container itself).

看配置的总线为例如何定制总线通过提供自己的bean配置文件和配置运行时构建对象的更多信息注入特殊情况创建的对象运行时(而不是对象由IoC容器本身)。

How service calls are processed

服务处理方式

客户端

服务端

Front-ends

前端

Front-ends provide a programming model to interact with CXF. JAX-WS, JAX-RS, Simple and Javascript front-end APIs are provided by CXF . Each implementation is cleanly separated from the rest of CXF, just like the bindings and the core. Front-ends provide functionality through interceptors that are added to Services and Endpoints. See also Front-ends

前端与CXF提供一个编程模型。JAX-WS，JAX-RS，简单的JavaScript前端提供API的CXF。每个实现都是从CXF其余分离干净，就像绑定和核心。前端通过拦截器，添加到服务终结点提供的功能。参见前端

Messaging & Interceptors 

消息&拦截器

CXF is built on a generic messaging layer comprised of Messages, Interceptors, and InterceptorChains. Interceptors are the fundamental unit of functionality. By dividing up how messages are processed and sent, this gives CXF a very flexible architecture. It can be reconfigured at any point in the processing. This also gives CXF the ability to pause & resume interceptor chains.

CXF是建立在一个通用的消息传递层组成的消息，拦截，并interceptorchains。拦截器是功能的基本单位。通过将信息是如何处理和发送，这给CXF非常灵活的体系结构。它可以配置在任何点的处理。这也给CXF暂停和恢复拦截器链的能力。

Interceptors have a method,  handleMessage, which allows them to act on the Message.These Interceptors can then be built up into chains of interceptors, straightforwardly called InterceptorChains. Some examples include:

拦截机有一个方法，handleMessage，这使得他们行动的消息。这些系统可以建立成链的拦截器，直截了当地称为interceptorchains。一些例子包括：

• An interceptor which parses just the headers of a SOAP message into DOM elements
• A WS-Security interceptor which decrypts or authenticates an incoming message.
• An outgoing data binding interceptor which serializes the result

• 一个拦截器,解析就头一个SOAP消息到DOM元素
• 一个ws - security拦截这解密或验证一个传入消息。
• 一个外向数据绑定拦截这序列化结果

Interceptors are uni-directional and are inherently unaware of whether they are dealing with a request, response, or fault.

拦截导弹 定向 和 本质上是 不知道 他们是否 正在处理一个 请求 ， 响应 ， 或 故障

Phase Interceptors

阶段拦截器

CXF provides an  InterceptorChain implementation called the  PhaseInterceptorChain. When Interceptors are added to the chain, they are grouped into ordered phases.  A  PhaseInterceptor may provide guidance as to how it is to be ordered within the phase.

CXF 提供了一个 interceptorchain实施所谓的phaseinterceptorchain。当拦截器添加到链， 它们被分为 有序相 。 一个 phaseinterceptor 可能 提供指导如何 可以 下令 在相

Let us take a hypothetical simplified example (NOTE: these phases and interceptors don't necessarily exist in CXF). Let us say we are parsing a SOAP message. We may want to have two phases. First, a dispatch phase which parses the soap headers and determines which service to route the Message to. Second, an unmarshal phase which binds the SOAP body to JAXB objects. In the first dispatch phase we could implement this via two interceptors, first a ReadHeadersInterceptor which parses the headers and second a WS-AddressingInInterceptor which determines which service we're invoking from the WS-Addressing header. In the second unmarshal phase, we have just a single JAXBUnmarshallerIntercptor. Both the ReadHeadersInterceptor and AddressingInInterceptor would tell the PhaseInterceptorChain they are in the "dispatch" phase by returning "dispatch" when getPhase() is called. Additionally, the ReadHeadersInterceptor could specify that it wants to run before the AddressingInInterceptor by returning the interceptor id when Interceptor.getBefore() is called.

让我们做个假设简化的例子（注：这些阶段和拦截器不一定存在于CXF）。让我们说我们是解析SOAP消息。我们可以要两个阶段。首先，一个调度相解析SOAP标头和确定路由邮件的服务。第二，分解结合皂体JAXB对象相。在第一个调度相我们可以实现通过两个拦截器，第一个readheadersinterceptor解析头和第二个WS addressingininterceptor确定要调用的服务寻址标头。在第二分解阶段，我们只有一个jaxbunmarshallerintercptor。无论是readheadersinterceptor和addressingininterceptor会告诉phaseinterceptorchain他们在“调度”阶段的“调度”getphase()返回时被称为。此外，该readheadersinterceptor可以指定要运行前的addressingininterceptor返回拦截器拦截getbefore()叫ID时。

Before it was mentioned how chains were very dynamic and flexible. In our above example, we could add interceptors specific to that service once it is resolved. Or we could pause the chain once while we wait for some external chain, like an asynchronous service response.

在提到链非常动态的和灵活的。在我们上面的例子，我们可以把它一旦解决，服务特定的拦截。或者我们可以暂停链一旦在我们等待一些外链，像一个异步服务响应。

Fault Handling    故障处理；

At any point during processing, an interceptor may throw a Fault, or a derivative of a Fault like the SoapFault. This will cause the chain to stop invoking and unwind it. Unwinding consists of calling handleFault on each interceptor that was invoked in reverse order.

在任何点 在加工过程中， 拦截 可能 抛出故障 ， 或衍生 的故障 如 SoapFault 。 这将导致 链 停止 调用和 解开 它 。 解除 由 每个 拦截机， 是在 相反的顺序 调用 调用 handlefault 。

InterceptorChains have the concept of a fault observer. Once the chain is unwound, the fault interceptor is invoked with the message that caused the fault. The fault observer may trigger a new chain which then invokes a specified set of interceptors meant to handle faults.

interceptorchains有故障观测器的概念。链条一旦消失，故障拦截器是引起故障的消息调用。故障观测器，将可能引发新的链，然后调用指定的一组系统意味着故障处理。

exchanges 交换

In addition to the concept of a Message, there is the concept of the Exchange. The exchange class holds a references to the in, out and fault messages for the current message exchange.

除了一个消息的概念，有交换的概念。交流类拥有一个参考的，和故障的消息交换的消息。

It also holds properties specific to the exchange, and not just the message. For instance the Exchange holds the Service that is current being invoked in it.

它也认为，Exchange特定的属性，而不是消息。例如交易所认为，目前正在调用它的服务。

Reentrant InterceptorChains 折返interceptorchains

An interesting feature of the PhaseInterceptorChain is that it is reentrant. This can be powerful and slightly dangerous. This feature is only used in CXF during the sending of an outgoing message, The SoapOutInterceptor is the best example:

phaseinterceptorchain的一个有趣的特点是，它是可重入的。这是强大的，稍有危险。此功能仅用于CXF在发送的传出消息，该soapoutinterceptor就是最好的例子：

public void handleMessage(Message m) { writeSoapEnvelopeStart(); writeSoapBodyStart(); // invoke next interceptor, which writes the contents of the SOAP Body m.getInterceptorChain().doIntercept(m); writeSoapBodyEnd(); writeSoapEnvelopeEnd(); }

The Service Model  服务模型

The Service model is the representation of a service within CXF. It is made up of two parts. First there is the ServiceInfo which contains a WSDL-like model of the service and its operations, bindings, endpoints and schema. Second, there is the Service itself, which contains the ServiceInfo, data-binding information, service interceptors, service properties and more.

该服务模型在CXF服务的表示。它是由两部分组成的。首先，它包含一个WSDL之类的服务模型及其操作，每个端点的绑定，和图式。第二，有服务本身，其中包含的每个绑定信息，数据，服务拦截机，使用性能和更。

A service can be constructed from many different sources including classes and WSDLs (1.1 or 2.0). Typically front-ends are responsible for creating a service via service factories. Factory components such as ServerFactoryBean and ClientProxyFactoryBean can used with the front-end to create, publish and consume web services. The factory classes build up the service model and configure the service interceptors, data bindings and more.

一个服务可以从许多不同的来源，包括类和WSDL构造（1.1或2）。典型的前端负责通过服务工厂创建服务。本厂元件如serverfactorybean和clientproxyfactorybean可以用于前端的创建，发布和使用Web服务。工厂类建立服务模型和配置服务系统，数据绑定和更多。

The Service model itself is contained in the ServiceInfo class. The following image depicts a subset of the Service Model's packaged API:

服务模型本身是包含在每个类。下图展示了一部分的服务模式的打包的API：

Data Bindings 数据绑定

Data bindings implement the mapping between XML elements and Java objects. Data bindings convert data to and from XML, produce XML schema, and provide support for wsdl2java code generation. Not all data bindings support all of this functionality. At very least, a data binding must provide the data conversion. See Data Binding Architecture for details. Currently supported data bindings include JAXB 2.x (default), Aegis, Apache XMLBeans, Service Dat Objects (SDO) and JiBX (under development).

数据绑定实现XML元素和Java对象之间的映射。数据绑定的数据转换和XML，产生XML模式，并提供WSDL2Java支持代码生成。不是所有的数据绑定支持所有的这些功能。至少，数据绑定必须提供的数据转换。看到数据绑定结构的细节。目前支持的数据绑定包括JAXB 2。X（默认），盾，Apache XMLBeans，服务数据对象（SDO）和JiBX（开发）。

Protocol Bindings 协议绑定

Bindings provide ways to map concrete formats and protocols on top of transports. A binding contains two main parts, a BindingFactory and a Binding. A BindingFactory builds a Binding from the service model's BindingInfo. The binding contains interceptors specific to the binding and also implements the createMessage() method, which creates a Message implementation specific for that binding.

绑定提供在运输混凝土格式和协议的映射方法。结合主要包含两个部分，一个bindingfactory和绑定。一个bindingfactory建立一个绑定的服务模式的绑定信息。结合包含特定于绑定和拦截系统还实现了createmessage()方法，它创建了一个绑定特定消息的实现。

CXF currently supported the following bindings protocols: SOAP 1.1, SOAP 1.2, REST/HTTP, pure XML and CORBA. 

CXF 目前支持以下绑定协议： SOAP 1.1, SOAP 1.2, REST/HTTP ，纯XML 和CORBA 。

The Soap Binding SOAP绑定

The prototypical binding is SOAP. It has its own Message class called the SoapMessage. It adds the ability to hold the current SoapVersion and the headers for the message.

典型的结合是肥皂。它有自己的消息类称为SOAPMessage。它增加了抓住当前soapversion和消息头的能力。

The Soap binding also adds a special type of interceptor called the SoapInterceptor. The SoapInterceptor adds two methods to the Interceptor class:

SOAP绑定还增加了一种特殊类型的拦截称为soapinterceptor。该soapinterceptor添加两种方法拦截器类：

Set<URI> getRoles(); Set<QName> getUnderstoodHeaders();

These inform the SOAP interceptors as to what headers and roles the particular SOAP interceptor understands.

这些通知SOAP拦截器是什么标题和角色的特定的SOAP拦截器的理解。

It has many interceptors designed to handle SOAP messages:

它有很多设计处理SOAP消息的拦截：

1. StaxInInterceptor: Creates an XMLStreamReader from an incoming InputStream
2. ReadHeadersInterceptor: Reads the headers into the SoapMessage
3. MustUnderstandInterceptor: Checks the MustUnderstand attributes of all the headers against all the SoapInterceptor's getUnderstoodHeaders method.
4. SoapOutInterceptor:

1.staxininterceptor：创建一个XMLStreamReader传入的输入流

2.readheadersinterceptor：读取头的SOAPMessage

3.mustunderstandinterceptor：检查所有对所有的soapinterceptor的getunderstoodheaders标题的MustUnderstand属性的方法。

4.soapoutinterceptor：

Additional Bindings 附加的绑定

Other bindings include REST/HTTP binding, pure XML binding, and the CORBA binding.

其他的绑定包括休息/ HTTP绑定，纯XML绑定，和CORBA的结合。

Transports运送

CXF includes its own transport abstraction layer to hide transport specific details from the binding and front end layers. Currently supported transports include: HTTP, HTTPs, HTTP-Jetty, HTTP-OSGI, Servlet, local, JMS, In-VM and many others via the Camel transport for CXF such as SMTP/POP3, TCP and Jabber. Learn more about transports here.

CXF包括自己的运输抽象层的结合和前端层隐藏传输的具体细节。目前支持包括：HTTP，HTTPS传输，HTTP码头，http-osgi，Servlet，地方，JMS，在虚拟机和其他许多人通过为CXF如smtp/pop3骆驼运输，TCP协议与Jabber。了解更多关于运输在这里。

Conduits中转人

Conduits provide the basis for outgoing message sending. A Conduit is created from a ConduitInitiator. Sending a message is a multistep pocess:

管道提供了依据，即将离任的消息发送。管道从conduitinitiator创建。发送消息是一个多步骤的过程：

1. Call conduit.prepare(message): this starts the message sending. At this point a Conduit may initiate a connection and set the OutputStream for the outgoing message.
2. Writing of the actual message to the OutputStream
3. Call to conduit.close(message): this closes and disposes of any existing resources for the message sending.
   A message sender may also register a MessageObserver with the Conduit. If the Conduit is synchronous, the MessageObserver will be notified once a response has been received.

1。调用管道。准备（消息）：这将启动消息发送。在这一点上，导管可以发起一个连接，为即将离任的消息集的输出流。

2。到输出流的实际消息写作

3。调用管道。关闭（消息）：这一关和处置的任何现有的资源来发送消息。

消息发送者也可以注册一messageobserver导管。如果管道是同步的，这将是一次messageobserver回复已收到通知。

Destinations目的地

Destinations are the basis for receiving incoming messages. A destination is created from a DestinationFactory:

目的地接收的传入消息的基础。目的是从一个destinationfactory创建：

DestinationFactoryManager dfManager = bus.getExtension(DestinationFactoryManager.class); // Find a DestinationFactory for the SOAP HTTP transport DestinationFactory df = dfManager.getDestinationFactory("http://schemas.xmlsoap.org/wsdl/soap/http"); // TODO: outline building of EndpointInfo EndpointInfo endpointInfo = ...; Destination destination = df.getDestination(endpointInfo);

MessageObservers can then be registered with Destinations. These listen for incoming messages:

messageobservers可以注册地。这些侦听传入的消息：

MessageObserver myObserver = ...; destination.setMessageObserver(myObserver);

The most common MessageObserver used in CXF is the ChainInitiationObserver. This takes the incoming message, creates a message Exchange & PhaseInterceptorChain, then starts the chain.

使用CXF最常见的messageobserver是chaininitiationobserver。这需要传入的消息，创建一个消息交换和phaseinterceptorchain，然后启动链。

A JAX-WS example JAX-WS的例子

Here's a small example of what might happen when we publish a service via the JAX-WS Endpoint.publish() method.

这是发生在我们发布一个服务通过JAX-WS端点可能是一个小例子。publish()方法。

1. Call to Endpoint.publish("http://localhost/service", myService)
2. The EndpointImpl creates a Service from the myService object using the JaxWsServiceFactoryBean using the class and/or WSDL
3. An EndpointInfo is created for the Endpoint.publish URL
4. A JaxWsEndpointImpl is created from the EndpointInfo. This contains the JAX-WS endpoint specific interceptors
5. The JaxWsEndpointImpl creates a Binding and Destination to listen on.

1。呼叫端点。出版（“http://localhost /服务”，那么）

2的endpointimpl。创建一个服务使用jaxwsservicefactorybean使用类和/或WSDL MyService对象

3。一个endpointinfo为endpoint.publish URL创建

4。一个jaxwsendpointimpl从endpointinfo创建。这包含了JAX-WS端点具体拦截

5的jaxwsendpointimpl。创建一个绑定和听的目的地。

Dependencies 附属

CXF's dependencies

Quality 优点

CXF's Software Quality approach is detailed here.

References 证明书

• Software Architecture, Wikipedia
• Sample S/W Architecture Document, Rational Software Corporation
• Documenting your Software Architecture, by Jim Alateras (March 2006)