好的我在哪里工作,我们在过去的几十年中编写了相当多的系统.
系统多种多样,多个操作系统(Linux,Solaris,Windows),多个数据库(oracle,sybase和mysql的几个版本),甚至多种语言(C,C++,JSP,PHP和许多其他语言)都是用过的.
每个系统都是相当自治的,即使以将相同数据输入多个系统为代价.
管理层最近决定,我们应该调查让所有系统愉快地互相交流和共享数据所需的内容.
请记住,虽然我们可以对任何单个系统进行软件更改,但任何一个系统(或更多)的完全重写都不是管理层可能会接受的.
这里几个开发人员的第一个想法是直截了当:如果系统A需要来自系统B的数据,它应该只连接到系统B的数据库并获得它.同样,如果需要提供B数据,则应将其插入B的数据库中.
由于使用的数据库(和版本)混乱,其他开发人员认为我们应该有一个新的数据库,结合所有其他系统的表,以避免不得不兼顾多个连接.通过这样做,他们希望我们能够整合一些表并摆脱冗余数据输入.
这是关于我对整个烂摊子的看法.
使用数据库作为系统通信手段的整个想法对我来说很有趣.业务逻辑必须放在多个系统中(如果系统A想要向系统B添加数据,它在插入之前更好地理解B关于数据的规则),几个系统很可能必须进行某种形式的数据库轮询才能找到对数据的任何更改,持续维护将是一件令人头疼的事情,因为对数据库模式的任何更改现在都会传播到多个系统.
我的第一个想法是花时间为不同的系统编写API /服务,一旦编写就可以很容易地来回传递/检索数据.许多其他开发人员认为这比使用数据库过多而且工作量大得多.
那么让这些系统相互通信的最佳方法是什么?
整合不同的系统是我的日常工作.
如果我是你,我会尽力避免直接在系统B中访问系统A的数据.从系统B 更新系统A的数据库是非常不明智的.与使业务逻辑如此分散的良好实践完全相反.你最后会后悔的.
中央数据库的想法并不一定糟糕......但所涉及的工作量可能在从头开始重写系统的一个数量级内.这肯定不是我想要的,至少在你描述的形式.它可以成功,但它更加困难,并且比点对点集成方法需要更多的纪律.很有趣的是听到它与"牛仔"方法一样,只是将数据直接推送到其他系统中.
总体而言,你的直觉似乎很好.有几种方法.你提到一个:实施服务.这不是一个糟糕的方式,特别是如果您需要实时更新.另一个是一个单独的集成应用程序,负责改组数据.这是我通常采用的方法,但通常是因为我无法更改我正在集成的系统以询问所需的数据; 我必须推送数据.在您的情况下,服务方法并不坏.
对于第一次参与系统集成的人来说,我想说的一件事情可能并不明显,那就是系统中的每一段数据都应该有一个权威的真实点.如果数据是重复的(并且是重复的),并且副本彼此不一致,则必须认为该数据的真实点的副本是正确的.没有其他方法可以在没有复杂性尖叫的情况下以指数速率整合系统.Spaghetti集成就像意大利面条代码,应该不惜一切代价避免.
祝好运.
编辑:
中间件解决了传输问题,但这不是集成中的核心问题.如果系统足够接近,一个应用程序可以直接将数据推送到另一个应用程序,它们可能足够接近,一个应用程序提供的服务可以由另一个直接调用.在你的情况下,我不建议使用中间件.您可能会从中获益,但复杂性会增加.您需要一次解决一个问题.