电信应用图

　　电信应用图（Telecom Application Map，TAM）有效地充当了NGOSS框架构建块（eTOM和SID）与实际的可部署且能得到的运营系统之间的桥梁，将流程功能和信息分组为得到认可的运营支撑系统（Operation Support Systems，OSS）和业务支撑系统（Business Support Systems，BSS）应用程序或服务。

　　虽然此领域可能没有绝对完美的解决方案，但TAM提供了一个通用参考框架，允许供应商、客户和在此领域进行运营的业务合作伙伴了解彼此的观点。TAM基于对当前固话网络、移动网络和线缆通信领域可用的典型系统的观察，并会随着这些系统的发展而发展。

　　从集成的角度而言，TAM提供了基础运营系统的规范模型，并为在eTOM中定义的业务功能和流程提供了通用端点。它充当了Facade，将业务服务从与基础运营系统相关的技术实现细节分离出来，从而进一步减少了此领域变更的影响，实现了基于SOA的解决方案的一个主要目标。

　　IBM WebSphere Business Services Fabric

　　IBM WebSphere Business Services Fabric提供了一个端到端SOA平台，用于建模、组装、部署、管理和治理组合业务服务。它提供了设计时工具、运行时环境、行业参考模型和预构建的SOA资产，以支持快速开发针对行业的组合业务服务。

　　WebSphere Business Services Fabric还提供了可选的电信软件包，此软件包构建于上述NGOSS标准和WebSphere Business Modeler扩展之上，提供了专门针对电信行业定制的、可配置的预构建参考业务服务模板集合。通过这种方式使用预构建资产，可通过重用、标准化和跨IT资产的一致性支持来帮助减少电信运营服务的维护成本。

　　治理

　　尽管治理在分布式体系结构的构造和管理中并不是新概念，但从失败到成功实现或遵循治理的经验使其在SOA中的重要性得到越来越多的重视。

　　早期一些使用共享库（如Microsoft Windows动态链接库）造成的混乱局面就是此领域缺乏治理的结果的一个例子。Windows构建于大量DLL之上，DLL是系统级别的公用功能库，在运行时供很多使用者动态地访问。桌面应用程序也可以使用这些DLL，而且根据操作系统的当前路径级别等因素，可以在安装应用程序时引入这些系统DLL的新版本。

　　您需要仔细分析更新共享DLL的版本的影响，因为所造成的错误的影响将非常广，而且难于定量。您需要保留接口，弃用所建议的退役API，向相关受众发布关于功能更改的信息，并在发布前使用新版本测试依赖于库的当前版本的应用程序和DLL。

　　如果没有进行这些必要的工作，则很容易发现陷入循环依赖关系的网中，发布一个DLL可能会修复一个问题，但最终会带来两个新问题。

　　SOA尝试通过将培训与管理技术结合来处理治理共享服务的类似问题，通过SOA卓越中心（Centre of Excellence，CoE）概念提供流程、模板和最佳实践。CoE提供治理中央机制，控制SOA生命周期的所有方面，包括以下内容：

　　·开发过程
　　·运营问题
　　·服务所有权

　　这以传统的基于项目的设计权威角色为基础，但将其提升到了企业级别，提倡跨所有SOA项目的重用、一致性和标准化。

　　客户案例研究

　　虽然SOA肯定可以应用于新项目开发，但可能在再工程领域才是它发挥自己最大效力的地方。下面的案例研究给出了很多现有IBM客户面临的一个业务问题，这同时也是迅速发展的组织所经历的典型问题。这通常会导致业务需求通过涉及调配具体系统的战术IT活动实现，而非战略企业级的计划。SOA的引入提供了在经历了这样的发展之后将IT与业务相结合的机会。

　　问题

　　客户的业务非常依赖于自定义的现成产品来进行电信运营。客户的基础设施中的每个应用程序在彼此独立的情况下都能正常工作，但由于缺乏企业视角而导致这些产品之间集成情况糟糕，从而出现竖井(silo)情况极为严重的局面。从IT角度而言，这并不一定是个大问题；每个系统都正常工作，似乎都在管理着一个业务流程。不过，这些流程实际上只是子流程，均参与到跨多个业务部门的较大事务中。

　　由于这样，会给用户带来以下影响：

