在某些圈子内,人们常常把SOA计划看作是一项孤注一掷的命题,需要有一个不妥协的承诺对整个企业实施改造。对于支持这个观点的人们来说,这种做法能 够促使设计师不再考虑必须要遵守全球数据模式,让IT经理由于担心失去他们部门的权利而睡不着觉,让标准警察(配备行业标准的防暴器械)控制这些难以管束 的开发人员。
把SOA计划与著名的“宇宙大爆炸”式的方法联系起来是一种令人遗憾的误导。这给SOA带来了没有保证的恶名,与SOA计算的理念 是背道而驰的。没有人要求你必须实施整个企业范围的SOA以便实现其好处。这正是“DomainInventory”(域清单)方式出现的理由。从战略计 划的观点看,对于大多数机构来说,没有其它任何方式能够比全面实现SOA提供的一切东西更重要。
在向SOA应用过渡的时候,你要负责 定义这个应用的范围。只要它是一种有意义的跨竖井式的方法,它就能够实现与SOA计算有关的战略性的好处。换句话说,我们只是说不要求你为了得到SOA的 好处而在整个企业范围内实施SOA。你可以建立一个你的IT企业有能力管理的域(domain)并且在那个范围内应用SOA。你的机构中的另一个团队可以 建立自己的领域并且实施不依赖于你的计划的自己的SOA计划。
这种基本概念构成了这个方式的基础,为整个企业范围内的应用提供一个非常现实的和得到证明的替代方法。
在SOA设计方式清单中,这些域将以服务清单的形式显示出来,如许多独立标准化的、治理的和拥有的服务。一个服务清单也许是你在一个服务目录或者服务组 合中存档的现实世界的实施。当采用“域清单”方式时,一个IT企业将有至少两个服务清单,每一个服务清单都有自己的定义并且根据自己的条款发展。事实上, 大型企业最终产生10几个“域清单”是很常见的。
分析师JoeMcKendrick最近在接受InformITOnSOA频道网络采访 时回答了有关这种方式与创建“服务岛屿”有什么区别的问题。他说,换句话说,这种方法是让我们倒退到最初使我们陷于困境之中的基于竖井的集成的应用程序环 境吗?不,不是。这种方式是建立一个“服务大陆”。在那里,每一个服务清单的范围都是通过恰当地实现战略重要性与可管理的治理平衡定义的。
但是,标准警察喊道:“等等,当不同域的服务需要沟通的时候,这还将导致集成的要求吗?”是的,警官。这是真实的。在需要结合跨“域清单”服务的时候, 需要列出这些传统的集成技术,如那些执行数据模型转的技术、协议桥接和数据格式转换等技术。同其它任何设计方式一样,这种应用程序会有一些不良后果,这是 “域清单”带来的重要交换条件。然而,由于这种方式的应用程序能够比较早地在规划阶段作为最初的计划实施,这些转换和桥接层被认为是企业技术环境中可以接 受的和可以预期的部分。企业技术环境是围绕域清单构建的。由于它们是可以预期的,它们的影响可以提前做出计划。在提供解决方案之后意外地产生集成的需求的 时候,这种方式能够更有效地缓解这种需求。
定义一个服务清单的域的构成有许多不同的方法,可以根据权限区、地理位置或者大规模的老式环 境等条件进行定义。最健康的方法是让“域清单”的边界与实际的业务领域一致。这有助于让一个面向服务的技术企业的物理宏观观点与逻辑的区域或者可能存在的 业务范围同步,这将极大地优化长期的业务技术调整。
使用这种方式还有许多不同的和创新的方法。例如,域服务清单以后可以在企业中用于分阶段地实施SOA。还有许多扩展的机会或者在最初定义之后扩大单个域的机会,从而使这些服务进一步以渐进的方式普及。
无论采取哪一种方法,重要的是理解这种方式提供给你的选择。由于这种方式能够使SOA在任何机构都能够成为可得到的和实现的项目,这种方式已经成为目前面向服务的计算提供的成功地实现企业价值的最流行的手段。