在XXX产品框架中，我们根据产品发展规划和业务领域需要，使用基于JMS技术，通过应用WEBService，开发了消息中心中间件（简称MC）。通过消息中间件，我们可以实现各系统间的异步数据交换和事务处理、执行不需前台使用人员干预的如后台业务和数据同步工作，也可用来处理一些受到安全和其它一些因素制约，导致无法直接通过数据库或应用系统进行处理的受限业务。
消息中心中间件，包括消息总线和消息客户端两部分：消息客户端负责业务类消息实例的产生、发送消息实例到消息总线、接收从消息总线转发而来的消息实例、将收到的消息实例交由其载体应用系统进行与之对应的业务处理等活动；消息总线负责接收从消息客户端产生并发送而来的消息实例、消息重建、根据消息配置进行消息实例重建,将重建后的消息实例转发至对应的消息客户端等活动。
消息客户端与XXX各应用系统集成在一起，并通过应用系统开放WEBService端口进行消息的发送和接收等，从而避免单独部署和发布所带来的困难和额外资源消耗。消息总线可单独部署，也可和消息客户端一样，与XXX应用系统集成部署，在XXX产品框架下，有且只需要一套消息总线即可满足需要。消息配置中心，其作用包括配置和管理消息中心各组成部分的部署方式和访问信息，以此将消息中心各部有机的联系起来；同时，各消息业务应用，也使用配置文件进行配置化管理，并与消息中心各组成部分进行关联配置，从而形成一个统一且开放的整体；其它的如性能优化处理、日志记录等也在配置中心进行配置和管理。
在消息中间件V1.0版本开发完成后，我们即将其投入实用。在XXX各分子系统这近一年时间的运行和使用过程中，消息中心很好的完成了预定任务，其可靠性、可扩展性和适用性得到很好的验证。以此为据，通过使用消息中心，开发出基于消息中心的客户化应用和业务活动也在持续的增加中，到现在为止，已经有包括网络检测、信息同步、配置更新、电子目录树更新、权限同步等诸多应用是基于消息中心应用开发，并很好的使用在XXX各分子系统的测试和内网正式环境中。
在XXX系统正式接入外网后，通过对业务进行跟踪，发现外网用户（系统）所产生的消息实例无法正常的到达指定的消息总线及消息客户端。最主要的体现是权限同步消息应用无法正常完成的问题，导致外网用户权限未得到及时更新。对此过程中消息中心所涉及部分进行分析发现：所有的权限同步消息实例在产生后，不能正常的将此消息实例发送至消息总线，分析失败原因，只有一种，那就是”connect time out”。从此信息可看出，应该是外网系统所发出的消息无法通过WEBService送达指定的消息总线接收端所至。但从内网发出的同一类消息，其发送和接收却又都是正常的。
1、先分析我们系统的整体部署方式，如下图所示：
根据外网用户可正常登录和访问系统，并可通过系统准确及时的发出执行指令操作，完成其所需的业务活动来看，网络方面和系统和硬件方面都不存在问题。
2、在外网环境下，直接进行各消息客户端和消息总线的服务的检测，所发请求都能够正确的到达指定目标，WEBService的响应也正常且正确，也就是说，各应用系统加载的消息服务运行也正常。
3、根据本次检测需要，另行开发消息中心专用检测工具，为本次和今后的行的消息中心检测和问题分析，作好更充分的准备。
4、通过检测工具，发现，外网环境下，消息客户端和消息总线之间不能够联通，从而找到问题所出：即不知是何原因，导致外网消息与外网的消息总线间联络不通！
5、对外网用户消息产生和发送的过程和逻辑实现进行分析：我们发现，为了满足应用系统外网访问的需要，我们对消息系统配置信息中服务地址的ServerName进行了伪处理，即在运行时，根据用户浏览器的请求头来判断用户使用的是哪一个WEB服务器地址，并将此地址动态的代替消息配置中的各ServerName信息，从而保证各使用用户只能够访问其指定的WEB服务器，从而避免因WEB服务器的不匹配而影响其访问速度、处理效率等故障的发生。此方式已在我部门多套同时服务于内外网络的系统中得到可靠的验证。
那么，会不会因为ServerName在动态解释过程中，因多并发情况下，因后访问者将前访问者的ServerName改写而导致错误的解释，即将不同网络用户的消息地址进行张冠李戴而导致消息无法正常发送呢？
分析消息中心各部分WEBService生成和使用机制：因系统的并发性要求较高，在高峰期其在线用户可达3000人，并发用户在300以上，且系统稳定性要求极高。为提高系统的性能和稳定性，在系统启动时即将消息中心各部的WEBService连接进行创建和缓存，以提升消息中心资源利用率，并提升其访问性能。
当存在多网络用户访问时，可能因消息中心存贮的WEBService连接并不是其用户所使用的那个网络的WEBService服务地址，此时，消息肯定是无法送达至此用户所需要的目标的。因此，报”connect time out”错误就成必然的了。
既然已找到问题的可能原因，我们立即进行着手分析和解决：根据部署要求，我们对对消息服务连接服务进行了升级，即将服务请求进行分类处理和实现，并在消息配置中对所使用的部署方式、代理实现后，交由测试人员进行部署和测试。
测试结果：令人失望的是，此问题依然存在！在通过外网WEB服务器访问的系统，其消息还是无法发送至消息总线。由此得知，此种分析方向是错误的！
至此，好像已经走入了死区,能想到的方式都已经想到了，但问题到底出在哪呢？
在一次与同事聊天的过程中，忽然想到一个问题，那就是：我们的消息的产生和应用都是由应用系统和与之集成在一起的消息客户端自动产生和处理的，此过程中完全不受人工干预和影响。而应用系统是部署在应用服务器中，WEB服务器仅是用来处理用户的HTTP请求à将此请求转发至对应的应用服务器后à将应用服务器的响应返回给用户。
在此过程中WEB服务器并未对用户业的http请求进行过任何业务上的处理！那么，问题会不会出在WEB服务器端呢？检查一下消息中心的配置不管是使用ServerName还是写死IP和域名，我们的消息中心配置的地址都是指向WEB服务器。而在应用系统发现消息时，其所在位置是应用服务器。而应用服务器是无法直接访问部署于外网IP中的WEB服务器的，当然，消息无法发送至目标就成为必然了。
既然已经找到问题，那就动手，将消息中心的配置信息指向应用服务器后，重启应用系统后测试，问题果然解决！
通过应用服务器进行后台自动处理的，进行HTTP或WEBService活动，其目标必需是它能够访问的有效地址！这个问题在以前也曾经碰到过，只是由于时间隔得太久，且这些场景应用出现太少，而导致再次发生。
1、 基于应用系统或后台自动触发的一些业务逻辑，如其中存在着系统间相互访问或远程调用等，必需以应用系统自身为根，进行连接测试；通过外层包装或其它代理，进行访问时，必需先剥离过外层包装或其它代理后，再进行连接测试，并以测试结果，作为决策的依据！此举适用于各类系统的架构设计和逻辑实现过程中。
2、 基于中间件产品应用，及时开发与之配套的检测和使用工具，是一件必不可少的工作，此举将为后期的实施和问题分析节省大量的工作量。