服务总线与直接数据库访问
使用 ESB 而不是直接访问数据库（通过 Hibernate 或 JDBC）有哪些优点？我知道你可以重用总线上的消息，但是你能不能将你的数据库访问代码打包成一个jar并将其分发到需要访问的不同系统（假设所有访问系统都支持Java）？
What are the advantages of using an ESB instead of directly accessing a database (via Hibernate or JDBC). I know you can reuse the messages on the bus, but could you not just package up your database access code into a jar and distribute it to the different systems that need access (Assuming all the accessing systems support Java)?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
ESB 向您的服务/数据库层添加了一个抽象层。您可以将 jar 分发到需要服务访问的所有应用程序，但如果服务更改其合同或需要更新业务逻辑怎么办？对于所有应用程序来说，更改其 jar 文件确实很困难。特别是在企业环境中，仅更改 jar 文件将需要大量的更改控制过程，这最终会增加更改的成本。
如果您使用 ESB，则可以在单个点添加删除或路由服务。因此，每次更改的成本将是最小的。也就是说，有几个缺点，例如 ESB 可能成为应用程序中的单点故障。因此，您需要有足够的冗余来应对任何故障。
ESB adds a layer of abstraction to your service/database layer. You could distribute jars to all the applications that require service access, but what if the services change its contract or business logic needs to be updated. It would be really difficult for all the applications to change their jar files. Especially in an Enterprise setting changing just a jar file would require a big CHANGE CONTROL PROCESS which ultimately adds on to the cost of change.
If you are using an ESB, adding removing or routing services could be done at a single point. Hence, the cost per change would be minimal. That said, there are several disadvantages such as ESB can become a single point of failure in your application. Therefore, it is required that you have sufficient redundancies in place to counter any failure.