分析IT基础设施库(ITIL, IT Infrastructure Library)指导原则并找到和分离出其中的规范域模型，以便在企业服务总线(ESB)中利用这些模型。

　　引言

　　近期在IBM developerWorks上发表的两篇文章（“Introduction to IT service management Part 1 and 2”——请参阅参考资料）介绍了IT服务管理以及它同IT基础设施库 (ITIL, IT Infrastructure Library) 标准和最佳实践集的关系。这两篇文章描述了IBM如何支持更好地实现基于ITIL的方法，以便通过IT流程建模、流程编排和自我管理自主技术来进行服务管理。

　　首先，本文略微深入地研究了ITIL流程及其子模块。然后，本文探讨了如何利用基于ITIL的规范域模型和企业服务总线(ESB)技术来提供一种消息传递基础设施，这种消息传递基础设施可以集成解决IT服务管理问题的应用程序并为其实现自动操作，同时帮助企业实现面向服务的体系结构(SOA)的远景。

　　什么是ITIL？

　　ITIL是当前应用最广泛的IT服务管理方法，由英国政府商务办公室 (British office of Government Commerce) 开发，它提供了一组针对IT服务管理的最佳实践指导原则。ITIL指南将IT服务管理规程的主要原则分为以下几个子类别，这几个子类别统称为ITIL框架（请参见图 1）。

　　图1. ITIL框架
 
　　从上图中可以看出，Business Perspective 模块完全符合Business模块的要求，而ICT Infrastructure Management 模块则完全符合Technology模块的要求。Planning to implement Service Management模块负责处理与将要部署的IT管理服务流程的规划、实现和改进相关的所有问题和任务。

　　Service Management模块是该框架的关键点，它包括Service Support和Service Delivery子模块。Service Delivery模块涵盖了与IT Service的规划和交付相关的流程，而Service Support模块则描述了这些IT Service的日常支持和维护所需的流程。Application Management模块详细描述了在整个应用程序生命周期的所有阶段对其进行管理所必需的流程。Security Management（这个模块经常作为一种完善措施）与框架中其他模块的许多流程都存在交叉，框架中的安全流程情况与此类似。

　　Service Delivery和Service Support模块由许多与正确管理这些问题有关的业务流程组成。图2（展开后）显示了端到端ITIL模型的详细情况。如果单击查看下面的详细图片，可以看到图1显示的ITIL分类中的每一项父类别都完全展开。

　　将Domain和Model Driven设计原则运用到ITIL框架中

　　为了使这些服务管理域的业务流程实现自动化，IBM创建了一些应用程序，这些应用程序可以极大减少在完成一个给定流程的过程中所需的人工参与。我在前面提到过的“Introduction to IT service management”系列文章认为对业务流程进行建模有助于实现这个目标。在这一点上，Domain设计和 Model Driven设计可以密切协作。

　　此时，您可能想知道在这一部分的开始提到的术语域 的含义。我首先列出Webster词典提供的几条定义。其中，最适用于此上下文的定义有两条。一个域可以定义为：

　　实施规则或者控制的领域。

　　独立变量的一组值并据此来定义函数。

　　Wikipedia对域的定义如下：
　　
　　软件系统的应用程序域是一种任务类型，人们针对该任务类型来使用或者计划使用此软件系统。这与软件工程领域存在紧密联系。应用程序域的例子包括保险、计算机辅助制造和管理。

　　软件工程领域是一个研究领域，它为任何在该领域构造和用于解决问题的软件程序定义了一组公共的需求、术语和功能。

　　如果仔细研究作为示例的Problem Management业务流程（它是图1总体视图中Service Support的子类别），可以看出它有一个特定的范围，在该范围内有一些特定于 Problem Management 的流程和活动，并且这些流程和活动属于此特定业务流程（如 create Problem Ticket、update Problem Ticket、Process Misdirected Problem Ticket 和 Close Problem Ticket）。

　　从Domain Driven设计方法起步使您可以深入了解业务域（如ITIL Service Delivery或Service Support模块），这是获得正确的Model Driven设计的关键所在（下一步）。运用在域建模中获得的知识资本，您可以创建与这些域相关的业务流程的模型，然后编排这些流程，并实现利用这些流程的应用程序。将这种方法运用到ITIL上，您在尝试实现服务管理流程自动化上可以获得大幅度的进步。有关域建模的详细信息，请参阅Domain Driven Design（请参阅参考资料）一书。

　　将SOA设计原则应用到ITIL框架

　　一旦域建模、业务流程建模和业务流程编排这三项工作结束，下一步就是通过SOA公开这些流程。随着SOA和Web服务的出现，不同供应商构建的支持同一个域的应用程序之间现在可以共享业务流程数据。这样的一个示例将使用Web服务在IBM e-ESM系统接口和Remedy或Peregrine 系统接口之间交换 Problem Management 数据。顺便提一句，Ali Arsanjani曾写过一组有关面向服务的建模和体系结构 (Service-Oriented Modeling and Architecture)、面向服务的集成 (Service Oriented Integration)和服务集成成熟度模型 (Service Integration Maturity Model)的文章，这些精彩的文章可以为您提供关于如何完成这一工作的详细信息（请参阅参考资料）。

　　不过，事情还没有完全结束。尽管两家供应商也许可以利用Problem Management 服务请求和响应处理各自的数据而无需使用公共的 Problem Management　SOA服务词汇（也称为规范域标准 (Canonical Domain Standard)），但它们无法理解其他供应商的 Problem Management 应用程序发送给它们的数据或者事务请求。因此，为了不通过中介方式通信，两个应用程序需要为 Problem Management 服务事务使用同一个规范标准。

