为什么要对接改造？
我们公司是做增值税管理系统的，增值税系统涉及到开发票的业务，需要与不同的供应商对接开票接口，供应商提供的开票接口，包括四种：A1供应商有两种，第一种是开票服务器，第二种是税盒 A2供应商也是一种是开票服务器，一种税盒。
客户有用税盒开票的，也有用开票服务器的，各种情况都有
我们的产品有两个开票历史版本，一个历史版本是 有一个WEB和一个开票客户端
如图：
每一次要开票的数据，都要先经过web端处理完之后，存到数据库里面，然后再打开开票软件，进行开票
这样的缺点：1.操作繁琐，2.客户要装很多额外的软件
后来我们进行了第一次改造，就是借助Active 控件与本地机器通信，如图：
这样的话，客户不用再像历史一一样，需要安装一个客户端软件进行复杂的操作，但是active控件是有缺点的：一个是只有IE用，一个是配置复杂，测试人员因经常配置不好active控件，导致测试效率问题
现在的话，公司专门针对于这个问题，开发了一个稳定，不受浏览器限制，可以共享，集群开票的基础服务性软件，简单结构图如下：
这样的话，调用端不用，再像历史二那样，安装activce，不受浏览器限制，可以共享开票机器
- 调用者请求业务服务，WEBService接受到请求会先对要传递的数据进行校验
- 校验成功，给调用者一个受理信号，然后将要处理的业务请求，发送到MQ消息对列里面去，等待任务被处理
- WebSocket会根据登录的开票机客户端，查找到要请求的开票机器号，并将数据发送到开票客户端
- 待开票客户端完成，开票的操作之后，将结果返回到调用方
- 最后，调用方，将处理完的结果，回写给调用方
基于历史版本，我要做的就是把原来历史二的开票方式，给替换成远程消息队列的模式。
要考虑到的一些点如下：
- 原来有本地，调用active开票的，也有远程开票
- 有A1厂家开票模式，也有A2厂家开票模式
- 要提供回调服务，要考虑异步回写
- 要方便以后的修改
- 要可以执行不同的开票动作
设计了如下的改造结构：
用户可以针对于不同的业务进行回写服务的扩展和开票服务的扩展
可以添加不同的厂商开票方式
兼容原来的模式，前端只需要向后端传递数据，告诉执行什么动作
就可以按既定的业务模式执行业务了