许多组织现在都面临着跟上当前的业务趋势和管理复杂系统的挑战。所以组织都在寻找着更好的业务敏捷性,更好的业务自动化,以及更好的IT适应性来加速其业务成长。 在大多数情况下,SOA在简化业务和不同部门间的沟通方便上做出了帮助。它把功能分割到不同的业务服务—可方便地访问和重用的单元。
SOA专注于敏捷性和灵活性。其要点是创建可容易地跨企业访问并可在不同的环境中消费的服务。 面向服务架构 根据维基百科,“面向服务架构(SOA)是一组灵活的设计原则,用于计算域的系统开发和集成阶段。基于SOA的系统会把功能打包成可互操作的服务套件,这些服务可用于来自若干业务域的多个独立系统上。
” 通常SOA……
我们一直都在努力坚持原创.......请不要一声不吭,就悄悄拿走。
我原创,你原创,我们的内容世界才会更加精彩!
【所有原创内容版权均属TechTarget,欢迎大家转发分享。但未经授权,严禁任何媒体(平面媒体、网络媒体、自媒体等)以及微信公众号复制、转载、摘编或以其他方式进行使用。】
微信公众号
TechTarget
官方微博
TechTarget中国
许多组织现在都面临着跟上当前的业务趋势和管理复杂系统的挑战。所以组织都在寻找着更好的业务敏捷性,更好的业务自动化,以及更好的IT适应性来加速其业务成长。
在大多数情况下,SOA在简化业务和不同部门间的沟通方便上做出了帮助。它把功能分割到不同的业务服务—可方便地访问和重用的单元。SOA专注于敏捷性和灵活性。其要点是创建可容易地跨企业访问并可在不同的环境中消费的服务。
根据维基百科,“面向服务架构(SOA)是一组灵活的设计原则,用于计算域的系统开发和集成阶段。基于SOA的系统会把功能打包成可互操作的服务套件,这些服务可用于来自若干业务域的多个独立系统上。”
通常SOA会为服务的消费者(如基于web的应用)提供一种手段,让其了解已有的基于SOA的服务。
以下是开发、治理和使用期间的SOA指导原则:
- 可重用、颗粒度、模块化及互操作性
- 遵从行业标准
- 配置及监控/跟踪
在任何给定的组织里面,SOA行动失败的其中一个原因是糟糕的治理。SOA治理在管理和跟踪服务里面扮演者重要角色。它帮助维护版本和生命周期、配置、服务质量,以及服务的其他方面。企业架构通过提供框架、工具集技术来帮助组织开发和维护其SOA。它也帮助业务端与IT相互适应。
根据开放群组(The Open Group),“开放群组架构框架(TOGAF)是一种框架,是一种具体的方法和一组支持工具——供开发企业架构所用。它可以自由地为任何希望开发供内部使用的企业架构的组织所用。”TOGAF ADM(应用程序开发方法)是一种循序渐进式的流程,用以开发满足组织的业务和信息技术需求的企业架构。它可以进行调整以适应组织的需求并运用到架构规划活动的执行当中去。下图由开放群组提供,说明了ADM的周期:
TOGAF下的SOA
尽管TOGAF被定义为开发企业架构的具体方法,它也借助了帮助架构师决定在何处以及如何使用SOA的指南和技术。
在ADM的过程中,以下事情需要多加小心:
准备阶段:
这一阶段关注的是满足新企业架构的业务指导所需的准备和初始活动。在此阶段,企业架构师应当采纳面向服务的原则。这将帮助本阶段两项额外的输出——治理和支持策略,以及初始架构库进行相互的调整适应。
架构师应当:
- 在架构原则之下增加面向对象原则
- 利用开放群组的服务集成成熟度模型(OSIMM)进行SOA成熟度评估
- 定义SOA治理和支持策略—SOA治理应该延伸对IT&EA(企业架构)治理
- 注入一个与SOA相关的架构容器,如SOA参考架构,SOA构建模块,SOA SBB或SOA技术组件
- 组建SOA卓越中心(CoE)并建立架构团队
架构愿景:
本阶段关注于愿景、范围、业务驱动力以及准备情况评估。
愿景:定义愿景的时候要小心。SOA有其自己术语(像合同、服务等之类的术语),模型、策略以及模型。开放群组已经发布了SOA本体论,正式定义了SOA的术语、语义以及基本概念。
范围:架构范围取决于企业的类型和规模。作为一条普遍实践,不建议建立单一的架构(如果是非常复杂或大型的话)。首先定义拥有长期视图的战略架构。这一架构将会拥有SOA的若干部分。每一分块可在分块架构(Segment Architecture)中具体细化,并拥有单一的集成的SOA。分块还可以进一步细化为更小、更简单的单元,称为能力架构。下图显示了TOGAF的范围模式:
TOGAF的范围模式
- 业务驱动力及关注点:在定义也去驱动力的关注点和视角的同时,也需要坚持SOA的原则和原理。
- 准备情况:一方面要评估业务能力,也要完成对SOA准备活动的评估。
业务架构
这个阶段关注于业务架构方面的事情,如人员、流程和职能。按照SOA的观点,TOGAF的元模型需要被扩展到覆盖业务架构。而SOA的其中一个主要部分——契约,也需要对业务服务与内外部实体交互的的功能与非功能属性进行形式化。至于非功能需求,SOA服务质量对象应当进行建模。
信息系统架构
这个阶段关注的是组织的应用组合和实体。重大的变更需求需要在应用架构层实现。SOA的产品跟TOGAF的那些不一样,基础和目标架构的差距分析的过程也各异。
技术架构
本阶段定义架构所需的软硬件基础设施。SOA相关的活动可从SOA参考架构开始,并可根据组织的不同进行客户化。在定义技术的时候,应当使用SOA参考模型。
机会及解决方案
本阶段关注于初级实施规划,然后确认前面阶段所定义的架构的交付工具。在SOA中,服务和解决方案组合的识别是一件关键的事情。对解决方案组合、集成以及管理,以及内部或外部服务供应商的确认在本阶段完成。SOA及SOI路线图,SOA解决方案模型与图解是本阶段的输出。
迁移规划
本阶段的关注点是利用一个支撑性的先前阶段确认计划搭建一套细化的系列过渡架构。在这个阶段,SOA治理和策略应当与TOGAF的建议治理模型相吻合,并应该在实施开始前完成。
本阶段关注实施的架构性监管。架构实施应当坚持按照先前阶段所定义的TOGAF和SOA治理及策略模型进行。
架构变更管理
本阶段关注新架构的变更管理,并帮助考虑采纳面向对象的原则。
摘要
实现TOGAF之下的SOA的主要关注点是:
实现TOGAF之下的SOA时,架构师应当记住目标是让SOA解决方案专注于管理企业的复杂性提供提供业务的敏捷性。
资源
- SOA本体论(http://www.opengroup.org/projects/soa-ontology/)
- IBM SOA参考架构(http://www.ibm.com/developerworks/library/ar-archtemp/)
- OASIS面向对象架构参考模型(http://www.oasis-open.org)
- 有关企业架构问题的更多技巧和文章(http://searchSOA.techtarget.com)
关于作者
Gaurav Tripathi (http://in.linkedin.com/in/gauravtripathi)在一家领先的IT企业集团担任解决方案架构师。其主要工作职责是提供大规模/复杂企业应用和应用组合优化、IT战略、技术路线图的架构咨询。他兴趣浓厚的其他领域是在架构治理、指导、技术培训以及博客方面的参与和贡献。参见:http://visitgaurav.blogspot.com/ 了解更多。
相关推荐
-
SOA治理模型核心:人
治理在IT领域非常关键,但是很多时候企业的做法往往太过单向,企业SOA治理模型往往忽视了所有部分当中最关键的组件:人。
-
如何使用SOA治理工具保证项目进度
由API的增加以及为业务应用创建出简单好用接口的需求增长所驱动,这些合并的API-GRC工具帮助开发人员创建,发布,管理并且推广API的使用。
-
SOA治理工具优势:自动化、集中化
SOA项目出现了失去控制的倾向,有可能会导致SOA行动出轨,失去对未来努力的支持,并且浪费时间和资源。
-
SOA架构:为什么需要API管理?
为什么我需要API管理?它能带来哪些好处?其实只是术语变了,但需求还是一样的。在SOA炒作的鼎盛时期,厂商们都宣扬他们的产品支持SOA治理。