敏捷开发和 ESB
我正在致力于将我们的企业技术范式转变为敏捷开发。 这是一个艰难的过程，但我们已经快成功了！ :)
我们有用于数据库管理的遗留系统（以前是 Access，现在移植到 .NET 和 MS SQL），并且我们正在为我们的未来愿景开发一个框架。 我们希望尽可能地迁移到网络。 但我们希望将当前的系统与“即将到来的”系统整合起来。 我们不会重叠任务和功能。
我的愿景是将用户的所有联系信息移至不同的数据库，将这些“个人资料”链接回 MS SQL 以获取其历史记录和会计信息。 我们会将所有会计系统保留在桌面应用程序上，但我们即将添加更多功能，这些功能将严重依赖于网络，尤其是 Ruby on Rails。
我想问题是：为什么是 ESB？ 有没有一种方法可以创建 SOA，而无需热衷于复杂的 ESB 系统。 无论如何，整个想法就是亲吻。 SOA 能否以允许桌面/Web/移动作为界面的方式创建，将功能保留在业务逻辑上（当然，某些功能必须在界面上实现，但将其保持在最低限度）。 ESB 是否符合敏捷哲学？ 我阅读和研究得越多，我就越不这么认为！ ：/
感谢您的意见！ 如果您需要我澄清，请提出几个问题，我会尽力做到！ :)
I'm working on shifting our corporate technological paradigm to Agile Development.
It's been a hard process but we're almost there! :)
We have legacy systems for our database management (used to be Access, now ported to .NET and MS SQL) and we're developing a framework for our future vision. We want to migrate as much as possible to the web. But we want to integrate the current system with the "upcoming" one. We won't be overlapping tasks and functionalities.
My vision is to move all contact info on our users to a different database, linking those "profiles" back to the MS SQL for their history and accounting info. We'll keep all accounting systems on the desktop app, but there's a lot more functionalities that we're about to add that will rely heavily on the web, especially Ruby on Rails.
I guess the question is: why ESBs? Is there a way to create a SOA without going gung-ho with complex ESBs systems. The whole idea is to K.I.S.S. anyway. Can a SOA be created in a way that allows the desktop/web/mobile to be interfaces, keeping the functionalities on the business logic (of course some functionalities would have to be implemented on the interface, but keeping that to a bare minimum). And do ESBs even fit an Agile philosophy? The more I read and study them, the less I think so! :/
Thanks for your input folks! If you need me to clarify, just make a few questions and I'll do my best to do so! :)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
一旦框架/基础设施就位，ESB 就非常适合敏捷。 你会发现你可以分片创建一个新系统，让新的片断与旧系统并行运行一段时间，然后逐渐关闭系统的旧部分，直到只剩下新系统，没有人会这样做。知道
基本 SOA 只定义服务而不是应用程序的区别吗？ ESB 管理通道中的服务以隐藏端点，使升级和替换更加“敏捷”
ESBs fit well with agile once the framework/infrastructure is in place. You'll find that you can create a new system in pieces, run the new pieces in parallel with the old system for a while, and gradually turn off the old parts of the system until only the new system is left, and no one will ever know the difference
a basic SOA just defines services instead of applications; an ESB manages the services in channels to hide the endpoints, making upgrades and substitutions much more "agile"
我很快就学会了回避“ESB”这个术语，因为它的含义非常广泛，并且对不同的人来说意味着不同的事情（有时对同一个人来说也意味着不同的事情:-)）
自然，关键的事情是问自己你真正需要什么。
将数据库包装为服务可能是一个明智的选择，特别是如果您有多个此数据的客户端； 您将不得不花费大量时间来考虑您的合同和范围，但敏捷可以在这方面提供很大帮助。
现在的问题是如何调用这些服务，我认为您需要权衡客户端和服务发生变化的可能性以及您的系统将如何发展。
服务总线有助于从客户端（可以是其他服务）屏蔽服务，并且这种“屏蔽”可以中继到位置、协议、格式、代码等。
某些形式的服务总线还保留行程（需要调用什么以及何时调用），但我通常不喜欢这个想法。
所以 - 我认为你首先需要问自己的问题是你需要从什么开始以及你希望进行多少前期投资（并且可以证明）
例如，如果最初你对更多的点感到满意-点对点方式，您的客户可以直接调用服务； 在稍后阶段，随着服务的发展，您可以引入“中间人”来代理请求和响应（是的 - 如果您愿意，您可以将其称为 ESB）。
或者，您可以从基本的“中间人”开始，这样客户端就不会直接调用服务，而只具有您需要的功能，并根据需求形式扩展其功能； 它很可能从一个简单的转发机器开始。
理想情况下，您将构建在具有许多内置功能的产品之上； 如果您使用的是 MS 堆栈（但有学习曲线），BizTalk Server 是一个很好的匹配，
所以 - 如果这不是一个非常具体的答案，请道歉 - 但我想我的主要观点是“ESB”不一定是一种矫枉过正，这只是归结为您在第一天希望拥有的东西，而敏捷（和 SOA）肯定会有所帮助，因为它允许您逐步发展，而不是像大爆炸那样的事情。
（如果以上内容完全是无稽之谈或只是有点不清楚，那是因为家里新生儿睡眠不足！抱歉:-)）
I've learnt fairly quickly to shy away from the term "ESB" as itis very overloaded and means different things to different people (and at times different things to the same person :-))
The key thing, naturally, is to ask yourself what it is you actually require.
Wrapping your database(s) as a service is likely to be a wise choice, especially if you have multiple client for this data; you will have to spend a good amount of time thinking about your contracts and scoping, but agile can greatly help here.
The question is now how do these service get called, and I think you need to weigh the likelihood of the clients and services change and how your system is going to evolve.
A service bus helps masking the services from their client (which can be other services) and this "masking" can relayte to location, protocol, formats, codes, etc.
some forms of a service bus also maintain the itinerary (what needs to be called, and when) but I generally dislike the idea.
so - the question you need to ask yourself first, I think, is what do you require to start with and how much up front investment you are wishing to make (and can justify)
For example, if initially you are happy with a more point-to-point approach, your clients can call the service directly; at a later stage, as the service evolves, you can introduce the "middle man" to broker the request and response (yes - you can call it ESB if you like).
Alternatively you can start with a basic "middle man", so that the clients never call the service directly, but have just the features you need to begin with and expand it's capabilities as requirements form; it may well start as being a simple forwarding machine.
Ideally you would build on top of a product that has many capabilities built in; BizTalk Server is a good matchif you're on MS stack (but has it's learning curve)
so - apologise if this is not a very concrete answer - but I guess my main point is that "ESB"does not have to be an overkill, it simply comes down to what you wish to have at day one, and agile (and SOA) definitely helps by allowing you to gradually evolve rather than anything big-bang like.
(if anything above is complete nonsense or just a bit unclear it's due to lack of sleep with a new born in the house! apologies :-) )
整个迁移让我转向 ESB...但是 ESB 的整个想法对于解决涉及大约 30,000 个配置文件的问题来说似乎太复杂了！ 我们正处于指数级增长（达到几百万个配置文件）的边缘，也许开始一条新的道路是最好的。 将 MySQL 数据库上的条目链接到 MS SQL 数据库上存储的数据有多容易？ 显然，我不希望复式输入，但可能有比“整个”ESB 更敏捷的方式...我确实理解，具有 ESB 的 SOA 在升级和替换方面可以非常敏捷，但它会是这样吗？矫枉过正？ :)
The whole migration is what got me to ESBs... But the whole idea of an ESB seems way to complex to solve a problem that involves around 30,000 profiles! We are on the verge of some exponencial growth (to a few million profiles) and maybe starting on a new path would be best. How easy is to link an entry that sits on a MySQL DB to data stored on MS SQL DB? I don't want double-entry obviously, but there might be a more agile way than a "whole" ESB... I do understand that a SOA with an ESB can be pretty agile in terms of upgrades and substitutions but would it be an overkill? :)