Web services SOA/ESB困境

很抱歉这个问题很复杂，但这是我已经研究了一段时间的事情，它真的让我很沮丧。我觉得在当今时代，实现服务的方法有很多种，其中之一就是跨平台（SOAP）和易于构建（多亏了.NET、java和其他框架）。然而，这些技术已经在社区中使用了5-10年，但我们（或至少我）一直受到相同问题的困扰：

识别（跟踪服务）-UDDI；e、 尽管有一个讨论该服务的wiki和保存服务文档的存储库中的同一文档的PDF版本，但g.不得不在本月3次提醒同事该服务的位置

可扩展性—开箱即用的集群；作为一个组织，我们花了很多钱支付给我们的管理员，只是为了观察我们服务的利用率，并做出决策，比如，这个服务是否需要更多的RAM、更多的CPU和更多的接口？我如何平衡这个负载

监控-错误记录等；我无法计算我需要在服务上设置多少次跟踪，以了解为什么会发生一个似乎只影响一个客户的bug，或者必须将逻辑编码到服务中以序列化异常、将异常记录到dbs、正常失败等

部署-易于部署；所有这些都无法将DLL部署到5个负载平衡的服务器

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

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

所以，我不是说这篇文章是关于我的梦想。我确实有个问题。首先，我的梦想/愿望是否完全不现实？此外，有哪些解决方案可以尝试解决这些问题，而不将我们局限于新的、更专有的服务开发方式（BizTalk）？最后，关于一个完整的SOA/ESB解决方案，我们认为现在或将来市场上最有潜力的地方在哪里？

这是我的两分钱

我曾经是一家错误使用SOA的公司的开发人员。他们实现的最糟糕的解决方案是使用SOA在桌面应用程序上对表单元素进行字段级验证。要以可接受的方式执行这些操作，需要非常低的延迟。等待2-4秒以更改到新字段很快就会变老。该服务在biztalk server上通过网络运行。每个人都讨厌它

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

---

不要忘乎所以地认为SOA是解决所有问题的解决方案。在高层次上使用它很好，在低层次上使用它会使您的应用程序变得脆弱、缓慢，并且无法调试。

我认为您在这里讨论的是不同类型的问题

1） 。不阅读文档的开发人员。这是一个普遍存在的问题，不仅限于SOA——只要看看有关StackOverflow的一些问题就知道了。至少开发人员会问您是否有服务，而不是在他们自己的代码中复制逻辑。我看不到任何解决此类问题的技术方案，您已经提供了良好的注册表和文档，但是一些开发人员更喜欢与人交谈。甚至可能，这实际上是一件好事——人机交互的价值高于交互的技术内容。或者，你太好了：“不，我不回答这个问题，查一查。”

2） 。缩放比例。有一些技术可以解决这个问题。（免责声明我为IBM工作，IBM销售一些产品，因此我将引用这些产品-我无意暗示IBM是这一领域中唯一提供解决方案的供应商。）有这样的产品，可以配置新机器、安装软件堆栈并将其添加到集群以解决工作负载变化。然后，在JavaEE世界中的细粒度控制级别上，应用服务器可以动态地塑造流量并调整集群。看

3） 。监测。我不明白你在这里所期望的。在所有可能的情况下，这些棘手的错误将需要应用程序级别的跟踪。对于一些问题，例如查找内存泄漏和性能瓶颈，有非常好的工具，至少在JavaEE世界是这样

4） 。我无法与.Net世界对话，但我想说Java EE应用程序服务器在顺利跨集群部署应用程序方面做了合理的工作，在我们使用JNI并需要部署DLL的情况下，我们可以使用我提到的Tivoli stack等产品来管理这一点

---

总之，我认为供应商正在努力解决这些问题。我不认为没有SOA你的生活会更简单。相反，想象一下，同样的问题也适用于无数独立的应用程序。

如果您与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.

注册表和存储库服务器。很好的一点是，它可以进行治理（升级、降级、版本控制、批准），并且您的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?

交易

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