在设计原有系统的时候，其中有一个模块式消息处理模块，我们的命名是消息服务器，使用消息服务器的名称应该是更合理的，因为设计消息转发的消息模块使用的是activeMQ
一个java JMS标准实现的开源MQ消息服务器。
开始的时候我们的设计有一下的考虑：
1，自己制定消息的格式，在服务器进行实现，并转发，客户机链接消息服务器并进行接收 。因为警情消息的格式是较多，同时数据的大小也相对是比较多的，是串口接收的数据，同时对于多客户的链接，多线程的处理，相对来说压力是比较大的，没有好的处理方式，服务器容易出现故障影响系统的稳定性，最重要的是对于多坐席端的数据进行实时的转发，以及坐席端对于数据的实时更新，并通知其他的坐席，对于自己进行实现是比较费事的。
2，使用一些相对好的开源产品，对于这种实时性的警情数据转发处理，同时是基于网络的应用使用消息驱动的架构是比较方便的，同时对于系统的维护也是比较方便的。
在以上的基础上，我们使用了avtiveMQ ，当时也有另外一个可选的方案是使用XMPP这种可以进行即时聊天应用搭建的协议，但是因为可选的稳定的开源产品较少，并且使用起来不太符合系统的要求。
现在想起来使用activeMQ是一个较好的解决方案：
1，稳定，故障率低。
2，消息的处理性能很好。
3，支持的消息处理方式较好 p2p的以及p/s的模式。
4，较多的客户端API支持 ，几乎包含当前主流开发语言。
5，可也使用java的跨平台的特性，我们实际部署的时候可以使用免费的linux系统进行部署。
6，同时对于需要进行使用java 开发jsp 网页产品或者PHP ，asp.NEt 网页产品是可以直接进行使用我们无需考虑消息格式的处理，因为activeMQ帮我们进行转发。
7，同时可以使用集群的功能，当消息较大，或者处理不及时，单机崩溃，可以转入其他的服务器。使用简单的配置即可。
另外一个可选的方案是使用AMQP （高级消息队列协议）。MQP的原始用途只是为金融界提供一个可以彼此协作的消息协议，而现在的目标则是为通用消息队列架构提供通用构建工具。因此，面向消息的中间件（MOM）系统，例如发布/订阅队列，没有作为基本元素实现。反而通过发送简化的AMQ实体，用户被赋予了构建例如这些实体的能力。这些实体也是规范的一部分，形成了在线路层协议顶端的一个层级：AMQP模型。这个模型统一了消息模式，诸如之前提到的发布/订阅，队列，事务以及流数据，并且添加了额外的特性，例如更易于扩展，基于内容的路由。
同时开源的产品也是较多的，比如RabbitMQ 同样可以使用跨平台，客户端API也较丰富，对于坐席端的实时警情处理，并及时的通知其他坐席端的使用另外的方案是.net的 signalr 这个框架，可以在微软的channel 9 中查找相关的演示，可以进行实时的游戏处理，确实是很不错的。而且提供了JS 客户端的API可以方便的在网页中处理。可以在我的博客中看到相关的文章。
在消息的传送格式上，以前的处理方式是传送对象，确实是比较方便的，但是如果是不同的实现语言，传送的对象的处理是有问题的，由于开发语言的不同，现在的一种想法是使用文本的消息格式，但是不是一般得文本而是大家比较熟悉的JSon格式应该会比较方便，服务器进行序列化，客户机进行反序列化，这样可以达到大家都能方便处理，同时不需要考虑使用的开发语言。
在实现的基础上使用消息中间件的开发模式，在实际的应用开发中是较多的，同时也是一种较好的解决方案。后续将粘贴相关的实现代码，并讨论重新的处理方式和实现代码。