SOA / ESB困境

Question

对于这个非常复杂的问题感到抱歉，但这是我一直在研究的一段时间，这让我非常沮丧。我觉得在今天这个时代，我们有一百万个实现服务的方法是跨平台（SOAP）和易于构建（感谢.NET，Java和其他框架）。然而，这些技术已经在社区中存在了5到10年，但我们（或者至少我）经常遇到同样的问题：

1. 识别（跟踪服务） - UDDI;例如，本月必须提醒同事3次服务所在的地方，尽管事实上有一个讨论服务的wiki和存放在我们服务文档的存储库中的相同文档的PDF版本
2. 可扩展性 - 开箱即用的集群;作为组织，我们花了很多钱来支付我们的管理员只是为了观察我们的服务的使用并做出决定，例如，这项服务需要更多的RAM，更多的CPU，更多的接口吗？如何对此进行负载均衡？
3. 监控 - 错误记录等;我无法计算我有多少次设置对服务的跟踪，以便了解为什么一个错误只会影响一个客户，或者必须将逻辑编码到服务中以序列化异常，将异常记录到dbs，优雅地失败等等。
4. 部署 - 易于部署;没有将这些DLL部署到5个负载平衡服务器

这些问题中的每一个都需要组织实施某种类型的自定义解决方案。 ＃1的文档和UDDI。 ＃2的虚拟化和负载平衡硬件/软件。跟踪，为＃3编写数据库/日志等的例外。 ＃4的自定义部署软件。我在一家中型组织工作。我甚至无法想象像Sun，Google或Microsoft这样规模的公司如何应对这些困境。

也许我的愿景是不现实的，但我梦想有一个框架本身存在于管理所有上述内容的服务器集群之上。我很欣慰地看到微软的AppFabric，因为它似乎真的将BizTalk的一些功能扩展到WCF服务实现者：缓存，托管，监控等等。但是，从我所看到的，我仍然感觉不到它的存在实现一体化解决方案的梦想，它可以帮助开发人员和组织编写容易跨集群扩展的服务，轻松部署到集群中，可识别，甚至可以版本化。

所以，我不是说这篇文章是关于我的梦想的。我确实有一个问题。首先，我的梦想/想要完全不现实吗？此外，有哪些解决方案可以尝试解决这些问题，而不会将我们局限于开发服务的新的更专有的方式（BizTalk）？最后，考虑到完整的SOA / ESB解决方案，我们现在或将来在哪里可以看到市场中最具潜力的产品？

Answer 1

我认为你在谈论不同类型的问题。

1）。不阅读文档的开发人员。这是一个地方性问题，不仅限于SOA - 只需看看StackOverflow上的一些问题。至少开发人员会询问您是否有服务，而只是在他们自己的代码中复制逻辑。我没有看到这些问题的任何技术解决方案，你已经提供了良好的注册表和文档，但一些开发人员更愿意与人交谈。也许，甚至，这实际上是一件好事 - 人类互动的价值高于互动的技术内容。或许，你太好了：“不，我不会回答这个问题，看看吧。”

2）。缩放。有一些技术可以解决这个问题。 （免责声明我为IBM工作，销售一些，所以我会参考这些 - 我并不打算暗示IBM是唯一在这个领域有解决方案的供应商。）有this等产品可以配置新计算机，安装软件堆栈并将其添加到群集以解决工作负载变化问题。然后，在Java EE世界中，在更细粒度的控制级别，Application Server可以动态调整流量并调整群集。见WebSphere Virtual Enterprise

3）。监测。我不会“得到”你所期望的。在所有可能的情况下，这些棘手的错误将需要应用程序级别跟踪。对于某些问题，例如发现内存泄漏和性能瓶颈，有很好的工具，至少在Java EE领域是这样。

4）。我无法谈论.Net世界，但我会说Java EE应用服务器能够顺利地跨群集部署应用程序，在我们使用JNI并需要部署DLL的情况下，我们可以使用产品比如我提到的Tivoli堆栈来管理它。

因此，总而言之，我认为供应商正试图解决这些问题。如果没有SOA，我认为你的生活会更简单。想象一下，相同的问题应用于无数独立的独立应用程序。

Answer 2

这是我的两分钱。

我是一家不正确使用SOA的公司的开发人员。他们实施的最糟糕的解决方案是使用SOA在桌面应用上对表单元素进行字段级验证。为了可接受地执行这些需要非常低的延迟。等待2-4秒等待改变到一个新的领域变得很快。该服务在biztalk服务器上通过网络运行。每个人都讨厌它。

如果您要这样做，您确实需要花费大量时间来处理网络延迟，服务故障，时间安排和超时问题。

不要忘记，并认为SOA是解决每个问题的方法。在高级别使用它很棒，在低级别使用它会使您的应用程序变得脆弱，缓慢且无法调试。

Answer 3

如果您与IBM或其中一家大型SOA供应商交谈，他们会获得涵盖每种情况的产品。

Identification (Tracking services) - UDDI; e.g., had to remind a co-worker the 3 times this month where a service is at, despite the fact there is a wiki that discusses the service and a PDF version of the same documentation that lives in a repository where we keep our service docs.

Registry and Repository服务器。好的方面是它确实进行了治理（升级，降级，版本控制，批准），并且您的ESB通常会对注册服务器进行最新和最大的“查找”。

Scalability - Out of the box clustering; As organizations, we spend a lot of money on paying our admins just to watch the utilization of our services and make decisions like, does this service need more RAM, more CPU, more interfaces? How do I load balance this?

事务监视软件，如IBM Tivoli Composite Application Manager for SOA。基本上，它从水平的角度跟踪事物，并从最终用户/最终应用程序的角度来看是否存在服务中断。

就你的集群而言......你必须选择好的中间件和架构。就个人而言，准备“云”的东西。由MOM连接NoSQL的App Server。

Monitoring - error logging, etc; I can't count how many times I have to set up tracing on services in order to see why a bug is happening that only seems to affect one customer, or have to code logic into the service to serialize exceptions, log exceptions to dbs, fail gracefully, etc.

您的开发人员和供应商的企业标准。将所有业务和系统事件集成到一个仪表板中。 （大多数公司都将它们泄露出去）。这在大多数企业商店已经完成。

Deployment - easy to deploy; none of this deploying DLLs to 5 load balanced servers

啊...... Microsoft IIS Web部署工具2.0。只需更新主服务器即可同步100个MS服务器。这真的很容易。