论坛首页 Java企业应用论坛

企业内部子系统交互方案

浏览 9167 次
精华帖 (0) :: 良好帖 (1) :: 新手帖 (0) :: 隐藏帖 (0)
作者 正文
   发表时间:2013-07-05  

如题,该贴讨论企业内部繁多的子系统之间的交互方式及解决方案;

 

背景:公司正在处理一个项目,由于业务的需要分为N个子系统(都是内部子系统),子系统之间的交互很多,关系复杂;

 

-------------------------------我是华丽的分割线-----------------------------------------------------------

 

目前的解决方案:

我们暂定的实现方案是,通过jar包提供服务,jar中封装通信协议、以及报文的封装,保证了开发者的易开发性;

 

优点:

接口开发者、接口调用者均使用java代码(java类,参数有明确的类型,如XXXBean..),开发类似于本地调用,开发简单、方便;

 

缺点:

由于被调用接口的变更,需要变更参数,需要重新编译接口jar包,同步更新相关调用者的系统的jar包,维护麻烦;动态性差

 

 

大家可以发表自己的看法,以及相关的方案,谢谢!

 

   发表时间:2013-07-06  
使用服务框架和消息中间件
0 请登录后投票
   发表时间:2013-07-06  
我们用这个jersey
0 请登录后投票
   发表时间:2013-07-08  
天下有鹏 写道
使用服务框架和消息中间件


淘宝方案:但是淘宝没有使用ESB,而是用了自研的服务框架和消息中间件

可否具体一点讨论,谢谢
0 请登录后投票
   发表时间:2013-07-08   最后修改:2013-07-08
用dubbo试试,阿里开放框架
0 请登录后投票
   发表时间:2013-07-09  
服务化框架+1

服务化框架的核心功能:提供服务的发布和订阅、服务器地址动态路由和软负载均衡、至于客户端,不推荐用jar,维护起来太麻烦了
0 请登录后投票
   发表时间:2013-07-09  
用JAX-RS来实现,比如Apache CXF。

跟Web-services差不多。
0 请登录后投票
   发表时间:2013-07-09  
须等待 写道
服务化框架+1

服务化框架的核心功能:提供服务的发布和订阅、服务器地址动态路由和软负载均衡、至于客户端,不推荐用jar,维护起来太麻烦了


其实我也是赞同 服务化框架+1 的,目前我们也是按照这个模式去实现,只是实现的不够优雅;

客户端使用jar包的原因是规范客户端调用,避免由于开发人员不规范操作时造成的问题,但是现状确实是维护起来太麻烦了,频繁打jar包,打完jar包,调用段还得重启才能重新加载。
0 请登录后投票
   发表时间:2013-07-09  
kingsfighter 写道
须等待 写道
服务化框架+1

服务化框架的核心功能:提供服务的发布和订阅、服务器地址动态路由和软负载均衡、至于客户端,不推荐用jar,维护起来太麻烦了


其实我也是赞同 服务化框架+1 的,目前我们也是按照这个模式去实现,只是实现的不够优雅;

客户端使用jar包的原因是规范客户端调用,避免由于开发人员不规范操作时造成的问题,但是现状确实是维护起来太麻烦了,频繁打jar包,打完jar包,调用段还得重启才能重新加载。


我认为如果使用了服务化以后客户端的调用还是使用jar的话,那么服务化的效果就太弱了,我们平台也是有这样的问题,发布一个服务要由服务端封装一个客户端jar,用的时候到处拷贝,且不说管理起来很麻烦,一旦协议有变化要升级什么的,简直是痛不欲生

个人觉得客户端这一块应该用更轻量级的协议模式:比如就直接用json来封装消息,你觉得这样可行么?
0 请登录后投票
   发表时间:2013-07-09  
如果是异步交互,建议消息中间件;
如果是同步交互,有两种风格:
1. RPC风格,包括Web Service,自定义RPC协议等;
2. RESTful风格,将所有服务抽象为资源;

第一种的缺点是,接口不容易改变,增减参数会影响服务端和客户端;
第二种的缺点是,可能需要更高的抽象能力,但是很多变化可以在资源内部进行,接口不受影响。
0 请登录后投票
论坛首页 Java企业应用版

跳转论坛:
Global site tag (gtag.js) - Google Analytics