敏捷开发和ESB

时间:2008-12-09 22:51:07

标签: .net ruby-on-rails business-logic esb middleware

我正在努力将我们的企业技术范式转变为敏捷开发。 这是一个艰难的过程,但我们几乎就在那里! :)

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

我的愿景是将用户的所有联系信息移至另一个数据库,将这些“个人资料”链接回MS SQL,以获取其历史记录和会计信息。我们将所有会计系统保留在桌面应用程序上,但是我们即将添加的功能将更多地依赖于Web,尤其是Ruby on Rails。

我想问题是:为什么ESB?有没有办法创建一个SOA而不用复杂的ESB系统。整个想法是K.I.S.S.无论如何。 SOA是否可以以允许桌面/ web / mobile为接口的方式创建,保持业务逻辑的功能(当然,某些功能必须在接口上实现,但要保持最低限度)。 ESB是否符合敏捷理念?我阅读和研究的越多,我就越少这么认为! :/

感谢您的输入人员!如果您需要我澄清,只需提出几个问题,我会尽我所能! :)

3 个答案:

答案 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在升级和替换方面可以非常灵活但是它会是矫枉过正? :)

豫ICP备18024241号-1