　　·多次身份验证：用户需要维护多个运营系统的多个登录凭据。
　　·集成情况不理想：相关处理系统之间没有或仅有很少的自动化；在存在集成的情况下，也是使用不灵活的专用API，而这意味着要进行更改非常困难。
　　·手工处理：由于缺乏集成，因此存在大量的手工活动，导致出现数据重复，而且需要手动进行协调。
　　·数据不一致：手动干预不可避免地会导致生产系统间出现不准确的数据表示形式。
　　·可见性差：缺乏整套业务流程，意味着很难生成准确的MIS信息。

　　此案例研究的重点在于上面问题中重点涉及的以下三个运营系统间的集成：

　　·订单管理系统：用于记录和管理客户订单
　　·CRM：作为客户信息的主要来源
　　·供应系统：用于激活客户所需的网络服务（即漫游、3G等）

　　每个系统都包含应用程序特定的业务逻辑，这些业务逻辑均以相对独立的方式运行，如图3中所示。此逻辑经常与表示信息交织在一起，即体系结构内没有清楚的关注分离，从而进一步限制了灵活性。在系统彼此通信的情况下，由于使用了专用API，因而存在紧密依赖关系，这种方式不可靠，而且会降低可见性。

　　图3. 业务子流程
 
　　这些系统的用户群实际上有重叠，有些用户最终需要按顺序访问所有三个系统，以收集必要的信息。这就要求他们进行多次登录，以不同的表示样式进行交互、进行重复任务并手动对每个系统的信息进行协调。

　　解决方案

　　引入SOA，以在分层参考体系结构中统一这些异类系统，如图4中所示。

　　图4. SOA分层体系结构
　
　　每个层次提供不同的好处（如下所示），这些层次一起提供了一个灵活的可自定义的业务驱动体系结构。接下来让我们详细讨论一下这些层次：

　　·表示层：引入了门户，为用户提供跨业务活动范围的统一用户体验。通过其个性化功能，可以针对用户的角色对界面进行定制，从而通过基于浏览器的单点登录环境为用户提供相关内容。
　　·业务流程层：尽管现有业务逻辑主要部分仍然驻留在运营系统中，但业务流程层将对这些系统限制如何协作进行编排。它可提供以业务为中心的视图，记录端到端流程，但是不考虑细节。
　　·ESB：可以将总线视为此方案中的粘合剂。它为服务提供者和使用者（可以为业务流程或Portlet）提供一定程度的隔离。虽然总线中没有业务逻辑，但它可以进行动态路由（例如，基于某个服务级别协议选择一系列激活服务中的某个服务），并进行接口映射，有效地将异类基础数据对象统一起来。
　　·服务：提供了基于标准的接口，允许使用者以独立于平台的方式访问服务包含的功能，而不用考虑其实现。
　　·服务组件：这包括实现服务指定的功能的软件组件。服务组件遵循服务层中定义的契约，并保证IT实现与服务描述的一致。
　　·运营系统：运营系统大部分都没有变化。不过，其间的任何依赖关系限制都完全在业务流程层内进行了处理。其目标不是将业务逻辑从这些应用程序迁移出来，而是要保留其经过生产验证的功能，并以标准方式在整个企业内对其进行公开，从而提高其可见性。假如服务接口不变化，则基础运营系统可能会在不影响服务使用者的情况下进行变更。通过这样，就可以使用独立的实现完全替换一个运营系统（例如，使用Siebel替换PeopleSoft），让业务需求推动系统的选择，而不是让IT主导供应商的选择。

　　服务投资组合

　　标识服务时，可以使用一系列建模技术，如IBM内使用的面向服务的建模与体系结构（Service-Oriented Modeling and Architecture，SOMA）方法，本文对此将不予讨论。但抽象一点来说，所标识的服务归为两大类：

　　·IT服务：这些服务通常不包括实质的业务逻辑，而用于提供对现有运营系统的基于服务的访问。通常称为原子服务（因为这些服务通常并不依赖于任何其他服务），且由基础运营系统直接提供——不过也可以使用可用的任意接口机制自行构建。所公开的方法通常都是通用型的细粒度方法（例如，CRM服务可能会提供getCustomerRecord端点），因为这些服务主要设计为供其他服务进行重用。虽然此接口可以由ESB访问，但最好仅在服务接口足够通用，而且不会在使用者和提供者之间引入紧密耦合的情况下才使用。
　　·业务服务：这些服务包含业务流程使用的业务逻辑，通常称为组合服务，因为这些服务可能会将处理委托给一系列其他业务服务或IT服务。与IT服务不同，所公开的方法通常是粗粒度的，且通常与特定业务活动相关（如provisionNetworkService）。

