我们的系统由一个B/S网站和一套C/S应用组成,网站与C/S服务器端连接 
现在为了提高负载,也为了适应各地网络环境的差异,要在各地机房部署多个C/S服务器端,分别处理不同地域的C/S客户端请求,而网站需要与各个C/S服务器端通讯,也就是会形成一个网站服务器对多个C/S服务器端的架构 
网站服务器与C/S服务器端通讯频繁程度一般,C/S服务器端之间互相无通讯,绝大多数情况下都是网站服务器通知C/S服务器端进行某项操作,少数情况要返回一个结果。C/S服务器端只是定时向网站服务器报告自身的负载情况(其实也可以由网站服务器定时主动询问) 
也考虑了WebService,但感觉还是应该采用消息中间件,要求是:免费(开源不要求)、可支持Java(JMS)和C++的客户端——这是指消息中间件客户端,这在我们系统里就是C/S应用的服务器端了,我们暂时是用Java写的,未来可能提供C++写的。 
查了不少资料,似乎ActiveMQ不错,其它JBossMessaging也有人推荐,另外也看到一个同是Apache的Qpid,但版本还是0.5。各位有什么推荐的吗?

解决方案 »

  1.   

    直接用报文方式可能快点,WebService转一次效率可能低一点,如果没有条件,不如直接传xml文件可能更效率点
      

  2.   

    现在的问题不在于消息的格式,而在于怎么把消息传过去,你说传xml文件,那采用什么网络协议或者技术?socket?FTP传文件?
      

  3.   

    学习,我只知道Web Service中可以用HTTP或者WSDL,还是需要不断学习啊我
      

  4.   

    ActiveMQ 支持 C++ 端调用?
    或者如果在路由方面没有复杂的要求,用数据库做中介也不错。
      

  5.   

    如果要效率的话,就使用 Socket 长连接,这种方式的通信效率是很高的。
      

  6.   

    不明白为啥要用消息中间件来提高负载,
    中间件本身就会成为一个瓶颈。让所有网站发消息到F5 balance loader,它计算每个C/S服务器端的负载,
    然后它会把消息转送到负载最少的服务器。至于什么协议么,http啦,
    简单。
      

  7.   

    ActiveMQ-----用oracle数据库直接用Oracle AQ
      

  8.   

    遇见同样的场景XML观点 和  socket长连接观点,能再多说下吗?activeMQ 我用来做任务调度这玩还能通信用吗?
      

  9.   


    搜索引擎都没找到关于“F5 balance loader”的明确说明,能给个资料链接吗?
    我们的系统有点特殊,在C/S客户端从网站服务器获得C/S服务器端的IP地址后,就直接与该IP的C/S服务器端通讯了,不再需要网站经过消息中间件中转数据,使用消息中间件不是为了增加负载,而是为了让网站服务器和多个C/S服务器端通讯,当然这种通讯方式有很多种,比如直接Socket,或者WebService、RMI之类的,所以在咨询这种架构下,网站服务器与多个C/S服务器端之间采用什么通讯技术比较好
    Socket其实我是最先排除的,太底层了,很多特性需要我们自己写代码,基本上消息中间件的最基本的核心逻辑就需要我们实现一遍,比如消息队列。从我们的需求特征来说,消息中间件是最合适的
      

  10.   

    F5是一个硬件的网络负载均衡器。可以将一个局域网内的网络设备进行负载均衡。
    感觉上你也不必要提供消息中间件,因为你就是为了找一个代理,将传入的信息根据IP指定到相应的服务器上。建议你先与一些网络服务提供商或网络硬件提供商沟通一下。这样效率无疑是最高的。 除非必须有自定义的应用,否则真是不必要再部署应用了。
      

  11.   

    如果是C/S服务端发起的向Web服务器端的通知调用,用WebService最合适,但是楼主的需求里是有Web服务端向C/S服务端的通知调用,而且C/S服务端有多个,这样如果用消息中间件的话,岂不是多个C/S服务端需要对应多个消息队列?再加上Web服务端的消息队列,这么多的队列管理起来很麻烦(一般的开源消息中间件可能没有像WebSphere MQ那样的消息队列集群的概念)。如果所有C/S服务端和Web服务端都对应唯一的消息队列,那起码得要一台消息服务器,且各个C/S服务端和Web服务端都需要读写消息服务器,容易造成通讯瓶颈个人认为如果对实时性要求不高的话采用数据库接口表集成的方式最方便,Web服务端和C/S服务端都往接口表中插入数据,同时定时读取针对自身的数据,读取到后立即处理我的QQ:121102723,有空多交流交流
      

  12.   

    为什么不采用RMI?考虑到移植问题?
      

  13.   

    webservice 用来传输一般的文件还可以,大文件建议用socket
    用webservice 用的是HTTP传输方式,好处是可以穿防火墙。当调用webservice 返回的参数类型比较多的时候,可以采用xml打包方式!
      

  14.   


    QQ已经加你。
    数据库接口不可行,我们的C/S服务器端位于全国各地,地理距离可能很远,有的可能在电信机房,有的可能在网通机房,数据库放哪都不合适。
    我对消息中间件没有深入研究,据我所知,我们这种情况似乎只需要两个消息队列,一个是web服务器端的,一个是C/S服务器端的,后者应该可以做成一种广播方式的。不过消息服务器是肯定需要的了,可以跟web服务器端放一台机器上。回后面一位朋友的话,RMI的话,其实也是考虑到C/S服务器端可能会有C++版的,也因为这个原因,采用WebService就也不太合适了,由于web服务器端需要主动通知C/S服务器端,如果采用WebService,那C++版的C/S服务器端要提供一个WebService服务可就麻烦了
      

  15.   

    jms 和 webservice 都可以实现,但是在局域网建议使用jms 在外围网就要使用webservice了。