使用COM+实现校园一卡通与其他系统的协作

1 校园一卡通系统

校园一卡通系统是指基于校园网，采用先进的、成熟的非接触式IC卡实现数据采集并应用于实际的校园个人数据管理应用平台。它集收费管理、证件管理、教务管理、师生考勤、食堂管理、机房管理等多种功能将学校各个系统连成一体，动态掌握每一持卡人情况，不但满足了学校不同管理层次的需要，而且解决了不同规格的各种管理卡的兼容问题，为高校广大师生的日常学习和生活带来方便和快捷，同时丰富和强化了高校数字电子化建设。

但一卡通系统并不是一个孤立的系统，在运行时需要与财务管理、学生管理、后勤管理等软件协同运作，如在参考文献[2-3]中就对财务管理系统、图书馆系统进行了协同。因此需要一卡通在设计时需要涉及到应用程序级别的事务处理， 例如，使用一卡通进行购物后需要在一卡通系统与会计电算化系统中同时记录相关的操作，这种记录要么都成功，要么都失败，不允许出现一个成功另一个失败的情况。另外由于一卡通系统本身的特性，涉及的用户多，在使用中常大量出现并发操作，如果对这些并发处理不到位，那么将会出现如死锁、幻读、脏读等现象发生。这一点在参考文献[4]中采用了多线程的方式进行处理。

2 COM+中间件

COM+，即组件对象模型增强。是微软开发的开放的组件标准，它有很强的扩充和扩展能力。COM+在COM/DCOM的基础上提供了事务处理、安全机制、队列服务、负载平衡、内存数据库、事件服务等机制。

COM+中的事务通过MTS(分布式事务协调器)完成，MTS允许开发人员创建轻量型的控件，从而使得开发人员能够将精力集中于分布式上的事务处理中。例如一卡通在图书馆进行图书欠款交还时，产生了在一卡通系统与财务系统都要增加记录的分布式事务，该事务可能涉及不同的系统与数据库。由于内置了MTS，COM+就可以很轻松的实现该分布式事务。

3 普通环境下事务的解决

假设一卡通系统中有WriteRecordA方法。该方法在一卡通系统发生支付行为时增加记录的操作，而财务系统中有WriteRecordB的方法，用于更新某个用户的账户。当发生支付行为时分布式事务用伪码表示。

4 使用COM+解决一卡通系统中的事务

上述的伪码无法直接实现。原因在于不同系统中的相关方法无法通过硬编码的方式将相关操作封装在一个处理函数中，只能采用可配置的方式动态注入。而COM+的事件机制可以实现这一点。COM+中的事件机制类似于现实中的邮件订阅，读者可以自行订阅感兴趣的邮件。对于COM+事件的订阅只需在“我的电脑”→“管理工作”→“组件服务”中进行配置。

为实现消息订阅，一卡通系统中COM+定义时需要向外界公开订阅的接口，接口的定义如下：

在该伪码中定义了一卡通类，由于使用了TransactionOption.Required的特性，该类将被运行在一个事务环境中，该事务即为分布式事务的根，如果有其他系统订阅了如结算、刷卡等事件，那么该事件发生时事务也会被传到其他系统中，并通过分布式协调器进行分布式事务的处理。到此，一卡通系统就向其他系统公开了协同工作的接口，并将可能的业务包含于分布式事务中。

其他系统为实现与一卡通系统的交互，需要使用IMyTransactionEvents的接口，伪码表示如下：

由于一卡通系统定义必须运行在一个事务中，因此当具有TransactionOption.Supported属性的用户接收到相应事件后，也将在同一个事务中运行Action方法，从而通过分布式事务协调器的方式实现了对分布式事务的处理。

5 结论

一卡通系统在与其他系统要实现协同工作，需要解决分布式事务的处理。将一卡通系统中的相关业务逻辑封装在COM+组件中不仅可以完成一卡通系统的构建，而且还能够很好的解决在协作过程中出现的分布式事务的处理。