我正在考虑标准软件系统的几种架构选项。也许你想分享你的意见。
系统： 我们有一个带有底层数据库的业务逻辑组件。直到今天，这个逻辑组件仅由一个客户端使用，因此UI和逻辑和数据层都在一个可执行文件中。 （工具A）
现在，该程序具有如此酷的功能，另一个已经存在的工具应该使用它（工具B）。工具B还应使用（或至少显示）工具A的一些数据，但它也保留自己的数据存储。我们的解决方案很简单： 我们拆分了工具A.业务逻辑获得了一个服务接口（可能是Web服务，RESTful与否）。然后工具B可以访问工具A的业务逻辑，获取数据，执行计算等等。
现在，如果工具B显示工具A的数据，那么如果它会被通知工具A中的数据更改将会很好。我们的服务界面很好但是单向的故事（如果你不做这样的技巧）保持异步调用打开直到事件发生）。
我们看到了几个选项：
一个。工具B也获得服务接口。当它启动时，它会向工具A注册，工具A会将更改事件发送到工具B.
湾工具B轮询工具A的服务以进行更改。
℃。我们介绍了一个中间件，其中工具A正在发布事件，所有客户端都可以订阅这些事件。
我们不喜欢b）。太慢了，工具A需要一种方法来确定每个客户的变化。 c）具有引入新组件的开销。 a）将这两个工具紧密结合在一起。
更多信息： 我们将在一台机器上拥有一个中央数据存储（+我们的业务逻辑组件）。在其他机器上可能是客户端（最多20个，比如说。不是100，不是1000，不是10000）。 它是来自一个供应商的系统。我们不必为许多想要使用事件的第三方工具做好准备（这将是解决方案c的强有力指标））。
问题： i）除了a）-c）还有什么其他选择？ ii）你会选择哪种方式？为什么？