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或微软这样的公司会如何解决这些难题。

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

所以，我不是说这篇文章是关于我的梦想。我确实有一个问题。对于初学者来说，我的梦想/想要完全不现实？此外，有什么解决方案可以解决这些问题，而不会将我们限制在开发服务的新专有方法（BizTalk）中？最后，关于完整的SOA/ESB解决方案，我们现在或将来在哪里看到市场上最有潜力？

Answer 1

我认为你在这里讨论不同类型的问题。

1）。不阅读文档的开发人员。这是一个流行的问题，不仅限于SOA - 只要看看StackOverflow上的一些问题。至少开发人员会问你是否有服务，而不是在自己的代码中复制逻辑。我没有看到任何针对这些问题的技术解决方案，您已经提供了很好的注册表和文档，但一些开发人员更喜欢与人交谈。也许，即使这实际上是一件好事 - 人际互动的价值高于互动的技术内容。或者，也许你太好了：“不，我不会回答这个问题，查看它。” 2）。缩放。有技术解决这个问题。 （免责声明我为IBM工作，谁卖了一些，所以我会引用这些 - 我并不打算暗示IBM是这个领域唯一提供解决方案的供应商。）有一些产品，如this可以配置新机器，安装软件堆栈并将其添加到群集以解决工作负载更改。然后，在Java EE世界中更细粒度的控制级别中，应用程序服务器可以动态调整流量并调整集群。见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 server。很好的一点是它可以实现治理（升级，降级，版本控制和批准），而且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应用服务器。

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 

Ahh .. Microsoft IIS Web Deployment Tool 2.0。您可以通过更新主服务器来同步100台MS服务器。这很容易。