　　从本质上说，Web 服务提供了一个公共的通信模型；但仍然缺少公共的数据模型。

　　创建规范域模型

　　域和模型驱动设计是一个迭代过程在这一阶段，您需要回顾域知识、当前的流程模型，尝试分析与该域相关的业务流程，并将这些流程提炼成一组具体的谓词（如针对Problem Management 进行创建、更新、误寄或者关闭等操作）、名词（数据对象，如客户、服务器、Problem Ticket）以及相关的规范数据模型。然后，每个应用程序都需要根据这个标准，或者通过自身（优先采用这种方式），或者通过使用一个专门创建的适配器（此适配器可以代表应用程序执行规范格式转换）来发送和接收数据。

　　如果您有多个应用程序支持同一个域，则在此特定域中创建一个提供公共语言的规范域模型，以便进行通信。如果使用的是同一个规范域模型，则支持该域的新应用程序将自动集成并与现有应用程序交换数据。此公共语言还创建了一组公共的术语和流程（或者共享的知识资本），使人们在管理域的过程中进行交互和讨论变得简单了许多。

　　如果您的 Web 服务接口并不是内在地支持规范域模型，那么在将消息放到 ESB 中以传递给目标应用程序之前，它需要使用一个适配器（适配器是您的应用程序到 ESB 的入口/出口）来将出站请求转换为恰当的规范数据模型。例如，Problem Management 应用程序需要将出站消息从其专有的数据模型转换为 Problem Management 的规范数据模型，对于入站消息也同样如此。

　　规范数据类型的消息模式所使用的数据类型也很重要。由于 XML 是一个普遍存在的标准，本来就得到 Web 服务 SOA 标准的支持，因此我认为选择它是再明显不过的了。

　　还应该创建一个用于描述域模型内每个 XML 模式中的各个字段的数据词典。此数据词典应该指定每个字段的含义，它的取值应该反映不同的场景、它支持的数据类型，以及在人们将其专有的 XML 模式映射到规范数据格式时可能会需要的一切有用数据。

　　下图反映了规范域模型的一个简单示例。实现这种方法的一种方式是每个有效负载都有一组标准 XML Header 字段，来描述该负载为哪个谓词（create Ticket、update Ticket 等等）服务。接着，可以在一个同属于该 Header 的字段的一组 Body 标记中提供附有谓词的实际有效负载。

　　图 3. Problem Management 的一个规范域模型的示例
 
　　将标准域模型应用到 ESB

　　ESB 是由中间件技术实现的一组支持 SOA 的基础设施功能。凭借合适的服务级别和管理功能，ESB 支持异构环境中的服务、消息和基于事件的交互。（除了很多其他功能之外）它还可以为应用程序提供路由、中介和安全功能。此基础设施还允许完全不同的异构应用程序与其连接，并可向任何已连接到它的应用程序发送消息或者从这些应用程序接收消息。

　　Rick Robinson 的文章（“Understand Enterprise Service Bus scenarios and solutions in Service-Oriented Architecture”）提供了不同场景中 ESB 可以传递的内容的更为全面的定义（请参阅参考资料）。

　　一旦您有了一个基于 ITIL 的应用程序，并且其 Web 服务接口公开了根据特定的规范域模型来交换数据的业务流程，您就可以将它们连接到 ESB。ESB 提供了集中的消息处理基础设施，可以通过该基础设施路由管理 IT 服务管理事宜的应用程序所发送和接收的全部消息，从而自动集成支持各种 ITIL 域的应用程序。

　　在 ESB 中合并一组规范域标准带来的一个明显优势就是，一旦一个符合某个规范域标准的应用程序连接到 ESB，另一个连接到同一 ESB 并且符合同一规范域标准的应用程序就可以立即与其集成。如果能够正确实现，两个应用程序之间进行通信就无需任何中介或者转换，从而极大地提高了自动集成的能力。

 

　　图 4. ESB 总览
 
　　结束语

　　服务管理是一个与很多行业存在着交叉的问题。很多行业已经开始关注服务管理问题并创建了特定于行业的专有标准来包装这些问题。这是一个难题，因为这些问题不应该被限制在某个特定的行业。目前，已经有了 IT 基础设施库 (ITIL) 这组指导原则和最佳实践，但遗憾的是，它并没有为服务管理中更为细致的方面提供标准。IBM Tivoli 和 IBM Global Services（除了其他 IBM 组之外）针对此需求提供了解决方案并积极参与标准组织的活动，以帮助推进与服务管理相关且最终会跨行业使用的工业标准的制定和采用。

　　长期的远景目标是基于 IBM 服务管理域这一部分的业务流程，创建一个基于 ITIL 的规范域模型的目录，并使用其 IT 服务管理策略帮助应用程序所有者采用这些标准。这可以极大减少时间和成本，并使您可以自动完成过去需要数月的人工才能完成的工作。

　　About the author

　　Stephen Watt 是一名软件架构师，他在 IBM Integrated Operations 位于德克萨斯州奥斯汀的实验室工作，其研究方向是 Global Technology Integration 和 Management Competency 中的中间件集成解决方案。Steve 对 WebSphere、Web 服务和企业服务总线进行了广泛的研究，并花费了大量的时间来研究如何通过新兴的标准、产品和技术来创建、自动化或者改进服务、网络和基础设施管理过程。在 IBM 工作之前，Steve 有几年的时间在中东从事咨询工作，并在美国和南非的 startups 公司工作过。Steve 参与了Professional .NET Programming for J2EE Developers 和The ASP Maintenance Handbook (Wrox Press) 的编写，他还在 ASPToday 和 IBM developerWorks 上发表过数篇文章。您可以通过 swatt@us.ibm.com 与 Steve 联系。