问题的提出
呼叫处理系统（CPS - Call Processing System）需要和接入点（AP-Access Point）进行通信（还有其它一些设备，但本文只关注AP），总之CPS是一个信息交互的核心。两个设备之间有事先定义好的严格而精确的接口定义，保证两个设备如果在完全遵循接口定义的情况下进行开发，即使在不同项目组，最后也能无缝地整合。为了测试和验证CPS系统，又有一个模拟器（Simulator）专门用来模拟和CPS交互的外围设备（AP和其它设备），Simulator不需要有复杂的消息处理，只需要根据用户的定制或者上下文发送相应的消息即可，所以Simulator和CPS需要遵守相同的接口义。
 
我在CPS项目组，而Simulator却是在国外的某个项目组。现在由于业务的需要，CPS和AP之间的消息接口有所改动，所以CPS和Simulator都需要根据这一接口进行更新。CPS的开发工作已经完成，下一步就要进入集成测试。但我们现在只能等待与之遵循相同消息接口的Simulator的交付使用。由于根据经验，集成测试过程中可能会遇到很多问题，为了进一步赢取时间，只能从自身的角度看看有没有更好的办法了。
 
解决方案
    CPS和AP之间的消息接口发生了改变，而在Simulator这边也没有什么大的突破，所以只能转而考虑，是否可以在CPS内部做一些动作。
使用旧的Simulator，它只能接收和发送旧的消息，而现在的CPS是支持新的消息，所以考虑在新的CPS和旧的Simulator之间做一个转换，就是把接收到的从AP发来的旧的消息转换成新的消息发给CPS，而把CPS要发给AP的新的消息转换成老的消息发给AP。这个类似于Adapter的功能。
进一步优化的解决方案
    上面的解决方案的问题在于，需要改变现有CPS这边的实现代码，特别是消息接收和发送部分。为了减少这种耦合性，最大程度地减少对现有系统的影响，又做了如下的优化：

1.    现以旧的CPS和旧的Simulator做第一步的准备。现有CPS在一个固定的TCP端口侦听AP的连接，原先Simulator会模拟AP去连接CPS侦听的端口，现在另外有个一个与CPS和AP都三层网络可达的IP（也可以是Simulator或者CPS上的一个IP），起一个Adapter进程监听与此IP（Adapter进程的所在的主机根据IP的选定而确定）的固定侦听端口（与CPS同一个端口），这时的Adapter进程对Simulator来说就已经是CPS了，所以Simulator中的原来配置CPS的IP的地方，现在全部用Simulator侦听的那个虚拟IP来代替。Adapter还需要完成的工作是，当Simulator有连接请求时，它需要接受连接，并且同时向CPS发起相同的连接，保证这两个连接的消息是互相转发的，Adapter只是做了一个中转的作用。到此，如果测试结果显示Simulator和CPS之间的通信完全和加入Adapter之前无差异，说明Adapter现在是完完全全实现了中转消息的功能了。

2.    这一步就是要实现有差异的消息的转换了，没什么难点了。在Adapter中截取消息接口发生改变的消息，对消息做相应的转换（根据具体的接口定义），然后沿着原来的方向发送出去。这一步才是真正实现了Adapter的功能。