　　经常还有第三类服务，信息服务，用于提供对数据源（通常为联合数据源）中包含的数据的直接访问。不过，在这种情况下，所有数据访问都是通过相关运营系统执行的。

　　行业遵从性

　　使用行业特定的业务流程模板和数据模型不仅可以加速在WebSphere Business Modeler中进行的开发工作，而且还能够提供对业务本身的结构、确定的差距和重叠区域的验证。不过，可能更为重要的是其带来的前瞻性品质认证，特别是在应用程序集成方面更是如此。

　　由于其多样化且十分复杂的技术需求，很多电信运营商都非常依赖于现成的系统，将其用于控制从开单到网络的物理运营的各个方面的事务。这些系统必须有效地进行通信才能保证企业的成功，而遵循行业标准是实现此目标的最好方法。

　　目前需要使用ESB来执行中介操作，在相关运营系统使用的不同数据表示形式之间进行转换。但随着整个行业对标准遵循的不断增加，这将变得越来越没有必要。采用通用数据术语是此领域的一个关键，可帮助对产品接口进行标准化，提高性能、消除特定的产品依赖性，让我们回到SOA的主要目标之一，即业务敏捷性。

　　解决方案堆栈

　　此解决方案基于以下运行时堆栈和开发环境：

　　·IBM WebSphere Process Server (including WebSphere Enterprise Service Bus) V6.0.2
　　·IBM WebSphere Portal Server V6.0.1
　　·IBM Rational? Software Architect V7.0
　　·IBM WebSphere Business Modeler V6.0.2
　　·IBM WebSphere Integration Developer V6.0.2
　　·IBM WebSphere Business Services Fabric V6.0

　　除了每个体系结构层提供的具体功能外，堆栈还带来了一系列非功能优势，包括固有的可伸缩性（通过作为SOA基础的IBM WebSphere Application Server提供的功能）和在堆栈所支持的操作平台内一定程度的平台独立性。

　　尽管我们在此解决方案中使用了一系列WebSphere品牌产品，但此方案最终代表的是一种体系结构范式，并有一定的供应商独立性。IBM参加了各种标准组织（如W3C、OASIS及其TMF、BPEL、XML和WS*标准的后续实现工作），可确保此解决方案不会成为另一个定制解决方案。

　　总结

　　本文从技术和业务的角度讨论了如何通过引入SOA来处理现实的业务问题。BPM之类的补充技术的出现带来了更多的SOA好处，支持您的业务积极地参与到软件生命周期中来。

　　我们还了解了SOA一个将来的发展方向，说明了IT模式如何发展为行业模板，从而为整个企业提供技术和流程蓝图。任何SOA的一个主要目标都是将IT与业务需求相结合，但SOA现在有了进一步的发展；通过采用新兴的行业模型，我们可以看到SOA理念将如何帮助业务保持自身与行业的一致，通过采用标准和最佳实践来提供可靠的互操作性和未来敏捷性。

　　作者简介
　
　　Scott Glen是IBM的Advanced Technology Group (ATG)的一名IT架构师。他在面向对象的系统的体系结构确定、设计和开发方面拥有超过15年的丰富经验，曾为金融、政府、电信和媒体部门提供过咨询服务。他对WebSphere、J2EE体系结构和关联的设计模式有着特别浓厚的兴趣，现在主攻SOA技术，为整个EMEA地区的客户提供咨询和实现服务。
 
　　Jens Andexer是IBM的SOA Advance Technologies团队的认证IT架构师。他在全球从事了25年的软件开发工作，专业从事财务系统、公共部门金融以及保险方面的相关工作。Jens从PL/I维护程序员做起，曾在很多大型的复杂软件开发项目中担任过首席架构师角色。完成了在职计算机科学（软件工程）硕士学位课程的学习后，他于1998年加入IBM，现在正在运用其在主机技术、软件开发和软件维护方面的丰富经验为EMEA的SOA客户服务。