我正在努力将我们的企业技术范式转变为敏捷开发。 这是一个艰难的过程，但我们几乎就在那里！ ：）
我们有用于数据库管理的遗留系统（曾经是Access，现在移植到.NET和MS SQL），我们正在为我们未来的愿景开发一个框架。我们希望尽可能多地迁移到网络上。但我们希望将当前系统与“即将到来的”系统集成。我们不会重叠任务和功能。
我的愿景是将用户的所有联系信息移至另一个数据库，将这些“个人资料”链接回MS SQL，以获取其历史记录和会计信息。我们将所有会计系统保留在桌面应用程序上，但是我们即将添加的功能将更多地依赖于Web，尤其是Ruby on Rails。
我想问题是：为什么ESB？有没有办法创建一个SOA而不用复杂的ESB系统。整个想法是K.I.S.S.无论如何。 SOA是否可以以允许桌面/ web / mobile为接口的方式创建，保持业务逻辑的功能（当然，某些功能必须在接口上实现，但要保持最低限度）。 ESB是否符合敏捷理念？我阅读和研究的越多，我就越少这么认为！ ：/
感谢您的输入人员！如果您需要我澄清，只需提出几个问题，我会尽我所能！ ：）
答案 0 :(得分：3)
一旦框架/基础架构到位，ESB就能很好地适应敏捷。你会发现你可以分段创建一个新的系统，与旧系统并行运行新的部分一段时间，然后逐渐关闭系统的旧部分，直到只留下新系统，没有人会永远都知道差异
基本SOA只定义服务而不是应用程序; ESB管理通道中的服务以隐藏端点，使升级和替换更加“敏捷”
答案 1 :(得分：1)
我很快就学会了回避“ESB”一词，因为它非常超负荷，对不同的人来说意味着不同的东西（有时候对同一个人来说不同的东西： - ）
当然，关键是要问问自己实际需要的是什么。
将数据库作为服务包装可能是明智的选择，特别是如果您有多个客户端用于此数据;你将不得不花费大量时间考虑你的合同和范围，但敏捷在这里可以大大帮助。
现在的问题是如何调用这些服务，我认为您需要权衡客户端和服务更改的可能性以及系统的发展方式。
服务总线有助于屏蔽来自其客户端的服务（可以是其他服务），这种“屏蔽”可以转发到位置，协议，格式，代码等。 某些形式的服务总线也保持行程（需要调用什么，何时调用），但我一般不喜欢这个想法。
所以 - 我认为你首先需要问自己的问题是，你需要从什么开始，以及你希望做多少前期投资（并且可以证明）
例如，如果您最初对更加点对点的方法感到满意，那么您的客户可以直接致电该服务;在稍后阶段，随着服务的发展，您可以引入“中间人”来代理请求和响应（是的 - 如果您愿意，可以将其称为ESB）。
或者你可以从一个基本的“中间人”开始，这样客户就不会直接调用服务，而只具备你需要的功能，并根据需求扩展它的功能;它可能从一个简单的转发机器开始。
理想情况下，您将构建在具有许多内置功能的产品之上;如果你在MS堆栈上，BizTalk Server是一个很好的匹配（但它有学习曲线）
所以 - 如果这不是一个非常具体的答案，请道歉 - 但我想我的主要观点是“ESB”不一定是一种矫枉过正，它只是归结为你希望在第一天拥有的东西，并且敏捷（和SOA）绝对有助于你逐步发展，而不是像任何大爆炸一样。
（如果上面的任何内容完全是胡说八道，或者只是有点不清楚，这是由于在家中出生的新生儿睡眠不足！道歉:-)）
答案 2 :(得分：0)
整个迁移是让我进入ESB的原因......但是ESB的整个想法似乎很复杂，可以解决涉及大约30,000个配置文件的问题！我们正处于一些指数增长的边缘（到几百万个配置文件），并且可能从一条新路径开始将是最好的。将MySQL数据库上的条目链接到存储在MS SQL DB上的数据有多容易？我显然不希望双重进入，但可能有一种比“整体”ESB更敏捷的方式......我确实理解带有ESB的SOA在升级和替换方面可以非常灵活但是它会是矫枉过正？ ：）