|
SOA咨询方法论研究-SOA咨询理论基础（1）
 (2009-04-10 11:18:40) 1.1 Zachman框架Zachman框架起源于John Zachman的题为“信息系统开发框架”（A Framework for Information Systems Development）的学术论文，文中阐述了在信息系统开发工作中对软件体系结构的看法：系统开发是由具有不同关注视点的若干层面人员共同完成的，这与认识到系统开发是由不同阶段完成的同等重要；在系统开发中，考察对象不应仅限于数据和功能，还应包括地点。Zachman给出了一个矩阵，将关注视点放在列上，角色层面放在行上。 此矩阵最初有是什么（What）、如何做（How）和在哪里（Where）三列。后来，Zachman又增加了是谁（Who）、什么时间（When）时间和为什么（Why）三列。Zachman框架可以用来指导信息化建设过程，并管理此过程中的设计产物。 Zachman框架如下图所示： 图2.1 Zachman框架
Zachman框架是一个6×6矩阵：纵向从规划者、所有者、设计者、承建者、分包者和最终用户六个视角来划分，建立目标/范围、业务模型、系统模型、技术模型、详细表达、运行功能等模型；横向从数据（What）、功能（How）、网络（Where）、人员（Who）、时间（When）、动机（Why）等6个方面的模型，并分别由实体－关系模型（Entity-Relationship）、流程－I/O模型（Input-Process-Output）、节点－链接模型（Node-Link）、人员－工作模型（People-Work）、时间－周期模型（Time-Cycle）、目标－手段模型（Ends-Means）来表达。 Zachman理论发展到今天，称之为“企业架构框架”（EAF，Enterprise Architecture Framework），简称为“Zachman框架”。Zachman也被公认为企业架构领域的理论开拓者，现有的企业架构框架大都由Zachman框架派生而来。 Zachman框架具有容易理解、描述全面、独立于各种工具与方法学等优点，因而得到了广泛的认可，很多咨询方法都从Zachman框架中获得借鉴。Zanman框架完全可以作为SOA咨询方法论的理论基础，是一个非常适合于SOA咨询的思考框架和咨询模式。 1.2 服务架构模型SOA作为一种技术架构而言，涉及与信息系统建设和IT基础设施相关的方方面面，这已经超出技术架构本身，其复杂性难以单纯从技术角度进行评估。为了全面分析SOA知识背景中各个要素之间的关系，应该采用适当的方法来描述。 经过对SOA研究领域的综合分析，我们认为目前最为可行的方法是：基于Zachaman框架建立服务架构模型，采用结构化方法自顶向下进行分解，从不同的维度来进行描述，为现阶段依然模糊的SOA提供一个全景视图。 基于Zachman框架的服务架构模型采用矩阵来表示，横向从逻辑概念范畴的角度，分为六个维度：Why、With Who、What、How、With What、When，纵向从信息系统架构的角度，分为四个维度：业务架构、信息架构、应用架构和技术架构。通过对矩阵中的单元格进行功能聚类，可以发现服务架构模型划分为以下五个领域： （1）SAA（SOA架构的采纳） 面向服务提供了一种理想的世界：里面的资源划分整齐，以服务这种形式加以一致地呈现。因此，企业想从服务方面设计企业架构，就一定要采用SOA架构。所以，企业在业务、信息、信息系统和技术基础设施的各个层面都要从功能服务方面加以分解。采用一致、合理的做法可以提供松散耦合的功能服务，它们可以在所谓的共享服务中心里面进行外包、内包或者组合。与不想采用SOA架构的组织相比，采用SOA架构、并且以合理方式进行实施的企业可以获得更大的灵活性、适应性及敏捷性。 （2）SOE（面向服务的企业） 面向服务的企业其实以一种极其水平的方式连接业务流程。它采用的企业基础设施可以提供企业架构和安全基础，能够跨企业以一致的方式运行这些服务。虽然在过去的三十年里，面向服务的架构这一概念被系统架构师奉为最佳实践，但现在它得到了各个地方许多组织的接受，被认为是获得业务敏捷性的关键。但SOE和SOA既不是即开即用的成套系统，也不是什么单一技术，更不会让所有问题都能迎刃而解。尽管SOE能够带来甚至促进组织上的变化，但它也要求主管人员、企业架构师及项目经理要有不同的思考和行事方式，否则完全会发现自己遇到新问题，根本得不到多少好处。 （3）SOA（面向服务的架构） SOA体现的是一种新的系统架构。在基于SOA架构的系统中，具体应用程序的功能是由一些松耦合并且具有统一接口定义方式的组件（也就是服务）组合构建起来的。可以说SOA的出现，为整个企业级软件架构设计带来巨大的影响。 （4）SOC（面向服务的计算） SOC就是用服务作为基本单元来开发应用程序。SOC是依赖面向服务的架构来构造服务模型的。 （5）STP（SOA架构的迁移） 迁移管理是在通向面向服务的漫长道路当中最关键的问题之一。尽管迁移至面向服务的平台意义重大、关键的Web服务标准继续面临不确定性，加上大规模部署SOA往往会产生重大影响，现在是开始考虑迁移的时候了。成功迁移的关键在于，在有关SOA的活动当中找到一个平静点，然后制订直观的方案，指导贵组织走过面临技术障碍、组织阻力及不断变化的行业趋势的道路。 政府机构内与SOA相关的人员的关注点有所不同，如下： 对于组织的决策者和信息主管来说，需要考虑SOA的必要性、可行性等（SAA－SOA架构的采纳）； 企业架构咨询人员要从IT规划层面，考虑基于SOA的战略规划、业务规划和技术规划等（SOE－面向服务的企业）； 软件开发商需要从技术实现层面，考虑基于SOA的信息系统架构设计（SOA－面向服务的架构）； 硬件和平台厂商需要从IT基础设施层面，考虑如何优化基于SOA的系统的效率和性能（SOC－面向服务的计算）； 系统集成商需要考虑如何从原有的IT架构迁移到SOA架构（STP－SOA架构的迁移）。 基于Zachman框架的服务架构模型如下图所示： 图2.2 服务架构模型（基于Zachman框架） 在服务架构模型中，从技术实现和运营管理两个方面来看，以下的关键问题关系SOA项目的成败。在SOA项目启动之前，就应予以重点关注。 （1）服务规划 在基于SOA的信息系统中，服务是构建信息系统的基本单元，应该确定到底有哪些服务、服务封装什么内容、服务之间关系如何，需要重点关注服务粒度的划分和服务的相互引用问题。 服务粒度表示的是一个服务的大小，可以理解为服务操作的范围和内容。粗粒度的服务设计，可以减小服务之间的耦合性，但付出的代价就是增加服务的复杂性，服务具备了太多的功能，增加了设计的复杂性和维护的难度；细粒度的服务，可以让服务的实现变得简单，但这样会增加服务的数量，那样就增加了服务之间的耦合度。因此，应该确定一个准则来指导服务的粒度划分。 （2）服务编排 为了实现可以灵活定义和调整的业务流程，应该确定业务流程的流转范围、策略实现和定义方法等，需要重点关注服务编排问题。 服务编制关注于一种说明性的方式（不是编程方式）创建合成服务，定义了组成编制的服务，以及这些服务的执行顺序。服务流程的编制和编排，服务编制用于定义合成服务，关注重用已有服务的内部流程；服务编排关注与多方参与的交换消息，进行对等的业务协作。因此，应该确定一个标准来指导服务编排。 （3）服务质量（QoS） 为了对处于运行时（Runtime）的服务例程的服务质量进行跟踪、记录和分析，应该确定服务等级（SLA）划分、服务质量监控、事故记录分析、服务质量问题处理等方法，重点关注服务质量监控问题。 服务质量是SOA 应用的典型非功能服务需求，它使得在服务全生命周期中，根据可用的系统资源，使服务请求者的需要与服务提供者的能力达成一致，主要是指性能、可靠性、可用性和安全性等。因此，应该确定一个规范来指导服务质量管理。 （4）服务运营 |
|
|
