敏捷开发和ESB

Question

我正在致力于将我们的企业技术范式转向敏捷开发。这是一个艰难的过程，但我们快到了！:)

我们有用于数据库管理的遗留系统(过去是Access，现在移植到.NET和MS )，我们正在为我们未来的愿景开发一个框架。我们希望尽可能多地迁移到网络上。但我们希望将当前系统与“即将到来”的系统集成在一起。我们不会重叠任务和功能。

我的愿景是将我们用户的所有联系信息移动到一个不同的数据库，将这些“个人资料”链接回MS SQL，以获取他们的历史和会计信息。我们会将所有的会计系统都放在桌面应用上，但我们还会添加更多的功能，这些功能将严重依赖于web，尤其是Ruby on Rails。

我想问题是:为什么是ESB？有没有一种方法可以创建一个SOA，而不需要忙于复杂的ESB系统。不管怎么说，整个想法都是为了The。是否可以以允许桌面/web/移动设备作为接口的方式创建SOA，同时保留业务逻辑上的功能(当然，某些功能必须在接口上实现，但必须将其保持在最低限度)。那么ESB是否符合敏捷哲学呢？我越多地阅读和研究它们，我就越不这样认为！:/

感谢大家的投入！如果你需要我澄清，只要提出几个问题，我会尽我所能做到这一点！:)

Answer 1

一旦框架/基础设施就位，ESB就能很好地适应敏捷。您会发现，您可以分块创建一个新系统，将新部分与旧系统并行运行一段时间，然后逐渐关闭系统的旧部分，直到只剩下新系统，没有人会知道其中的区别

基本的SOA只定义服务而不是应用程序；ESB管理通道中的服务以隐藏端点，使升级和替换更加“敏捷”

Answer 2

我很快就学会了避免使用"ESB“这个术语，因为它非常过载，对不同的人意味着不同的事情(有时对同一个人也是不同的事情：-)

当然，关键的事情是问问自己，你真正需要的是什么。

将您的数据库包装为服务可能是一个明智的选择，特别是如果您有多个客户端用于此数据；您将不得不花费大量时间来考虑您的合同和作用域，但敏捷在这方面可以提供很大帮助。

现在的问题是如何调用这些服务，我认为您需要权衡客户端和服务更改的可能性以及您的系统将如何发展。

服务总线帮助屏蔽来自其客户端的服务(可以是其他服务)，并且这种“屏蔽”可以转发到位置、协议、格式、代码等。一些形式的服务总线还维护行程(需要调用什么以及何时调用)，但我通常不喜欢这种想法。

因此，我认为，你首先需要问自己的问题是，你需要从什么开始，以及你希望进行多少前期投资(并且可以证明)

例如，如果最初您对更多的点对点方法感到满意，那么您的客户端可以直接调用服务；在以后的阶段，随着服务的发展，您可以引入“中间人”来代理请求和响应(是的，如果愿意，您可以将其称为ESB )。

或者，您可以从一个基本的“中间人”开始，这样客户端就不会直接调用服务，而只是拥有您需要的功能，并根据需求表单扩展它的功能；它很可能从一个简单的转发机开始。

理想情况下，你应该建立在一个有很多内置功能的产品之上；如果你在MS堆栈上，BizTalk服务器是一个很好的匹配(但有它的学习曲线)

因此，如果这不是一个非常具体的答案，请道歉-但我想我的主要观点是，“ESB”不一定是一个夸张的词，它只是简单地归结为您在第一天就希望拥有的东西，而敏捷(和SOA)通过允许您逐步发展而不是任何像大爆炸一样的东西无疑是有帮助的。

(如果上面的任何事情都是胡说八道，或者只是有一点不清楚，那是因为房子里有新生的婴儿缺乏睡眠！抱歉:-) )

Answer 3

整个迁移过程就是我来到ESB的原因。但是，ESB的整个概念似乎过于复杂，无法解决涉及大约30,000个配置文件的问题！我们正处在一些指数级增长的边缘(达到几百万个配置文件)，也许开始一条新的道路将是最好的。将MySQL DB上的条目链接到MS SQL DB上存储的数据有多容易？我显然不想重复输入，但可能有一种比“整个”ESB更灵活的方法……我确实理解，具有ESB的SOA在升级和替换方面可以相当敏捷，但这会不会是一种矫饰？:)