没有合适的资源?快使用搜索试试~ 我知道了~
精通 SOA 软件开发的 7 个步骤
4星 · 超过85%的资源 需积分: 15 9 下载量 124 浏览量
2009-09-28
09:02:32
上传
评论
收藏 397KB DOC 举报
温馨提示
试读
17页
最新的soa资料,(9-28)通过以上7步,可以对soa的构建过程有个概念性的了解
资源推荐
资源详情
资源评论
了解精通 SOA 软件开发的 7 个步骤
第 1 部分:构建服务组合
尽管面向服务的体系结构或 SOA 仍然是新生事物,但许多公司正逐步认识到需要采用 SOA 方法作为执行满足业务需求的解决方案的方
法。采用这种方法的一个关键步骤是构建可重用服务的组合。
SOA 表示新应用程序的设计、开发和集成方式的根本性转变。它还将企业应用程序的开发简化为模块化业务服务,可以轻松地对其进行
集成和重用。
SOA 的一个主要优点是缩小了业务和 IT 之间的差距。作为需求收集活动的一部分,将业务和技术需求与机构的与项目有关的主要业务目
标相对应,将对确保项目与业务需求同步大有帮助。
着手构建服务组合的动力主要源于意识到需要保持业务需求与 IT 项目之间的一致性。一般来说,该过程始于初步确定所需的服务,进而
发展到发现它们所依赖的服务与资源(如定义特定业务规则的政策等)并对其进行分类。理想状况下,这样做的成果是一套面向服务的
业务应用程序,应用程序可以修正和重用,以满足企业不断变化的业务需求。
尽管在执行 SOA 时有许多问题需要考虑(如业务流程的编排、用户界面的开发以及支持安全和性能的基础架构等),但是获得服务组合
在逻辑上显然是第一步。在“精通 SOA”系列的此部分中,您可以大致了解用于构建服务组合的框架。
SOA 管理驱动组合构建
对 SOA 组合的创建起积极推动作用的通常是那些最为关心 SOA 管理相关问题的人。理想状况下,这个“管理委员会”应当是相关组的交叉
项,包括业务流程所有者、系统架构师和开发人员。
SOA 管理是一个宽泛的题目,值得专门撰文加以论述。不过,在这里我们不妨将其概括为“将 SOA 的灵活性与传统 IT 体系结构的控制及
可预言性相结合的框架”。
SOA 管理在本文中一般涉及下列方面:
服务与相关资源的生命周期管理
相关性管理
策略的应用与管理
安全性和运行时策略执行
服务可用性
服务供应
执行能够管理不断增长的服务组合的管理平台的重要意义远远不止于对技术基础架构和运行时间环境所需进行的改进。
对任何管理计划来说,主要目标都是通过定义将管理建立在其核心内的 SOA 策略来最大限度地降低风险。不受管理的 SOA 可能会导致
如下后果:
由于发布的服务不完全符合服务级要求而导致过程的中断
由于服务问题和故障而使帮助台和现场服务呼叫猛增,导致支持费用的增加
缺乏互操作性,从而形成业务服务的孤岛并时刻面临传统的、紧密耦合的体系结构所带来的挑战
由于无法使主要策略与服务相关联而导致无法满足合归性要求
由于允许随意访问数据和服务而形成安全漏洞
随着服务产品的增加,未受管理的 SOA 中存在的这些问题所形成的风险会成指数倍地增加。不过,通过对服务组合的正确执行和管理,
其中许多风险能够得以减少。
服务发现
逻辑上,构建服务组合的第一步是确定需要哪些服务。用于鉴别和发现候选服务的可行技术有三种,即自顶向下分析、自下向上分析以
及业务流程跟踪。注意,应当考虑使这些技术互为补充,不要唯一排外,每一种技术都应当在您的服务发现过程中发挥作用。
第一步,您应当启动自顶向下的分析,重点将机构的业务分解为若干功能“域”。在这里,域是指密切相关的功能和数据(如客户、产品和
合同)的逻辑分组。
自顶向下的分析一般会形成一个符合业务需要的、实际的候选服务集。不过,单凭该过程并不能发现机构内的所有候选服务。接下来要
做的是对 IT 基础架构、应用程序的功能性、业务应用程序以前曾使用过的数据以及现有的服务进行彻底的检查。这种自下而上的方法通
常会产生大量的高级和低级候选服务。
作为补充手段,您应当对每个业务事件的生命周期进行跟踪,以便发现哪些服务是通过其生命周期处理该事件所需要的。该过程称为业
务流程跟踪,它不但可以发现处理该事件所需的服务,还可以发现仅通过自顶向下或自下而上的方法操作时所遗漏的候选服务。
除了识别交付项目所需的服务之外,该业务流程驱动的方法还能够提供完整性检查,并就特定服务的重用潜力给出首要指示。
服务发现的最终结果将是一个概念上的服务组合,该组合包含了项目最需要的候选服务。
服务分类
发现一组候选服务之后,对它们进行分类是对其进行设计、开发和后续执行的至关重要的一环。
分类可以按照功能、用途、结构和调用等标准进行。例如,将服务分为基础架构服务( DNS 查找、电子邮件)或工具服务(转换)是基
于功能进行的分类。
这种分类方法有助于识别属于同一功能域的服务、允许定义标准和最佳方法并对不同服务类的要求进行管理和监控。对服务进行分类的
过程还将会发现业务服务的规则,可以将这些规则转换成一组应用于不同类型服务的、标准的、可重用的策略。
虽然服务进行分类还没有业界统一的标准,但通用描述、发现和集成 (UDDI) 注册表正在成为事实上的标准。UDDI 不但允许将元数据设
置在服务上,还允许将其设置在诸如策略和 XML 模式等相关产物之上。
例如,您可以在 UDDI 注册表中创建下列分类模型以简化服务的发现、管理和控制:
服务所有者和联系人信息
服务或产物的功能描述
版本信息/状态,例如“版本”或“状态:测试 | 生产 | 维护”
服务类型(“订单输入”)或业务范围(“会计”)
使用模式/建议,例如“事物处理 | 子事物处理”、“同步 | 异步”
预期的错误信息,用于现有服务的重用
服务相关性,可能包括相关的策略、XSL 转换和 XML 模式
可用的服务端点,以及 Web 服务中抽象的和具体的 WSDL 位置
给 UDDI 注册表中的服务和产物分类,不但可以使您能够更好地为潜在的候选项分类,而且还能发现可以重用的现有服务,从而避免了
功能的不必要重复。
确定服务粒度
争取合适的粒度级别将实现使用、重用和可管理性方面的最佳化。顶级的、业务驱动的分析通常会发现与现有需求相对应的高级(粗粒
度)服务。例如,一个粗粒度服务可能表示“流程采购订单”,它清晰地映射到一个业务流程。
由于自下而上的分析专注于 IT 基础架构和现有的 API,因此该方法通常会产生大量的粗粒度服务和低级(细粒度)服务。激活低级任务
(例如“插入订单行项”)的功能就是一个示例。
理想状况下,您的 SOA 组合应当首先包括粗粒度服务界面,该界面直接与业务语义相对应。高级服务在动态的业务环境中灵活得多,因
为它们没有紧密地耦合到下层基础架构之中。粗界面还允许您利用来自异类环境的其他服务来构建应用程序和流程,而不必考虑细节和
差别。
相反,低级服务是和下层基础架构或 API 紧密耦合的,不能轻易加以修改以适应不断变化的业务需求。实际上,将一个服务包装在一个
现有业务对象周围(例如企业 JavaBean (EJB))将不可避免地产生细粒度界面,把每个可供呼叫的方法显示在 bean 上。
用于处理机构内部非常特殊的案例的服务可以通过细粒度界面执行,这将为使用这些服务的客户端应用提供更多的灵活性。不过请记住 ,
在灵活性增强的同时还须面对复杂性增加所带来的成本问题。
一般来说,您应当避免将低级界面公开出来作为服务组合的一部分以试图满足业务需求。可考虑改为将一组细粒度服务结合起来组合成
粗粒度服务。
最后,需要记住的一点是,一个服务是否适当并不在于其是粗粒度还是细粒度,而要看其是否能使业务价值最大化。
服务获取
定义完服务组合之后,下一步是确定如何获取实际的服务:内部构建、获取服务或预订外部供应商提供的服务。
按照一般规则,那些关键性业务服务(即有益于业务流程、能为机构争取竞争优势地位的服务)最好是由内部提供。
您很可能在服务的发现阶段就已经在内部把可以映射到候选项的服务识别出来了。例如,倘若贵机构拥有 ERP 或 CRM 系统,则主要界
面(客户、订单、帐户)都是可以加入到您的组合中去的服务。已经在企业内部使用的自定义应用程序可能也值得加以分析,以便识别
可用的界面。
提供更多商品驱动的功能的服务(例如提供股票报价)可能是外部预订的候选项,很可能来自于贵机构已经与之建立关系的业务伙伴。
一旦您开始搜寻符合您需要的服务,服务分类的需要便立即显现出来了。
显然,在识别候选服务时,有许多支持产物也需要创建和管理,例如,用于控制服务的策略;服务所使用的消息类型;以及将输入和输
出消息转换成适当格式所使用的 XSL 转换。
创建一个这些产物及其相应服务之间的关系的目录将大大有助于构建您的组合。UDDI 注册表对本任务来说是一个价值极高的工具,它使
您能够构建一个服务和相关产物的完整的在线目录。
SOA 管理需要考虑的事项
最好您的 SOA 基础架构能提供一个针对如下管理性能的平台:监控与诊断、外化的安全性、集中式审计与事件记录以及服务级协议与策
略管理。有许多特定于 SOA 的组件可以用来进一步提高管理能力,例如企业服务总线 (ESB) 可用来实现可靠的消息传递;业务规则引擎
可用来捕获和自动化业务策略;业务活动监控解决方案可用来优化服务。
采用中间 Web 服务管理服务器尤其受益。在这种配置中,服务通过一个向用户开放的代理 URL 被“虚拟化”,因此请求是通过媒介而不是
直接发送到服务端点的。利用本集中管理平台可在服务上统一地设置策略,并为运行时策略的执行提供了一个单独的点。它还简化了服
务度量和使用情况统计信息(对维护服务组合的运行状况至关重要的数据)的捕获。
服务虚拟化还具有提供位置透明度的优点:通过公开代理,可以在不影响服务用户的情况下对下部基础架构进行改动。该媒介必须维护
其自身的虚拟服务到服务端点映射,或者利用 UDDI 注册表发现一个有效的服务端点。
结论
SOA 作为沟通 IT 世界和业务世界的桥梁这一论断在不断地发展着。服务组合的构建是一项时间和资源的投资,它必将在面向服务的业务
应用程序方面带来巨大的回报。对这些面向服务的应用程序可以加以修改以满足企业不断变化的业务需求。
第 2 部分:通过企业服务总线连接
随着实施面向服务结构体系 (SOA) 这一观念的日渐普及,企业发现自己的服务组合规模日益增大。如果不遵循正确的体系结构模式,则
很难有效地利用和重用这些服务。
企业服务总线 (ESB) 是一种相对较新的软件类别,我们可以使用它来满足上述目的。它提供了一个急需的中间层,从而简化了企业 SOA
实施的数据传递、服务访问、服务重用以及服务管理。ESB 还支持智能指导的通信,调解松散耦合业务组件和取消耦合的业务组件之间
的关系。
在“精通 SOA”的这一部分中,您将了解 ESB 为什么是企业级 SOA 必不可少的一部分,以及如何实施 ESB(包括常见问题)。
是否需要 ESB?
正如本系列第 1 部分 中所说明的那样,SOA 是应用程序在设计、开发和集成方面的一次根本性转变。SOA 还有助于将企业应用程序作为
可轻松集成和重用的模块化业务服务来进行开发。然而,SOA 还意味着各种挑战,其中许多挑战可直接通过 ESB 解决:
可靠的消息传递:可靠的数据传输仍然是所有集成解决方案的基本需要。虽然 SOA 的原则需要基于标准的、与平台无关的消息
协议,但该原则本身并未考虑可靠的数据传递。各项标准(如 WS-RM)正在逐渐支持该功能,但它们还不够成熟或者未被广泛
采用。
服务虚拟化:SOA 代表了一种基本的体系结构模式,在该模式中,任何服务使用方均可从任何平台访问一个服务提供方。这又
意味着适当的协议和语法调解在适当的位置隔离了使用方和提供方。
动态发现和调用服务:为了优化服务的重用,服务使用方需要一个中介功能来了解服务请求的特性,从而方便与提供方进行连
接。在理想的 SOA 中,这种关系将在运行时作为中介。
策略管理:已知和未知服务使用方进行访问都需要一个抽象的策略管理模型,该模型除了强制执行与服务提供方实施无关的更
复杂的业务级别策略外,还能够强制执行身份验证、授权和加密。
管理和监视服务:逐渐增加的服务数量导致环境越来越复杂。必须监视该环境以了解其可用性、性能以及任何技术或业务级别
错误。
系统异构性:人们通过常用的应用程序以及用来连接它们的软件可以发现,今天的新应用程序就是明天的旧应用程序。这种新
技术的普及是必然的,因此,设计系统时必须考虑让其支持这种变化。
从技术实施细节中抽取业务逻辑:SOA 的目标之一是提供一种分层的方法来开发系统,该方法将技术变化从业务流程的变化中
隔离出来,并且将业务流程的变化从技术变化中隔离出来。实际上,必须从一开始就将这种“分别考虑”设计到体系结构中。
解决这些问题的标准方法 — 无论是企业范围还是部门范围 — 是任何 SOA 项目成功的基础。不能保证数据传递的 SOA 解决方案对大多
数业务事务而言不够强健,不能将业务流程从转换和路由逻辑中抽取出来的 SOA 解决方案不会很敏捷。而且,一个无法适应标准和产品
发展变化的体系结构并不会降低 TCO。ESB 模式(以及相关 ESB 产品的引入)是全面的 SOA 解决方案成功的基础。
ESB 部署的先决条件
深入讨论细节之前,我们先进行一下回顾,就会发现并非所有 SOA 实施都需要重大的重用和松散耦合。例如,较小的实施可能只会从
ESB 的增加中获得边际效益。
您需要满足一些战术条件才能建立对 ESB 的需要。按照重要性顺序,这些条件依次为:
1. 服务使用方和提供方可能是松散耦合的,或者需要同步、非确定性的路由(其中使用方需要响应,但不会显式知道服务提供
方)。
2. 执行业务事务之前,需要根据数据、使用方或提供方执行专门的功能(可能包括策略验证、转换等)。
3. 必须有一种将端点应用程序连接到总线的方法(通过重新设计或者通过适配器),该方法必须能够在面向服务的模型中运行这
些应用程序(并非所有应用程序都能够轻松地支持服务。例如,传统的老式程序(如客户数据应用程序)使用连接到老式屏幕
的、基于批处理的编程模型来运行。它们可能不会很容易地适应更基于事务的 SOA 模式。)
对于所有复杂的计算体系结构,这三个条件仅仅是指导方针。肯定存在这样的情况:无需同时满足以上三个条件即可轻松地判别 ESB。
着手进行 SOA 规划时,不但要关心战术方面,还要考虑长期策略目标。
自上而下与自下而上
SOA 的两种主要方法通常被称作“自上而下”和“自下而上”。在自上而下的方法中,采用 SOA 是由业务方驱动的,结果是一个专门设计以
满足业务需求的体系结构,着重于效率。企业的 IT 部门通常推崇更实用的自下而上的方法,因为该方法更关心服务虚拟化,其主要目标
是将成本降至最低并将更多灵活性结合到核心 IT 资产中。
可以想象,人们就哪种方法最适合或最有效展开了激烈的争论。在此,我们不会偏袒任何一方,而是探讨 ESB 是否与这两种方法相关。
答案是肯定的,自上而下和自下而上这两种 SOA 方法通常都需要 ESB。这两种方法所使用的工具没有太大的区别;只不过引入这些工具
的时间不同。在自下而上方法中,可能在最初阶段就开始使用 ESB 来执行低级数据和系统集成。在自上而下方法中,最初关注的可能是
构建服务,不过稍后这些服务之间需要进行互连时,就该使用 ESB 了。
常见用例
详尽列出所有可能的用例将需要更长的篇幅。然而,其中一些较为常见的用例需要进行强调:
服务虚拟化。服务虚拟化是实施 ESB 的主要驱动因素,其他大多数用例都是它的变形。
设计时缺少清晰的层次(或“分别考虑”)会在业务逻辑和 IT 细节之间引入不必要的耦合。起初,这些交叉相关性的影响可能不太明显,
但随着集成范围的扩大,它们开始以指数级速度削弱 SOA 实施最初的优点。到端点的直接链接越多,最开始灵活、松散耦合的体系结构
的僵化惯性就越大。
例如,如果将端点详细信息嵌入在一个数据库中,那么将该数据库从一个网络重新定位到另一个网络将需要一个新版本的贷款审批流程 。
处理几个这样的链接可能还是可管理的,但如果增加到 50 个服务和数十个端点,您就会看到体系结构很快会变成一张纠缠不清的相关性
网。
该示例还暴露了这种设计在 IT 事件(数据库移动)和业务逻辑(贷款审批流程)之间引入的不正常关系。当复杂的核心商业资产(如贷
款审批流程)根本没有变化时,日常 IT 事件难以接受触发这些资产的整个版本控制。
当然,这个小示例可能已经通过仔细的配置以及使用诸如 JNDI 或 DNS 这样的技术缩减至最少,但它仍然可以方便地阐释服务虚拟化所
能解决的问题。更现实的用例包括添加或删除数据库、更改 CRM 供应商,甚至吸收作为合并或并购的结果而产生的新系统。
如图 1 所示,服务虚拟化是保存面向服务体系结构的增长能力的关键。通过使用 ESB,您可以从业务逻辑中彻底消除所有端点详细信息
(如 IP 地址、端口以及其他低级特定于计算机的详细信息),而是公开一个稳定的接口。最终结果是将业务需求与 IT 需求完全分离,从
而允许 IT 和业务独立修改各自的资产。
图 1 服务虚拟化
集中控制策略。您只需监视几个应用程序服务器日志和配置文件的日子已经一去不返。幸运的是,ESB 可以帮助您解决如今的分布式系
统中固有问题的管理和监视,即,提供有关多个应用程序和协议的端到端视图,在企业范围内配置并强制执行全局策略。
由于 ESB 逻辑上作为所有集成通信的中介,因此对 SOA 基础结构的监视变得简单。ESB 管理控制台提供了流经服务的所有交换和消息
的统一视图。(请参见图 2。)这些新的监视功能可用于进行被动和主动监视。例如,构建和强制执行端到端的服务级别协议 (SLA) 变
成可能。实际的监视平台可能是一个外部应用程序(如 OpenView 或 Tivoli,也可能是较新的业务活动监视 (BAM) 工具,现在越来越
多地用于实时基础结构监视),但 ESB 提供了所需的统一的、基于标准(SNMP、JMX、SQL)的基础结构视图。
剩余16页未读,继续阅读
资源评论
- Fly_KKKK2012-09-19资源不错,谢谢分享
tomskyupeng
- 粉丝: 1
- 资源: 1
上传资源 快速赚钱
- 我的内容管理 展开
- 我的资源 快来上传第一个资源
- 我的收益 登录查看自己的收益
- 我的积分 登录查看自己的积分
- 我的C币 登录后查看C币余额
- 我的收藏
- 我的下载
- 下载帮助
安全验证
文档复制为VIP权益,开通VIP直接复制
信息提交成功