服务管理员

让我们想象一个美好的SOA幸福世界，企业计算需求被分成许多小型应用程序，这些应用程序相互提供服务，以实现有效的协作。美好的一天早晨，一个消费者服务需要从一个供应商服务获取一些信息。问题是，虽然供应商服务拥有获取此信息所需的数据和处理逻辑，但它尚未通过服务接口公开这些信息。供应商有一个潜在的服务，但它实际上还没有存在。

在理想情况下，消费者服务的开发人员只需要求供应商服务开发潜在的服务，一切都会很顺利。但现实并非如此理想 - 这里的问题是，供应商服务的开发人员还有其他事情要做，通常这些事情对他们的客户和管理层来说比帮助消费者服务团队更重要。

最近我和同事埃里克·多恩堡聊天，他告诉我他看到一个客户使用的方法来解决这个问题。他们借鉴了开源的经验，将所有服务都变成了内部开源系统。这允许消费者服务的开发人员自己编写服务。

我相信很多读者看到这种做法会感到眼花缭乱，因为这会导致混乱，但就像开源项目不允许任何人编辑任何东西一样；这个客户使用开源式的控制机制。特别是，每个服务都有几个管理员 - 负责维护服务处于健康状态的人。在正常情况下，消费者开发人员实际上不会直接提交更改到供应商源代码树，而是将补丁发送给管理员。就像开源维护者一样，管理员会收到补丁并审查它，以查看它是否足够好以提交。如果不是，则与消费者开发人员进行对话。

正如埃里克从他自己的开源工作中了解到的那样，审查补丁比自己进行更改要轻松得多。因此，虽然管理员方法并没有完全消除消费者开发人员需要等待供应商开发人员的问题，但它确实在很大程度上减少了难度。再次遵循开源模型，一旦管理员感到满意，消费者开发人员就可以成为提交者。这仍然意味着提交可以由管理员审查，但避免了管理员成为瓶颈。

与之相关的是他们对服务注册表的方法。我们已经看到很多花哨的产品被出售来提供服务注册表功能，以便人们可以查找服务并查看如何使用它们。这个客户放弃了它们，而是使用了HumaneRegistry。

于 2012 年 5 月 24 日重新发布