采用竖井方法处理服务创建和所有关系

　　SOA 是一个相对较新的体系结构概念，可帮助弥合 IT 解决方案和业务目标之间的差距。SOA 还代表了从传统应用程序体系结构的概念和范畴进行的范式转换。应用程序体系结构通常作为独立的工作创建，此类工作通常属于特定组织域或实体。通常构建应用程序来实现单个组织域中的业务应用程序的自动化。这些单一域应用程序也称为“竖井”应用程序。顾名思义，竖井应用程序的原则和实现不能直接应用到 SOA。

　　当企业开始采用 SOA 时，从竖井开发进行范式转换并未得到良好的制度化。服务可能会基于独立应用程序进行标识，从而导致服务的标识和实现(由相同企业中的不同组织进行)在语义上类似，但却具有不同的名称。这种重复不仅会妨碍得到 SOA 所承诺的真正好处，而且还会增加开发和操作基础设施成本。

　　共享服务的概念应该在企业内得到制度化，必须对其好处有足够的认识。服务应该被视为整个组织内的实体，而真正的业务流程是通过使用多个服务来编排业务而实现的。流中的服务可以属于企业内不同的业务部门。

　　服务必须全面发布，以供整个组织内部使用，或在多个企业参与的服务生态系统中供外部使用。必须放松组织边界和约束的限定，以便实现共享服务的真正好处。

　　必须形成一个工作机构，其主要负责标识服务和建立治理框架来帮助定义作为实现候选的服务的所有关系、资金投入和生命周期。如果没有此类治理机构，企业就很难阻止竖井服务的增多，也很难实现 SOA 的好处。

　　竖井问题是 SOA 采用中的一个常见问题;将在稍后讨论更大的 SOA 治理问题，但务必认识到，治理是用于减少竖井方法的缺点的重要解决方案。

　　细粒度服务

　　甚至在开始 SOA 活动前，业务信息(数据)和应用程序功能也通常存在于当前的企业 IT 投资组合中。这些传统的企业应用程序通常是基于 API 的。用于访问客户信息的典型 API 的示例有 getFirstName()、getLastName() 或 getCelPhone()。这些 API 本质上通常是非常细粒度的。

　　一个常见的 SOA 错误做法是，使用服务接口包装这种细粒度 API，并将其通过 Web 服务描述语言(Web Services Description Language，WSDL)定义对外公开。这会导致错误地将服务概念看作不过是“使用昂贵的服务 Facade 包装的漂亮 API”。不仅得到的“服务”仅传递很少的业务数据，而且这种做法也会导致服务数量剧增。从而导致使用者要负责按照正确的顺序聚合服务，以便实现任何高级业务功能。

　　请记住，服务并不是免费的：对于调用每个服务，应用程序都将以损失一定性能为代价。刚刚提到的失误将导致服务间频繁通信，从而导致系统开销增加，所带来的性能损失将对 SOA 采用造成极大的阻碍。

　　正如我们多次提到的，服务必须与业务保持一致，并能为企业提供真正的收益潜力(无论通过减少成本和节约，还是通过产生收入)。创建仅模拟 API 实现的细粒度服务将不能为 SOA 或企业提供任何帮助。

　　服务可以通过聚合多个低级细粒度 API 实现的功能来实现。不要将每个细粒度 API 都作为服务公开;应该从 API 抽象出粗粒度的、与业务一致的接口，然后将此接口作为服务公开。这不仅能减少网络开销和各个应用程序层次间的通信量，而且还向与业务保持一致的服务接口迈进了一大步。