Archive
[CXF]CXF中的AbstractFactory模式应用.
首先,我们来看下Abstract Factory模式:
[意图]
Provide an interface for creating families of related or dependent
objects without specifying their concrete classes.
[参与者和职责]
- AbstractFactory
- declares an interface for operations that create abstract products
- ConcreteFactory
- implements the operations to create concrete product objects
- AbstractProduct
- declares an interface for a type of product object
- Product
- defines a product object to be created by the corresponding concrete factory
- implements the AbstractProduct interface
下面我们来看CXF中的代码:
BindingFactory: (对应AbstractFactory角色)
public interface BindingFactory {
Binding createBinding(BindingInfo binding);
BindingInfo createBindingInfo(Service service, String namespace, Object configObject);
void addListener(Destination d, Endpoint e);
}
SoapBindingFactory (对应Concrete Factory角色)
Binding, BindingInfo (对应Abstract Product角色)
SoapBinding, XMLBinding, SoapBindingInfo(对应Concrete Product角色).
举第2个例子在CXF中使用这个模式的.
Databinding (对应Abstract Factory角色)
JAXBDatabinding, AegisDatabinding, SourceDataBinding (对应Concrete Factory角色)
DataReader, DataWriter (对应Abstract Product角色)
NodeDataReader, XMLStreamDataReader, NodeDataWriter… (对应Concrete Product角色)
虽然说在这里,Databinding类我们用的是interface而不是用abstract,但是从使用的意义和用途,我们仍可断定是Abstract Factory模式.
参考资料:
——————-
http://www.dofactory.com/Patterns/PatternAbstract.aspx
[CXF]CXF中的Interceptor模式应用
Interceptor:
* Defines an interface for integrating out-of-band services
Concrete Interceptor:
* Implements a specific out-of-band service
* Uses context object to control the concrete framework.
Dispatcher
* Allows applications to register and remove concrete interceptors.
* Dispatches registered concrete interceptor callbacks when event occur
Context Object
* Allows services to obtain information from the concrete framework
* Allows services to control certain behaviour of the concrete framework.
看上去是很好理解的… Dispatcher负责添加和删除Interceptor, Concrete Interceptor通过Context Object获取到具体的上下文内容,去改变值,或者处理业务功能.
现在我们来看下CXF中是怎么使用Interceptor模式的.
Interceptor (对应Interceptor角色)
public interface Interceptor<T extends Message> {
void handleMessage(T message) throws Fault;
void handleFault(T message);
}
在CXF当中,还引入了一个Phase的概念.相当于说在Interceptor顺序方面加了一个比较大粒度的区别. 比如说,执行的phase顺序为:
pre-invoke, invoke, post-invoke. 具体的Phase优先级可以参考PhaseManagerImpl看看到底有哪些Phases.
所以说,在CXF当中,真正对应(Interceptor角色)的应该是PhaseInterceptor
对于每个concrete Interceptor来讲,它一定要指定自己是属于哪个Phase.
这里我们以MessageSenderInterceptor 来作为Concrete Interceptor的例子.
Message (对应Context Object角色),从Message这里你可以获取到你所要的信息,可以说所有的内容都可以从Message里面直接或者间接取到.
InterceptorChain (对应Dispatcher角色),在InterceptorChain里,我们可以进行增加,删除一个Concrete Interceptor.同时,也负责根据Phase和ID的顺序来执行各个Interceptor,具体的你可以参考PhaseInterceptorChain的实现.
我觉得这个InterceptorChain名字起得挺好的,因为如果你看它实现的话,里面用的就是链表来实现顺序的..
虽然我们上面把各个角色都介绍完了,但是当你看CXF的代码时候,你不会看到用InterceptorChain来注册具体实现的Interceptor,那么又是谁来充当这个注册器呢.
在CXF中,还有个类,叫做InterceptorProvider,根据名字,我们可以看出,凡是实现这个接口的,都有可能提供Interceptor,也就是说,Interceptor的注册器.
我们来看看有哪些类实现这个接口.
BUS, Client, Service, Binding, Endpoint. 这些地方都有可能提供他们的Interceptor. 记住我们的concrete interceptor实际上就是一个小模块的逻辑处理,比如我有可能是soapBinding,那么我就需要做一些soap binding所需要的特殊逻辑,这个时候,我们就需要在binding这个扩展点加入我们所需要的interceptors来处理. 一般来说,在InterceptorProvider里面注册的时候是没有顺序的. 我们会通过PhaseChainCache来对它构造出一个PhaseInterceptorChain. 然后再来调用doIntercept(Message)方法: 比如如下的代码.(摘自ClientImpl.java)
protected PhaseInterceptorChain setupInterceptorChain(Endpoint endpoint) {
PhaseManager pm = bus.getExtension(PhaseManager.class);
List<Interceptor> i1 = bus.getOutInterceptors();
if (LOG.isLoggable(Level.FINE)) {
LOG.fine("Interceptors contributed by bus: " + i1);
}
List<Interceptor> i2 = endpoint.getOutInterceptors();
if (LOG.isLoggable(Level.FINE)) {
LOG.fine("Interceptors contributed by endpoint: " + i2);
}
List<Interceptor> i3 = getOutInterceptors();
if (LOG.isLoggable(Level.FINE)) {
LOG.fine("Interceptors contributed by client: " + i3);
}
List<Interceptor> i4 = endpoint.getBinding().getOutInterceptors();
if (LOG.isLoggable(Level.FINE)) {
LOG.fine("Interceptors contributed by binding: " + i4);
}
return outboundChainCache.get(pm.getOutPhases(), i1, i2, i3, i4);
}
PhaseInterceptorChain chain = setupInterceptorChain(endpoint);
message.setInterceptorChain(chain);
modifyChain(chain, requestContext);
chain.setFaultObserver(outFaultObserver);
// setup conduit selector
prepareConduitSelector(message);
// execute chain
chain.doIntercept(message);
说到这里, 还需要提一点的就是: 在CXF中,还引入了另外一个概念: AbstractFeature, 这个我是从我同事willem的blog中知道了这个概念. 可能对于某个interceptor来说, 他要在IN, OUT, FAULTIN, FAULTOUT都需要这个interceptor,那么用feature.
* A Feature is something that is able to customize a Server, Client, or Bus, typically adding capabilities. For instance, there may be a LoggingFeature which configures one of the above to log each of their messages.
By default the initialize methods all delegate to initializeProvider(InterceptorProvider). If you’re simply adding interceptors to a Server, Client, or Bus, this allows you to add them easily.
现在我们再来理一理CXF当中的Interceptor的关系.
InterceptorProvider 有 IN/OUT 两个 Interceptor的集合.
IN/OUT Interceptor有他固定的PhaseInterceptor.
某一个具体的PhaseInterceptor有他所对应的具体Interceptors.
关于CXF中的Interceptor可以参考我同事willem写的两篇文章：
http://willem.bokeland.com/blog/794/6089/2007/06/30/209717
http://willem.bokeland.com/blog/794/6089/2007/06/30/209718
————
参考文档:
<Pattern oriented software architecture volume2>
[CXF]CXF中的Observer模式应用
老感觉跟Observer模式对不上号…现在,我明白了,原来他是一个简化版的Observer模式.
先看下典型Observer模式
- Subject
- knows its observers. Any number of
Observer objects may observe a subject - provides an interface for attaching and detaching Observer objects.
- knows its observers. Any number of
- ConcreteSubject
- stores state of interest to
ConcreteObserver - sends a notification to its observers when its state changes
- stores state of interest to
- defines an updating interface for objects that should be notified of changes in a subject.
- maintains a reference to a
ConcreteSubject object - stores state that should stay
consistent with the subject’s - implements the Observer updating interface to keep its state consistent
with the subject’s
在对号入座前,先讲讲我们解决的这个问题场景.
我们要通过Transport这一层来传送Message(消息),我们假设以HTTP传输协议来做例子.
在CXF当中,有两个概念来对Transport进行了封装.
1: Conduit 可以理解为信息发送地,发送一条信息需要经过两个步骤:
1) conduit.prepare(message);
2) conduit.close(message);
2: Destination 可以理解为目的地.
接下来,我们来看看是怎么应用Observer模式的.
Observable: (对应的是Subject)
public interface Observable {
void setMessageObserver(MessageObserver observer);
}
MessageObserver: (对应的是Observer)
public interface MessageObserver {
void onMessage(Message message);
}
Conduit/Destination (对应ConcreteSubject)
ClientImpl/ChainInitiationObserver (对应ConcreteObserver)
可以说,在CXF当中应用的Observer模式有点不一样.
1) 我们可以从Observable类中看出,他只能注册一个,以往典型的Subject是支持多于Observer注册的.
2) 我们不能在Subject中看到他调用Observer的方法.实际上呢,他是隐藏于ConcreteSubject类当中.
这里我们来看一个ConcreteSubject( ServletDestination )
protected void doMessage(MessageImpl inMessage) throws IOException {
try {
setHeaders(inMessage);
inMessage.setDestination(this);
incomingObserver.onMessage(inMessage);
} finally {
if (LOG.isLoggable(Level.FINE)) {
LOG.fine("Finished servicing http request on thread: " + Thread.currentThread());
}
}
}
当你读CXF的源代码的时候,你会发现尽管Conduit也支持Observable,但是目前代码出好像还没有具体的应用.
其实这是一个简单版本的Observer模式,而且并不是一个one-to-many,而是one-to-one的.
———————–
参考文档:
http://www.dofactory.com/Patterns/PatternObserver.aspx
[CXF]CXF中重要概念: Service Model
这里,为什么会存在一个Service Model呢,主要是因为它可以有很多个front-end,比如说 JAX-WS,simple(POJO类型的), JS etc,所以基于这种可变的,我们需要抽象出一个稳定的,这样,CXF内部runtime的程序打交道都是跟Service Model,它不需要去管前端是有JAX-WS or POJO的.. 其实,我到是觉得可以把Service Model看做是meta data 管理器,因为如果你想要所有的元数据,比如说wsdl的信息啊等等的,你都可以从这取到.
Jeff@IT 