Apache CXF Framework Structure and rationale (RPM)

Original link: http://blog.sina.com.cn/s/blog_6182547f01017pak.html

The CXF is designed to create the necessary infrastructure for the service, and its overall architecture consists mainly of the following components:

1.Bus

It is the backbone of the C X F architecture, providing a configurable place for shared resources, very similar to the ApplicationContext of s P r i n G. These shared resources include the WSDL manager, the binding factory, and so on. By extending the bus, you can easily accommodate your own resources or replace existing resources. The default bus implementation is spring-based, which strings the runtime components through dependency injection. The bus is created by Busfactory and the default is Springbusfactory, which corresponds to the default bus implementation. During construction, Springbusfactory searches all bean profiles under META-INF/CXF (in the jar contained in CXF), building a applicationcontext based on them. Developers can also provide their own configuration files to customize the bus.

2. Message passing and interceptors (interceptor)

CXF is built on a common message layer, consisting mainly of messages, interceptors, and interceptor chains (Interceptorchain). CXF is message-centric, and developers familiar with Jsp/servlet can view interceptors as "Filter" in the CXF architecture, and the interceptor chain is similar to "Filterchain". With interceptors, developers can easily extend the CXF throughout the entire process of message delivery and processing. Interceptors have two main methods: Handlemessage and Handlefault, respectively, corresponding to message processing and error handling. There are two points to note when developing interceptors:

Interceptors are not thread-safe, it is not recommended to define an instance variable in the interceptor and use it. This is the same as the processing of filter in Jsp/servlet;

Do not call the next interceptor's Handlemessage or Handlefault, this work is done by Interceptorchain.

3. Front End (Front end)

It provides CXF with a programming model for creating services, and the current main front end is Jax-ws.

4. Service Model

Services in CXF are represented by service models. It has two main parts: serviceinfo and service itself. ServiceInfo functions like WSDL, containing information such as interface information, bindings, Endpoints (EndPoint), and services that contain information such as serviceinfo, data binding, interceptors, and service properties. You can use Java Classes and WSDL to create services. Typically, the front-end is responsible for creating the service, which is done through servicefactory.

5. Bindings (binding)

Bindings provide a way to map specific formats and protocols on top of the transport, and the main two classes are binding and bindingfactory. Bindingfactory is responsible for creating the binding.

6. Transmission (Transport)

To transmit details to the binding and front-end masks, CXF provides its own transport abstraction. There are two main objects: conduit and destination. The former is the basis for message delivery, while the latter corresponds to message reception. Developers can also register Messageobserver with conduit and destination to get notified when messages are sent and received.

The CXF interceptor is the most important extension point of the CXF function. With custom interceptor, you can change some message processing for requests and responses, the most basic of which is a dynamic proxy.
Interceptor is a very distinctive pattern in the CXF architecture. You can add many features dynamically without modifying the core module. This is useful for CXF, a message-centric service framework that implements a number of key functional modules, such as log records, SOAP message processing, and message compression, by performing special processing of messages in interceptor.
If you want to perform an extension on CXF, it is recommended that you start with interceptor first.
In order to better learn and use CXF, it is best to read the official user manual:
Http://cwiki.apache.org/CXF20DOC/index.html
First, the basic principle
Below is a look at the location of the CFX interceptor in the process of the entire request response.





Ii. CFX Interceptor's core API
First look at the Interceptor Core Pack Org.apache.cxf.interceptor Description: Core Interceptor interfaces which form the basis for message processing chains in CX F.
Translation: CXF the most basic interceptor interface of the message processing chain.
A few more APIs are introduced and translated from the Internet:
Interceptor
Define two essentials, one processing message handlemessage, one is handling incorrect handlefault. Although interceptor is so basic, it is necessary to note that in the implementation of the specific interceptor of the two essentials, do not invoke interceptor internal member variables. This is because interceptor is a message-oriented process, and each interceptor is likely to run in a different thread, and if an internal member variable in interceptor is called, there is a case of critical resource access in interceptor. And then the interceptor is not thread-safe Interc eptor.
The most commonly used interceptor in CXF are placed in the org.apache.cxf.interceptor of Cxf-rt-core, and interested friends can study it.
Interceptorchain
A single interceptor function is limited, CXF to implement a SOAP message processing, you need to combine many interceptor together. So the design of the Interceptorchain, I looked at the Interceptorchain is like a interceptor of the little captain. The captain has the power to deploy the Interceptor (Add,remove), as well as the power to Control Message processing (Dointerceptor,pause,resume,reset,abort), as well as the right to deliver incorrect handling ({Getset} Faultobserver). More interesting is the Interceptor Processing message Order (Dointerceptstartingat,dointerceptorstartingafter) for flexible control, which is interceptorchain more difficult to understand the location.

Interested friends can follow up, CXF client and server communication between the interceptor, these interceptor is how to be called.
Fault
An incorrect message was defined in the CXF.
Interceptorprovider
This defines the interceptor's reserve guarantee unit. We can configure the In,out,infault,outfault backup squad in Interceptorprovider to add the interceptor we want to add. And Interceptorchain will be based on these backup units, the formation of their own team instances, complete the specific combat function tasks.
Abstractattributedinterceptorprovider
Interceptorprovider implementation of the abstract class, because this class to inherit the HashMap, we can store some property information like this class.
Abstractbasicinterceptorprovider
Unlike Abstractattributedinterceptorprovider, this interceptor simply implements the Interceptorprovider function and does not provide an extension to its property store.
Message
Since interceptor is handled for message, when you open the message class file, you will notice that many constants are defined in the message, and you can also get a lot of information about the message operation from the message. The object that can get the configuration has Interceptorchain Exchange Destination, and the generic interface that gets the configuration content, does it feel like message and bus, all become big grocery stores, All information related to message processing can be put in a message. I think this is also our CXF with the message processing as the center of the design idea of the concrete performance bar.
Exchange
Dealing with a message is inseparable from Exchange. Exchange establishes a connection between In/out,infault/outfault Message. You can get information about the conduit,destination of the message transfer from Exchange, as well as configure additional information about the session and know if it is possible to oneway the message.
Abstractfeature
To simplify the complex operation of configuring Interceptor, Abstractfeature is configured here, and by feature we can configure interceptor groups for different functions to bus,client,endpoint. This can greatly reduce the volume of our configuration files.

Official API URL: http://cxf.apache.org/docs/cxf-architecture.html

The above official API address to the current release time for the document belongs to the API translation version, if there are translation errors, please forgive me!

May 20, 2013 15:15:34

Apache CXF Framework Structure and rationale (RPM)