范文一:SOA面向服务架构
概要简介
SOA 的概念是 Gartner 公司, 在 1996年提出来的,并于 2002年 12月进一步提出 SOA 是 “ 现代应用开发领域最重要的课题 ” 。
一、 SOA 的定义
SOA 分为广义的 SOA 和狭义的 SOA :
广义的 SOA 是指一种新的企业应用架构和企业 IT 基础架构,它可以使企业实现跨应用,跨部门,跨企业甚至跨 行业之间的离散系统实现互连。
(注意:这里所指的服务并不单单是 Web Service,它可以是以 Web Service实现 ,也可以以业务方式实现,甚至是书面口头承诺实现)。
狭义的 SOA 是指一种软件架构,它可以根据需求通过网络对松散耦合的粗粒度应用组件进行分布式部署、组合和使用。
服务层是 SOA 的基础,可以直接被应用调用,从而有效控制系统中与软件代理交互的人为依赖性。
二、如何实现 SOA
目前 Web Service越来越流行, 并成为实现 SOA 的一种手段。 Web Service使应用功能通过标准化接口 (WSDL ) 提供, 使用标准化语言 (XML ) 进行描述, 并可基于标准化传输方式(HTTP 和 JMS )、采用标准化 协议(SOAP )进行调用,并使用 XML SCHEMA方式对数据进行描述。你也可以不采用 Web 服务来 创建 SOA 应用,但是这种标准的重要性日益增加、应用日趋普遍。
三、 Web Service实现 SOA 的好处
第一, Web Service是跨平台的,应用程序经常需要从运行在 IBM 主机上的程序中获取数据,然后把数据发送到主机或 UNIX 应用程序中去。即使在同一个平 台上, 不同软件厂商生产的各种软件也常常需要集成起来。通过 WebService ,应用程序可以用标准的方法把功能和数据 “ 暴露 ” 出来,供其它应用程序使用。
第二, Web Service是无语言限制的,你可以使用 .NET,JAVA,PHP,VB...... 等多种语言开发并进行相互调用。
第三, 使用 SOAP 时数据是以 ASCII 文本的方式传输,调用很方便,数据容易通过防火墙而实现无缝连接。
四、 WCF 是什么
WCF 是微软为了实现各个开发平台之间的无疑缝连接而开发一种崭新工具,它是为分布式处理而开发。 WCF 将 DCOM 、 Remoting 、 Web Service、 WSE 、 MSMQ 、 AJAX 服务、 TCP 开发集成在一起,从而降低了分布式系统开发者的学习曲线,并统一了开发标准。
五、 WCF 的优点
第一,开发的统一性。 WCF 是对于 ASMX , Remoting , Enterprise Service, WSE , MSMQ , TCP 开发等技术的整合。 WCF 是由托管代码编写,无论你是 使用 TCP 通讯, Rmoting 通讯还是 Web Service ,我们都可以使用统一的模式进行开发,利用 WCF 来创建面向服务的应用程序。
第二, WCF 能够实现多方互操作。它是使用 SOAP 通信机制,这就保证了系统之间的互操作性,即使是运行不同开发语言,也可以跨进程、跨机器甚至于跨平 台的通信。例如:使用 J2EE 的服务器 (如 WebSphere , WebLogic) ,应用程序可以在 Windows 操作系统进行调用,也可以运行在其他的 操作系统,如 Sun Solaris , HP Unix, Linux 等等。
第三, 提供高效的安全与可信赖度, 它可以使用不同的安全认证将 WS-Security , WS-Trust 和 WS-SecureConversation 等添加到 SOAP 消息中。 在 SOAP 的 header 中增加了 WS-ReliableMessaging 允许 可信赖的端对端通信。而建立在 WS-Coordination 和 WS-AtomicTransaction 之上的基于 SOAP 格式 交换的信息,则支持两阶段的事务提交 (two-phase commit transactions)。
第四, WCF 支持多支消息交换模式,如请求 -应答,单工,双工等等。另外 WCF 还支持对等网 —— 利用啮合网络址,客户端能在没有中心控制的情况下找到彼 此并实现相互通信。
总括来说, WCF 是实现 SOA 的的一个优秀选择,利用 WCF 能够实现跨平台,跨语言的无缝连接,从而实现 Web 服务的相互调用。
SOA 架构设计
SOA 本身就是一种面向企业级服务的系统架构,简单来说, SOA 就是一种进行系统开发的新的体系架构,在基于 SOA 架构的系统中,具体应用程序的功能是 由 一些松耦合并且具有统一接口定义方式的组件(也就是 service )组合构建起来的。因此,基于 SOA 的架构也一定是从企业的具体需求开始构建的。但是, SOA 和其它企业架构的不同之处就在于 SOA 提供的业务灵活性。 业务灵活性是指企业能对业务变更快速和有效地进行响应、 并且利用业务变更来得到竞争优势 的能力。对企业级架构设计师来说,创建一个业务灵活的架构意味着创建一个可以满足当前还未知的业务需求的 IT 架构。使用 WCF 实现 SOA ,正好可以利用 WCF 的灵活性,把业务层封装,发布为 Web 服务。这样可以降低系统的耦合度,加大对未知业务的扩展性。
Web 服务本来就是没有区分代码的, 在这个例子里在下多开发了一个 Service Interface目的是为了使系统更易于管理。 在开发期间, Service 是不断更改的, 如果在 UI 层上直接调用服务层,那更改将会是频密的,所以在这里在下开发一个 Service Interface层目的是为了把 WSDL 集成在同一个 DLL 程序集里面, 进行统一修改。最后 UI 层只要直接调用 Service Interface,就可以对系统直接进行操作。要以不同开发工具来实现 Service Interface,这个的代价并不大, 开销是可以承担的。下面附上最简单的例子,希望有经验的高手给予点评,有不妥的地方请多加指教。
代码
在原代码中,在下以 Ucsmy.Portal.ServiceFactory 实现 Service Interface层,其实这个 ServiceFactory 没有太多工作,只是对 WCF 添加服务引用,然 后直接生成 DLL 即可。当然这只是初步的做法,在日后完善代码的时候,这一层还需要对 WCF 的生命流程进行管理。
最后在 UI 层只要直接添加对 Service.Portal.ServiceFactory 的引用就可以直接运行,无需再理会 BLL,DAL....... 等复杂的逻辑转换。在实现多功能分布式开 发的时候,以 WCF 实现的 SOA 的开发方式更能展示其优势。在现代的大型企业系统开发过程中,系统往往会使用 B/S,C/S混合的开发模式。在以往的开发过 程,开发人员往往把 B/S, C/S分开来实现。在使用 WCF 技术后,开发人员可以把功能模块统一发布为 WCF ,然后绑定不同的 endpoint 进行发布,将 B/S和 C/S方式的业务逻辑层真正地融合在一起,从而降低开发难度。
使用 WCF 实现 SOA ,可以对事务、安全、编码等进行统一管理,协调了各服务器之间的系统操作。它涵盖了之前微软推出的所有用于分布式开发的技术,包括 Remoting 、 Web Services、 WSE 、 MSMQ 等,并以一种统一的编程模式来实现。 WCF 既支持具有互操作性的 Web 服务,也能够实现 .NET 客户端 与 .NET 服务端的通信,提供了分布式事务的支持,同时在安全性上,它完全遵循了 WS-*的标准,此外,它还支持队列服务,可以非常方便地利用消息队列完 成异步 操作与脱机调用。在众多优点的支持下,使用 WCF 实现 SOA 面向服务开发不失为一种理想地选择。
范文二:面向服务的架构
(一)基础:什么是BPM商业流程管理? CNET中国·PChome.net 类型:转载 作者: csdn 责编:小蝎 时间:2006-10-23
BPM是流程自动化的应用,帮助企业进行业务流程的分析之外,另可利用IT技术,自动化组织内各部门的原本以人力及公文传递的流程。
根据数据整合软件供货商Ultimus的定义,BPM主要精神在于管理企业的流程。除工作流程自动化系统之外,还必需提供企业应用软件整合(EAI)与交换的功能、流程成本效率评量与绩效管理,以及流程初始设计的模型最佳化工具,用以涵盖企业管理流程中所有的必要环节。
分析师建议,决定BPM工具之前,企业必须用严谨的态度检讨目前使用的软件,决定业务角色的授权,权衡数据模型(data model)与分析工具(analytical applications),并建立未来采用BPM后的假想情境。
目前包括IBM、微软、BEA也努力催生商业模型标准,联合起草网络服务(Web Services)商业流程执行语言(BPEL4WS)。业界相信,先建立商业流程模型,再从这些流程模型中建立应用程序进而监视这些模型,将有助在企业内部的IT部门与业务主管之间建立起环环相扣的自动化流程
(二)体系架构蓝图----SOA和BPM的合并
CNET中国·PChome.net 类型:投稿 作者: BEA 责编:小蝎 时间:2006-10-23
面向服务的体系架构(Service-oriented architecture,SOA)已经成为软件工程中一个最重要的主题。无疑,随着Web服务的推广和广泛接受,以及支持基于SOA解决方案开发的case风格的IDE这一新浪潮的兴起,SOA已经成为构建企业级分布式应用程序的首选蓝图。与此同时,业务流程管理(business process management,BPM)作为操作灵活的新企业并为其建模的主要支持者,正在强力反弹。
面向服务的体系架构(Service-oriented architecture ,SOA)已经成为软件工程中一个最重要的主题。无疑,随着Web服务的推广和广泛接受,以及支持基于SOA解决方案开发的case风格的IDE这一新浪潮的兴起,SOA已经成为构建企业级分布式应用程序的首选蓝图。与此同时,业务流程管理(business
process management ,BPM)作为操作灵活的新企业并为其建模的主要支持者,正在强力反弹。基础结构厂商已经使BPM成为他们出售的系列产品的主要组件,瞄准机会的厂商使用专用的BPM系统提供垂直的业务解决方案,纯使用BPM的厂商正在得到更加广泛的接受。
尽管两种趋势均显露出了征兆,它们的趋同现象仍不明显,而且关于这种现象没有统一的看法。它们是互补的表示法吗?它们会重叠吗?我该如何一起使用它们?这样做有没有另外的优点?此外,为什么80年代末期的企业流程重构(BP reengineering)失败了,而第三次BPM浪潮却将要取得成功呢?
在这一系列三篇文章中,我将解决这些问题。首先,我将讨论一个体系架构蓝图的最佳实践如何将面向服务体系架构与BPM框架合并,从而为构建健壮的企业级集成解决方案并对其建模提供可重复的方案。我描述了为什么在当今,任何使用技术支持其任务陈述需要的企业比以往更能拥有合适的体系架构蓝图。最后,我讨论了什么是实时交易的挑战,以及BPM方法如何能够实现企业灵活性、智能企业建模、系统开发和以客户为中心的运作优点。
在第二篇文章中,我将应用BPM技术来为一个支持“用于汽车保险”业务场景的软件解决方案建模和设计体系架构。我将讲述两种设计:一种纯BPM设计和一种混合型设计。我还将讲述一些新兴的建模工具和标准,并讨论一些建模和各种体系架构选择和策略方面的难题。
在第三篇(也是最后一篇)文章中,我将使用BEA的WebLogic Platform
8.1 构建一个POC。我将讨论BEA的IDE新引入的可视化编程范型及其优缺点,和构建完全分布式的企业级应用程序所需的一些技术。我还将解释,为什么流行的请求/响应模式的WEB协议与基于事件的流程建模,以及它在进行架构决策时的意义不一致的原因。
体系架构模式 —— 谁需要它们?
软件工程是艺术还是科学?在科学中,我们有明确的定义、定理和证据。在艺术中,我们有工具和技术、趋势以及最佳实践。科学中提出了一些假设,其中一些变成定理,另外一些在经过数个世纪的研究之后得到验证,还有一些永远没有答案。在艺术中,新技术带来新的趋势,比如新闻和数字摄影。如果软件工程是一门科学,定义我们在日常业务语言中使用的所有术语不应该是一件困难的事情,像服务、Web服务、面向服务的体系架构、BPM和BPM系统(BPMS)。的确,我可以利用数学精度来证明一个数据库查询算法的正确性。但是,我能够以一种干脆、简洁且通常会被接受的方式来回答,J2EE中的B2B集成是与纯.NET Web服务解决方案相对的正确答案吗?据我了解,对于我们中间的一些人来说,这不是问题。最后,任一种常见的贸易出版物的随机调查指出,每个人都可以给出自己的定义,而有些人甚至质疑IT存在的本质。我不得不得出结论,软件工程仍然是艺术多于科学。这正好是我们需要合适的最佳实践、框架和可重复过程的原因。
模式封装了最佳实践,简练地定义了域问题,描述了使问题值得关注的原因,并提出了解决方案。模式并没有解决独特的问题。专业人员结合各种模式来解决更为复杂而且有时更为独特的问题。Christopher Alexander说:“模式同时也是发生在世界上的事件和告诉我们如何创建该事件的规则,以及我们必须创建它的时刻。它既是过程,也是事件。”我回想起我一直以来最喜欢的定义:对象是带有状态或数据及行为的数据结构。就目前来说,可以把Web服务看作带有一个方法的对象。就像BEA WebLogic Platform 8.1所实现的那样,会话式Web服务看起来更像是真正的对象:对它进行一次初始化,然后一直执行方法。万一您仍然不能肯定Web服务是粗粒度的对象,考虑:(1) IBM、BEA和 Microsoft宣布了WS-Eventing规范。它就像是优秀但老式的对象观察者模式。(2) 开放式网格服务体系架构(Open Grid Services Architecture)实现了网格服务协议的Web服务接口继承。因此,Web服务提供数据和行为(Alexander的定义中的事件和规则),而BPMS 实现模式的流程组件。SOA是一个用于解决企业集成和系统开发问题的体系架构模式。
我们已经看到,SOA不是体系架构趋势的革命,而是它经过一段时间发展的演变成果。它围绕为企业构建分布式系统而发展。诚然,Web服务以一种普遍接受且无二义性的方式提供底层技术,以解决系统连接性问题。也许是头一次,Web服务成功地解决了互操作性的问题,而这是 CORBA、COM、 DCOM和 RPC 做梦也从未想过的事情。我肯定,作为中立语言,XML对此也准备一展身手。然而,SOA中包括进来的BPMS框架是一个新的、革命性的元素。Howard Smith 和Peter Fingar 描述的第三次浪潮是指一组全新的概念、框架和主流产品。它正在显著改变企业转化的方式,从而灵活地管理和运行全局的和协作的电子商务实体。
业务流程管理的出现已经有一段时间,它更多地用于工业中,而与IT无关。并发工程和六西格玛被开发用来解决生产和流程改进中的及时协作问题,并且确实取得了相当的成功。然而,在80年代晚期,出于多方面的原因,业务流程重构管理获得的成功非常有限。但是最根本的原因是,重构是纸上谈兵。没有软件来支持这样一个复杂的任务。BPM在没有考虑IT系统的情况下设计了自适应的企业。正如David Taylor 所写:
“对连续性流程优化的需要要求从根本上重新考虑如何设计和构建信息系统。提出解决固定问题的固定解决方案已经不再够用。”
信息系统,像它们支持的业务模型一样,必须在本质上就是自适应的。
Taylor提出一种基于OO的开发技术,作为开发自适应IT的一种方法,这种技术称为聚合工程(convergent engineering)。然而,OOP无法成功解决分布式计算和企业集成的问题。另外,负责对企业建模的业务分析人员也没有采用OO。
BPMS将流程建立为用于建模、软件设计和运行时执行的统一结构。过去,开发趋势一直在影响我们对企业建模的方式。功能式编程使功能需求技术流行起来。关系数据库带来了RDBS分析和设计的流行。面向对象的编程则为OO分析和
用例开发铺平了道路。但是在大多数情况下,业务分析人员不会使用开发专门术语,因此产生了对需求可跟踪性中通常影响的另一种翻译的需要。
BPM规范正在快速演变为标准。市场中已经出现了支持业务建模、优化和运行时执行的产品。正如BEA的WebLogic Platform 8.1和其他BPMS产品所实现的那样,以流程为中心的BPMS 方法用于系统开发生命周期,它消除了对运行时阻抗不匹配的业务需求。
灵活的企业拥有自适应的业务和自适应的IT系统。如果构建企业解决方案的过程中出现一个新的问题,那么它一定是需求变化的速度。它的速度之快是前所未有的。BPMS引擎添加了一个新的层到传统的开发堆栈(参见图1)中,并引入服务质量来解决企业集成中的根本问题。BPMS引擎使编程最易变的部分——集成点——的软布线变得容易。软布线是以正式语言显式描述的,并由BPMS引擎(又名有限状态机引擎)执行。正如BEA WebLogic Integrator和其他BPMS产品所实现的那样,业务与IT资源可以同时在一个可视化的只能IDE中查看和修改流程。只需轻击鼠标,便可部署到运行时BPMS执行引擎。业务模拟可以运行,而性能工程可以在系统完成之前完成;这种方式听起来就像CASE工具。SOA和BPMS工具将灵活企业的实时执行仪表板带向主流。
(图01)
在本文余下的部分中,我将描述一个典型的金融服务企业的开发,并提出一条通向基于BPMS的SOA的迁移路径。该路径是增量的,但是它需要战略思考和对未来远景的承诺。作为回报,它将允许投资的早期回报,并将遗留企业转化为完全自适应的灵活企业。
从企业远景到组织筒仓(Silo)
企业从远景开始。CEO和董事会采用远景和行业使命陈述。C级管理人员定义策略,并适当地安排流程来管理执行(参见图1)。定义功能角色和责任,然后创建企业界线。业务分类(Line of business,LOB)在本质上可以是水平或垂直的(参见图2)。垂直LOB具有以下特征:
独立的操作域。
特有的管理和策略。
开发和维护自己的IT—自动化孤岛。
足够大以至于可以创建多种业务分类;例如,抵押贷款证券、市政公债、货币市场,等等。
(图02)
水平LOB具有不同的特征集合:
提供业务控制。
管理的支配和一致。
需要访问由垂直LOB管理的数据。
合适的手动流程和书面报告。
在第二个信息纪元(不要与第二次浪潮混淆)中,我们使用了各种编程技术来链接自动化孤岛,从FTP、数据库复制、EAI和消息收发开始。此方法产生了一整套新问题:
· 接口的多重性: 一份Morgan Stanley Dean Witter报告表明,通常的金融服务客户需要维护6000个接口,为此每年花费2500万美元,而且每年还需构建900个新的点到点接口,为此需另外花费2500万美元进行构建,并且还要花费400万美元进行维护。
· 调停流程: 必须在每一个仓库上实现,需要消耗有价值的时间和昂贵的资源。这是一项常用技术,用于检验由多个实体修改的引用数据。
· 流程: 在中间件中进行硬布线。在分析过程中捕捉流程所花费的时间和金钱属于浪费。企业最重要的资产——流程——隐藏在n(n-1)个意大利面式接口的迷宫中。
· 开发新的水平流程:需要多个LOB 的协调。
· 实现特定和专用的接口:需要专门化和一次性编程。重用消失,维护方面的投入显著增加。
· 异常难于跟踪: 错误解析通常需要访问多个系统。人工干预和解释是不可避免的。找寻答案需要花费大量宝贵时间,并对客户满意程度和收益性方面的大致情况有着直接影响。
流程无处不在。您能发现它们吗?
对于企业来说,流程可以是客户层面上的,也可以是内部的,或者可以是更大流程的组成部分。我们在同样的企业中可以找到内部流程。流程通常涉及到人与系统的交互,或者只是系统之间的交互(参见图3)。交易流程是大规模流程的一个很好的例子。行政管理部门的交易人员在他的销售订单系统中接收一个来自对冲基金管理人员的交易执行命令,或者他接到一份传真或一个电话。交易人员检查库存系统的安全性或资金,并借助他的交易对手执行交易。可以制造纸质入场券,而交易助手可能必须在下行系统中进入它。
(图03)
当因为下行系统之一错误地再进入,而帮助台分析人员收到一份异常报告时,另一个内部流程启动了。然后,他在内部记事薄之一中查找数据(原始进入记录),请求来自事务部门的传真(我们假定讨论的交易超过了结算日期),而且因为他在两天内没有收到回复,也许他会再次重复同样的行为。这个流程最终当分析人员解决了问题时终止,当然,除非他调到另一个部门或者调出公司。然后,顾问们必须参与进来,跟踪问题和流程,这通常需要一大笔钱。 每月的客户声明是定期性企业范围内流程的一个传统例子,通常为水平LOB所特有。在大多数情况下,客户在被不同LOB支持的产品中拥有帐号,例如,股票、U.S.证券和外汇。在月末发送多个声明将会十分混乱。法律和一致性问题还需要交叉引用多个仓库的数据。Patriot和 Sarbanes-Oxley Acts (一个新的业务流程,但是不赚钱)的一个主要问题是要访问由大量LOB所拥有的数据,有时还要环绕半个世界。EAI技术和消息收发试图借助早先阐明的限制解决这些问题。 通向灵活性的道路:以BPM为中心的SOA
让我们考虑带有Web服务的、以BPM为中心的SOA如何将现有的遗留企业转换为自适应性的企业。水平流程和异常管理是用于SOA启用的理想候选者,可以演示可调整的和速度快的ROI。没有经历业务流程再造的严谨,我们必须定
义良好的流程图。流程图也是实行业务流程重新设计的第一步。如果使用BPMS 设计工具(Proactivity, Intalio, Interfacing Technologies),您可以把度量关联到流程和行为,例如,性能、开销、IT资源、FTE、逝去的时间、容量,等等。许多BPMS设计工具允许您运行模拟,并继续进行流程优化(运行what-if场景),但是这并非本文的重点。对于我们的重点来说,以下列出的是良好流程图的一些特征:
· 考虑流程而不是功能 : 流程告诉您完成什么工作以及如何完成。功能描述谁在哪里来完成它。
· 从客户的观点出发: 考虑从外部业务事件开始的流程,例如,一次交易、一份订单、一个主张、一个报价请求。
· 在更宽泛的意义上并基于不同的服务质量来划分客户类别: 您生态系统中的性能、供应商、业务伙伴。
· 流程反映状态变化:交易订单、现金支付。从可管理的流程数量6-10开始。记住,大多数人最多只能保留一个页面上的七样东西。
· 定义核心流程和子流程:这里没有科学理论,只有最佳实践。然而,要当心P-calculus2 和Petri-nets;它们将在接下来的10年内带给BPM科学的严密性。 · 将流程分解为行为
下一个目标是通过分解行为来定义小单元。我们将这项工作称为
Elementary Business Services (EBS)。如果您从多维矢量代数开始回想,空间中的任意一点都可以被定义为单元矢量的线形组合。在我们的例子中,我们以可以通过编排EBS子集来构造任何流程的方式定义了所有EBS。正如您可能猜想的那样,我们将EBS实现为Web服务。识别EBS的正确集合和粒度水平很重要。这与设计对象的重要程度相同。相同的规则和技术——封装、状态相关性、内聚性、松散耦合和重构——同样适用,这并不使人惊奇。
EBS的业务量体现出了大量实际优点:
1. 它是要重用的最终指南。可以通过任何想像得到的方式编排EBS,以形成新的LOB。
2. 连续性流程改进不必等到IT适应新的业务模型。
3. EBS对企业生态系统中的企业和业务伙伴可用。
4. 放弃使用一个系统并不是一个一蹴而就的过程,而是一个循序渐进的过程。
5. 可以以一种易于管理且性价比高的方式合并和获得IT。
6. 可以几乎实时地设计和执行一个新的业务流程。
从图4中可以看出,我们可以使EBS在BEA WebLogic Platform 8.1(集成组件)的一个实例中可用。从技术上说,在BEA WebLogic Integration中,Web服务被称为业务流程资源。我们使用IDE编排新流程,使用门户添加UI,然后将它部署为一组EJB来执行。就是这么简单!现在流程是一项IT资产了,就像数据库表、存储过程、遗留COBOL书籍和专用的计算c库。
(图04)
许多金融服务机构的业务分类是水平的,管理高净值的私有客户。在启用了BPMS SOA的企业中,开发IT基础结构来支持这样的新LOB完全可以与正确放置业务模型并行完成(参见图5)
(图05)
考虑Amazon.com 现象,它们并没有创造任何新的EBS。所有EBS位于任何其他邮件订单一览表书店中的恰当位置:定购书籍,检查库存,信用卡付帐,打印声明,准备装运,给客户发送电子邮件。但是它没有创建新流程,没有质疑已经建立好的流程,甚至不用花费什么力气。
正如Howard Smith 和 Peter Fingar所说的那样:“在BPM的第三次浪潮中,筒仓式思考和点到点的技术集成被灵活的、基于业务流程的体系架构所代替。”此外,Gartner Group 现在声明,继续将业务逻辑硬布线到软件或中间件中或者坚持人工步骤的公司将输给部署流程管理体系架构的竞争对手。 实时处理业务
退一步说,预测将来是很困难的事情,但是我们用非常科学的态度对待它,而且始终试着这么做,不管对还是错。统计和预测是关于预测将来的两门科学。投资组合评估和保险统计研究是有关预测的科学。实际上,我们的预测仅仅基于我们已经经历过的、过去的性能和趋势。实时处理业务需要预测未来的业务情况。然而,基本的业务协议和框架必须合适。今天,技术革新、BPMS和SOA是将业务目标与IT相结合的基础。流程提供一个封装了变化的新层。90年代早期,PowerBuilder和VB风格的工具使客户端/服务器和关系数据库系统的开发
流行开来,通过与此相同的方式,BPMS引擎将在未来建立流程驱动的企业。事实上我预测,在我们的一生中,我们将看到对运行时流程的需求,该类流程用于实时变化或对自修改流程的需要。无疑,人类希望能够掌管该类变化,但是通过使用UDDI-? (? 代表流程)找出最可能的服务契约和使用描述域专业知识和市场情况的规则进行决策,BMPS能够使这项工作更加容易。随着BPMS的普及,灵活性将被极端自适应所代替。
结束语
在本文中,我描绘了合并SOA和BPM的蓝图。从一幅企业的自顶向下流程图开始,我们定义了基本业务服务的组合选择。垂直LOB拥有并部署EBS。Web服务实现它们,并使它们对企业可用。通过使用BPMS引擎的一个实例,可以设计、开发、测试新的流程,并通过结合现有的EBS,在数日内添加业务值。
在我的下一篇文章中,我将:(1) 讲述用于给现实世界业务保险流程建模的BPM技术,并提出一个纯BPM解决方案和一个混合解决方案;(2) 使用Web服务和JMS连接设计EBS并实现它们;(3) 提出一个使用WebLogic Platform 8.1的物理基础结构;并 (4)讨论面向服务体系架构中的BPMS难题和新出现的模式。
直到:流程无处不在。您能发现它们吗?
(三)简单到复杂,BPM技术促进SOA发展
CNET中国·PChome.net 类型:转载 作者: csdn 责编:小蝎 时间:2006-10-23
BPM(企业流程管理,Business Process Management) 与 SOA (服务导向架构,Service Oriented Architecture)各自历经多年的发展,越来越成为人们的焦点。 众多厂商成为了SOA技术架构的推动者,其中包括IBM、BEA、HP、Oracle和SAP。
SOA可以看作是B/S模式、XML/Web Service技术与管理软件的结合。它通过组合单独业务和流程实现复杂的业务应用,而这些业务功能和流程称为服务, SOA把业务流程视为独立于应用程序及其运行的平台的可复用组件。 从SOA概念提出以来,越来越多的主流厂商开始了BPM与SOA的应用。今年3月,BEA收购Fuego扩展SOA到BPM软件,以此使用新的BPM升级SOA平台。2月,HP和Oracle集团宣布,HP的服务咨询和集成(Services Consulting &
Integration)将会同Oracle的Fusion中间件,加入到它的SOA的投资组合以及HP OpenView管理软件套件,以Fusion融合SOA。去年,Oracle收购了BPM专业公司Collaxa;SAP重新设计软件,以便集成自由版本的面向BPM的中间件NetWeaver。
除平台提供商以外,开源厂商也试图占领拥有自己的SOA却缺乏服务的
市场。JBoss公司在2005年10月发布的企业过程管理引擎,围绕业务过程执行语言(Business Process Execution Language BPEL)提供了一种可插拔的体系结构、扩展的任务管理以及新的可扩展性。BPEL虽然是用来编排Web服务的,但依然适合用来集成,而不是深入的业务逻辑。 BPM无论从技术还是方法上都将促进SOA的发展。在此过程中,大型平台厂商IBM、BEA、SAP、Oracle等将会尝试建立一种新SOA标准;而开源厂商努力构建一套工具,不把自己禁锢于用一种方法构建SOA。 从BPM的IT需求与SOA技术角度上看,BPM与SOA的融合也具有先天优势。BPM的范围覆盖了企业运营的各个环节,如生产、销售、物流、财务等企业经营活动,甚至延伸到供应商和经销商。其产品开发包括6个部分,从基础开始为:开发语言,如BPEL、Java等;BPM服务器,包含EAI/BPM平台产品;BPM工具,包括用户接口工具、过程建模工具、软件需求工具等;BPM套件;BPM知识架构;BPM系统和其应用。由此可见,BPM的IT需求与SOA技术具有以下相似点: 1.BPM涵盖范围广泛,需要完成因事件触发的完全不相干的事件,此特点正与SOA的松散耦合特点相吻合。 2.BPM需要多部门、区域的协同。在此中环境中网络环境的安全性可由SOA技术构架中的WS-Security、LDAP(Lightweight Directory Access Protocol-轻量级目录访问协议)、
PKI(Public Key Infrastructure-公钥基础设施)架构和数位签章等机制来完成。
3.BPM系统构成元素种类繁多而复杂,包含分布于各模块的企业逻辑和规则。而SOA可以看作是B/S模式、XML/Web Service技术与管理软件的延续。
当前多数SOA环境能提供系统管理工具给系统管理员使用,协助管理SOA架构下模块的安装、移除、启动等。目前能够实现SOA的产品包括:Microsoft Biztalk Server, webMethods Business Integrator, IBM SeeBeyond, TIBCO和Vignette。在SOA提出以前,大部分BPM产品在流程图中采用自有定义流程逻辑。 4.企业BPM系统的实施往往从最简单的开始,逐渐提升为复杂的BPM系统。而SOA模块化的特性正好吻合了此特性。
(四)分析:BPM与SOA之间的区别及联系 CNET中国·PChome.net 类型:转载 作者: newhappy2008 责编:小蝎 时间:2006-10-23
关于业务流程管理(BPM)和面向服务架构(SOA)之间关系的讨论热闹非凡。二者也是多年来的热门话题,但是关于它们的讨论通常都出现在互不相关的论坛上,讨论它们的人通常也属于不同的圈子。不过现在这种情况正在改变,因为这两个概念以及相关技术的使用者和提供者正日渐将二者结合起来看待。
BPM阵营通常声称,SOA对于实现BPM来说不是必需的。只需部署一个BPM套件,就可以更快地实现目标而不会带来多少复杂性。SOA阵营则注重于如何从一般意义上解决企业IT的复杂性。该阵营通常声称BPM是SOA的一个特性,但是它是SOA解决方案的一部分,而不是一个单独的东西。当SOA领域的人士谈到BPM时,该术语通常与服务编排或流程整合同义,而不强调对业务分析人员友好的建模或人员交互,而后者对BPM阵营来说非常重要。
为了澄清这些误解,我认为有必要阐明BPM与SOA的不同本质:SOA是一种架构方法;BPM则是一组协调活动。
因此,可以很容易地得到使用SOA或不使用SOA的BPM,反之亦然。我们来看看不同组合的优点。
如果部署一个不使用SOA的BPM套件,则可以获得快速创建、执行和监控/管理业务流程的能力。业务流程的模型可以由业务分析人员创建,但是其完整实现则需要与底层IT系统的集成(以及定义用户如何与该流程交互,但是现在我们暂不考虑)。BPM套件(如BEA的AquaLogic BPM Suite)支持使用各种不同的技术(面向服务的或不是面向服务的)对应用程序和数据库进行轻松访问。实现由代码和来自于并依赖于底层系统接口的元数据组成,因此,对底层数据库和应用程序的任何更改都将导致对业务流程的更改。
如果组织和IT环境规模比较小,并且由同样一组人来控制所有的系统(包括BPM套件)的话,这是完全可以的。如果底层系统完全不更改的话,这种方法同样运行良好。
但是,如果BPM套件由一个小组部署,并消费来自另一个小组的系统的服务,那么协调和管理每个小组中的更改的任务很快就会变得非常困难。这是SOA要解决的典型问题,因此,SOA可以应用于BPM套件的部署,就像应用于其它地方一样。
如果BPM作为SOA的一部分进行部署,这意味着当一个业务流程连接到底层系统时,它连接到由企业服务总线所提供的代理服务,这样就隐藏了底层应用程序和数据库的复杂性。这具有以下优点:
将业务流程连接到系统的过程会更简单,因为IT可以公开更有用的接口,比如聚合的数据服务或使用标准协议而不是专有协议的服务。这减少了实现流程所需的IT工作量,并允许流程人员将精力集中于流程,而不是粘合流程与底层系统所需的技术。
它使得实现更为健壮,因为对底层IT系统的更改不必影响流程所使用的接口。
它在BPM套件之外提供了一个独立的控制和管理层。这允许IT小组更好地管理他们所拥有和维护的服务的策略和资源。
SOA还支持从BPM套件中获得对它所连接到的系统的更好可见度。IT小组可以在服务注册库中注册服务,流程开发人员(甚至可能是业务分析师)可以在构建流程时浏览这样的注册库。这确保了服务可以被正确地使用和重用,而且通常简化了业务流程,因为使用正确的服务可以将流程本身的复杂性降至最低。
无疑,这些优点只有在IT基础架构足够复杂,并且/或者BPM项目达到一定的范围和规模时才能显现出来。因此,在很多情况下,应该首先开发出BPM,而将SOA组件留待以后考虑。
最好的方法是一开始就让业务运作团队和IT企业架构小组保持良好的对话,并针对未来进行规划,同时支持战术性执行。这就需要正确地组合产品。例如,BPM套件本身应该能够提供丰富的连通性,以便无需全面应用完善的SOA来使得BPM运行,这一点非常重要。类似地,BPM套件应该支持SOA,这样BPM与SOA才不至于存在于独立的竖井中,这也很重要。
(五)OASIS总裁Patrick Gannon谈SOA与开放标准
CNET中国·PChome.net 类型:转载 作者: Cnet 责编:小蝎 时间:2006-10-23
Patrick Gannon:今天来给大家介绍一下SOA 对产业的一些好处和标准对产业的一些影响。这一页是我的简单介绍。主要介绍一下开放标准和SOA 对公司的发展有哪些影响。今后的电子商务将会搭建在SOA 的平台上,现在SOA 和开放标准还处于初期阶段。这一页幻灯片是介绍了一下SOA 的基本情况。为了达到SOA 所承诺的前景,需要建立一个共同的框架体系和标准体系。公司要在SOA 投资,必须要获得一些收益,这样保证他们的资产有更好的流动性,也保证他们的资产有长期保值的能力。所谓流动性就是灵活多样的意思,也就是说SOA 的标准体系和核心技术要能够满足各式各样应用的需求。SOA 很重要的特性是能够让你对软件的投资有长期的保值性,能够避免重复投资,可以让你的软件模块可以重复地使用。
为了达到这些目标,有一些很基本的工作需要做。我们必须要有一个共同的体系结构和一套共同的词汇表,大家都知道每一个软件的变量代表了什么意思。现在的问题是各个行业一些主要的技术厂商,他们看的都局限于他们这个行业或者是自己的技术体系来考虑整个软件应用的问题。这个问题是不同的词汇表,不同词汇的意义和不同的表示方法都对使用软件技术的发展带来了障碍。我们的解决方法是什么?在商业业务层面创造互操作性。
其中一个方法是实现跨部门的应用互动和应用的集成。为了达到这个目标,开放标准是其中一个很重要的措施。很多公司问为什么我们需要标准?我们看到为了建立标准体系需要很多的投入,一个标准组织就是为了让业界的企业一起共同做标准的工作,降低大家分头做标准的成本。软件公司需要知道他们做什么标准、同时应该了解标准是怎么产生的,通过什么样的方式使标准有一个基本的接受情况。我们请了Delphi Group Research 做一个标准的调研,看整个企业对标准的认识,和目前对标准研究的看法。有三个重要的调研结果。采用开放标准使得企业的软件可以重复使用,数据也可以在不同的平台上进行共享。第二个结论是采用了开放标准,企业的研发工作可以在更大的协同范围,甚至是摄入最终
用户来进行共同的开发。我们看到开放标准对于Web Service 的使用是非常重要的。
OASIS 是一个国际标准组织,主要是针对先进的结构化数据的信息标准。OASIS 不光只是研究和产生标准,同时也跟其他国际组织一起合作来推动标准的采用和技术的发展。OASIS 有一个非常开放的组织结构,可以让会员很容易在组织里面表达自己,目前有650 个不同的企业会员,来自80个国家。OASIS 在Web Service 、电子商务、eBusiness 和文档管理方面是目前世界上权威的标准组织。通过13年的努力,OASIS 已经得到广泛的承认,OASIS 不仅可以直接向国际标准组织、国际电联和联合国相关标准组织直接提交标准提案。
OASIS 不光只是由技术厂商参加的标准技术组织,实际上有35%的成员来自于客户,也就是说可以对甲方有影响力的部门,还有大概15%的研究单位。OASIS 也是一个发展很快的组织,我来中国很重要的目的是希望能够参与快速发展的亚太地区的经济活动。
这是OASIS 在亚太地区目前的成员,这是在大陆地区的会员成员,我已经参观过了书生、长风联盟和神州数码,以及互联网中心。根据我这个星期在这边的感觉,我认为很快会有更多的公司参加OASIS 这个组织。我邀请大家能够参与OASIS 这个组织。
OASIS 是为SOA 和Web 服务的发展提供重要的指导作用。OASIS 的工作覆盖了SOA 和Web 服务一些非常重要的领域。这是OASIS 在SOA 和Web 服务里重要的领域和技术工作组所覆盖的一些SOA 和Web 服务的重要领域。OASIS 不但是推动标准的研发和发布,也推动标准的全面采用。OASIS 是有25个技术委员会在SOA 领域里展开技术的研究工作。对于公司对eBusiness 有兴趣的公司,有一个商业编排工作组。标准、访问权限控制也是OASIS 在SOA 和Web 服务领域里的重要工作。
Web 服务的管理也是我们一个很重要的技术研究工作。可靠的消息传输也是我们的工作之一。这是UDDI部分的工作。你们看到在OASIS 里对SOA 和Web 服务做了大量的研究和标准建设工作,这也是很多公司参加OASIS 的直接目的。大家都知道当一个公司在新技术方面做投入时都会涉及到一个潜在的风险。SOA 可以帮助公司降低采用新技术的风险。企业今天可以做什么呢?一个是可以参加OASIS 组织,或者是可以观察、了解一下OASIS 组织能做什么。因为这些标准都是在全世界推广和采用的,所以非常重要的是要让在中国的软件企业或者是中国的最终用户能够对他们的技术需求和他们的一些要求很明确地表示出来。表示出来以后,能够影响标准的产生,而且标准是在全球范围内推动的。其中软件公司在OASIS 的工作是提出新的研究方向。其中一个例子就是书生公司已经在上个星期提出了UOML在OASIS 里立项。我相信肯定有很多其他的公司可以把他们创新性的技术提案通过OASIS 这个平台建立起来。对于小的公司,没有很多钱来参加像这种标准组织的话,也可以多看一看标准组织能不能对你们的市场活动带来好处。
除了标准的研究工作以外也跟很多组织合办活动,把会员的一些技术在更大的范围里展示。对于最终客户来说,OASIS 对他们也有很多好处。对于最终用户如果能够把他们对技术的需求明确提出来之后,可以在明确的过程中考虑进去。OASIS 有很多会员是政府部门,这些政府部门参加的原因是他们希望观察标准的研究情况,对标准提出一些建议。这些政府部门也利用OASIS 平台来了解哪些技术方向值得政府的资助,对参加这些研究方向的企业优先考虑进行资助。对于开放标准和SOA 的研究,希望能够邀请和OASIS 一起共同讨论SOA 和开放标准的工作
(六)业界观察:为什么SOA如此得势?
【正文】
作为未来的技术趋势之一,SOA正无可争议地引领着软件业的新一轮浪潮,并在未来给软件和网络带来革命性的变化。为什么SOA如此得势?这是因为SOA改变了过去开发应用的模式,将软件按照业务需求定义成“组件”,作为共享资源,提供以服务为中心的应用软件设计方法。这种方法,能够提高IT对业务的响应能力,使企业得以实时支持业务的变化,最终帮助企业转变为服务驱动型企业。
早在2002年Gartner就预测,到2008年,SOA将成为占有绝对优势的软件工程实践方法,它将结束传统的整体软件体系架构长达40年的统治地位,届时,将有70%的企业在进行企业IT建设时会转向SOA。从技术上讲,SOA并不是一个新概念,早在20世纪90年代中期,Gartner就提出了SOA的概念,但当时的软件技术发展和信息化水平还不足以使它走入实用阶段。进入21世纪,随着Web服务等相关标准的出现和成熟,SOA开始从概念走向实用。
SOA不是某个产品,也不是某个技术,而是一种软件设计架构和方法。SOA要求开发者从服务集成的角度来设计应用软件,它将应用程序的不同功能组件定义为“服务”,通过“服务”之间的良好接口联系起来。(也就是“服务”之间的松耦合。)接口是采用中立方式进行定义的,独立于实现“服务”的硬件平台、操作系统和编成语言。而且这些构建在各种各样系统中的“服务”可以以一种统一和通用方式进行交互。保证系统灵活性,另外,还可以保证“服务”的重复利用。
由此可以看出,SOA的核心概念是“重用”和“互操作”,从而使企业的IT系统拥有极大的灵活性。SOA的另一层意义就是整合,它将企业的IT资源整合成标准的、可操作的服务,使其能被重新组合和应用。在这种架构下,IT系统的复杂性并没有增加,相反,随着系统的不断完善,整个系统的架构将变得更加清晰。
现在随着网络技术的发展,企业在信息化建设中产生了大量为满足产品或服务需要的软件系统,如:ERP、CRM、OA、SCM等一系列IT软件系统。但这些系统
一般都是单独实施、独立存在的,由于数据标准不统一,接口不一致,系统间往往缺少联系与合作,这也就导致了一个系统成为一个“孤岛”。而基于SOA的理念,则使企业在需要改变IT系统时的灵活性大为增加。
SOA架构定义了搭建企业软件架构的一种新方法,它的出现使所有应用在交换数据和处理过程中,不需要考虑应用软件是用什么编程语言开发的或在什么操作系统下运行。在这种模式下,一个应用或应用的一部分其实是一种服务,其他的应用和客户都可以在无需编写大量代码的情况下使用这些服务,这一切都使一些大企业或在地理上分布范围比较广的开发队伍能够更好地合作,因为这些SOA架构下的中间件业务模块都能够被重新配置或以新方式优化来满足新的需求。正是SOA的重用性和互操作性所带来的灵活性实现了企业IT资源整合,使企业IT资源真正面向于服务。
SOA作为一种概念虽然已经成熟,并得到了国内外主流软件开发商和企业客户的认可,目前主流软件厂商均已经完成了基于SOA的改造,但在客户端大规模的应用还有许多事情要做。首先,它包括一系列技术和规范,面临诸多挑战,尤其在项目开发初始,付出的代价要比传统软件项目大得多。其次,实现SOA的Web服务技术尚不成熟,标准还处在发展之中。目前,很多企业对于SOA的认识还仅限于一种“整合”IT技术的概念,人们对于SOA认识的误区还有很多。
面向服务架构(SOA)的原则
Web service已经不再是新婚的娘子。众多企业都已经创建各种实验性Web
Services 项目,事实证明,这项新兴的分布式计算技术确实能够降低集成和开发的成本。另外,一些关键的Web Ser
vices标准纷纷制定,强安全(robust security)和管理方面的产品也陆续问世。对于志向远大的企业来说,他们已经在考虑下一步了。
对大多数公司来说,下一步要考虑的不再是点对点的应用,而是Web services在企业间以及业务伙伴间更为宽广的应用。这种技术的变迁需要更松散耦合、面向基于标准的服务的架构。这样一个架构要求对IT在组织中的角色有新的观点和认识,而不仅仅是一种实现方法。通过对业务的敏捷反应,企业可以得到实实在在的回报,而要达到这一点,面向服务架构设计师的角色非常关键。除此之外,潜在的回报更是不可胜数-分布计算技术能够保证对业务需求足够灵活的反应,而这种业务上的敏捷正是各公司梦寐以求而目前还遥不可及的。
分布式计算将网络上分布的软件资源看作是各种服务。面向服务架构是一种不错的解决方案。但这种架构不是什么新思想;CORBA和DCOM就很类似,但是,这些过去的面向服务架构都受到一些难题的困扰:首先,它们是紧密耦合的,这就意味着如分布计算连接的两端都必须遵循同样I的约束。打比方说,如果一个COM对象的代码有了更改,那么访问该对象的代码也必须作出相应更改。其二,这些面向服务架构受到
厂商的约束。Microsoft控制DCOM自不必说,CORBA也只是一个伪装的标准化努力,事实上,实现一个CORBA架构,经常都是在某个厂商对规范的实现上进行工作。
Web services是在改进DCOM和CORBA缺点上的努力。今天应用Web services的面向服务架构与过去不同的特点就在于它们是基于标准以及松散耦合的。广泛接受的标准(如和P)提供了在各不同厂商解决方案之间的交互性。而松散耦合将分布计算中的参与者隔离开来,交互两边某一方的改动并不会影响到另一方。这两者的结合意味着公司可以实现某些Web services而不用对使用这些Web services的客户端的知识有任何了解。我们将这种基于标准的、松散耦合的面向服务的架构简称为SOA。
SOA的强大和灵活性将给企业带来巨大的好处。如果某组织将其IT架构抽象出来,将其功能以粗粒度的服务形式表示出来,每种服务都清晰地表示其业务价值,那么,这些服务的顾客(可能在公司内部,也可能是公司的某个业务伙伴)就可以得到这些服务,而不必考虑其后台实现的具体技术。更进一步,如果顾客能够发现并绑定可用的服务,那么在这些服务背后的IT系统能够提供更大的灵活性。
但是,要得到种强大和灵活性,需要有一种实现架构的新方法,这是一项艰巨的任务。企业架构设计师必须要变成“面向服务的架构设计师”,不仅要理解SOA,还要理解SOA的实践。在架构实践和最后得到的架构结果之间的区别非常微妙,也非常关键。本文将讨论SOA的实践,即:面向架构的设计师在构建SOA时必须要做的事情。
SOA的原则
SOA是一种企业架构,因此,它是从企业的需求开始的。但是,SOA和其它企业架构方法的不同之处在于SOA提供的业务敏捷性。业务敏捷性是指企业对变更快速和有效地进行响应、并且利用变更来得到竞争优势的能力。对架构设计师来说,创建一个业务敏捷的架构意味着创建这样一个IT架构,它可以满足当前还未知的业务需求。
要满足这种业务敏捷性,SOA的实践必须遵循以下原则:
* 业务驱动服务,服务驱动技术
从本质上说,在抽象层次上,服务位于业务和技术中间。面向服务的架构设计师一方面必须理解在业务需求和可以提供的服务之间的动态关系,另一方面,同样要理解服务与提供这些服务的底层技术之间的关系。
* 业务敏捷是基本的业务需求
SOA考虑的是下一个抽象层次:提供响应变化需求的能力是新的“元需求”,而不是处理一些业务上的固定不变的需求。从硬件系统而上的整个架构都必须满足业务敏捷的需求,因为,在SOA中任何的瓶颈都会影响到整个IT环境的灵活性。
* 一个成功的SOA总在变化之中
SOA工作的场景,更象是一个活的生物体,而不是象传统所说的“盖一栋房子”。IT环境唯一不变的就是变化,因此面向服务架构设计师的工作永远不会结束。对于习惯于盖房子的设计师来说,要转向设计一个活的生物体要求崭新的思维方式。如下文所写的,SOA的基础还是一些类似的架构准则。
SOA基础
在IT行业有两个越来越普遍的发展方向,一个是架构方面的,一个是方法学方面的,面向服务的架构设计师可以从中有所收获。第一个就是MDA(模型驱动架构),由提出CORBA的OMG模型提出。MDA认为架构设计师首先要对待创建的系统有一个形式化的UML(也是由OMG提出)的模型。MDA首先给出一个平台无关的模型来表示系统的功能需求和use ses,根据系统搭建的平台,架构设计师可以由这个平台无关的模型得到平台相关的模型,这些平台相关模型足够详细,以至于可以用来直接生成需要的代码。
MDA的核心就在于在设计阶段系统就已经完全描述,这样,在创建系统的时候,几乎就没有错误解释的可能,模型也就可以直接生成代码。但MDA有一些局限性:首先,MDA假设在创建模型之前,业务需求已经全部描述,而这一点,在当前典型的动态业务环境中几乎是不可能的。第二,MDA没有一个反馈机制。如果开发人员对模型有需要改动的地方,并没有提供给他们这么一个途径。
SOA的另一个基础是敏捷方法(AM),其中非常有名的方法是极限编程()。象XP这样的AM提供了在需求未知或者多变的环境中创建软件系统的过程。XP要求在开发团队中要有一个用户代表,他帮助书写测试来指导开发人员的日常工作。开发团队中的所有成员都参与到设计之中,并且设计要尽量小并且非形式化。AM的目标是仅仅创建用户想要的,而不是在一些形式化模型上耗费工作量。AM的核心思想就在于其敏捷性-处理需求变更的敏捷性。AM的主要弱点是其规模上的限制,例如,XP在一个小团队和中型项目中效果不错,但是当项目规模增大时,如果没有一个一致的清晰的计划,项目成员很难把握项目中的方方面面。
从表面看来,MDA和AM似乎是相对立的-MDA假定需求是固定的,而AM恰恰相反。MDA的中心是形式化的模型,而AM恰恰要避开它们。但是,我们还是决定冒险把这些不同方法中的一些元素提取出来,放入到一个一致的架构实践中。
在SOA中有三个抽象层次,按照SOA的第一条准则:业务驱动服务、服务驱动技术。AM将业务模型直接和实践连接起来,表现在平台相关的模型之中。MDA并没有把业务模型和平台无关模型分开来,而是把平台无关模型做为起点。SOA必须连接这些模型,或者说抽象层次,得到单一的架构方法。我们将从五个视图的架构实现方法来
实现这个连接。
SOA的五视图实现方法
企业架构设计师发现他们的职业非常有竞争力并且值得骄傲,因为他们要从很多方面来通盘考虑IT系统。Kruchten(RUP的开发负责人)将这些方面提取出来,在应用到SOA时,我们称为五视图实现方法(five-vw apach)。
四个方框表示对一个架构的不同审视方法,分别代表不同的涉众(stakeholder)。弟五个视图,use-case视图涵盖了其它视图,在架构中扮演的是一个特殊的角色。部署视图将软件映射到底层平台和相关硬件上,是系统部署人员对架构的视图;实现视图描述了软件代码的组织,是从开发人员角度出发的视图;业务分析人员则利用过程视图进行工作,它描述的是软件系统的运行时特性。最后,逻辑视图表示的是用户的功能需求。在SOA中,面向服务的架构必须能够以use-case视图中的用例将用户连接到服务,将服务连接到底层的技术。
为了表示面向对象的架构是如何工作在这些视图之上,让我们将他们置于SOA元模型的上下文之中。SOA中两个领域存在重叠:由业务模型和服务模型表示的业务领域和由服务模型及平台相关模型表示的技术领域(两个领域共享服务模型)。业务用户通过逻辑视图和过程视图处理粗粒度的业务服务,根据变化的业务需求,按照需要将它们安排在过程之中。另一方面,技术专家的工作是创建并维护服务和地层技术之间的抽象层。表示这些服务的中间模型,起到的是轴心的作用,业务以它为中心进行。
SOA元模型从MDA中继承平台无关模型和平台相关模型,但是添加了AM和用户交互以及敏捷的反馈这两部分,后者通过椭圆之间的双向箭头来表现。类似地,元模型通过引入由中心的服务模型提供的中间层抽象解决了AM在伸缩性方面的问题。这样,服务模型中的任何需求的变化,都会反映到用户每天的业务处理中。同样,由于底层技术是模型驱动的,技术专家也可以根据这些变化的需求迅速而有效地作出应变。
SOA实践和过去解决企业架构传统方式的不同之处就在于其对敏捷性的支持。如前所说,SOA的第三条原则就在于它总在变化之中。这种恒在的变化性环境是SOA实践的基石。如图所示,涉众(stakeholders,译者注:RUP中也有这个词,表示软件开发中涉及到的各种角色如:用户、设计人员、开发人员乃至测试人员等等。)在一个必需的基础上影响到整个架构的变化。在当技术专家在每天的日常工作中不断对变化的业务需求作出响应的这种情况下,设计阶段和运行阶段之间的界限变得模糊起来,很难清晰地分离这两个阶段。
剩下的部分
我们已经为面向服务的架构提供了一个高层次的框架,其中MDA和AM的元素帮
助工具的使用者来创建和维护SOA。但是,SOA中还缺少一些内容-那就是软件开发商和专业的服务组织必需提供的。理想情况下,开发商必需提供面向服务的业务流程、工作流以及服务的协调工具和服务;另外,能够以一种敏捷的、平台无关的方式充分反映业务服务的建模工具也是必须的;技术专家必须配备可以从模型中自动生成代码,并在代码变化时更新模型的工具,最后,开发商必须提供支持SOA的软件,帮助面向服务的架构设计师以一种可信并且可伸缩的方式创建位于服务和底层技术之间的抽象层次。幸运的是,这方面的产品即将上市。
另外,最重要的就是贯穿本文的自顶而下的SOA实现方法了。今天关于Web services的大部分思考都是自底而上的:“这是如何创建Web services的方法,现在,我们来使用它们集成吧”,对Web services技术的这种方法是伟大的第一步,因为它可以惊人地降低集成的开销,这是现在的技术管理人员最乐意见到的了。但当经济进一步发展,IT走出低谷,企业会寻求IT的帮助来提高组织战略意义上的核心价值。使用面向服务的架构,IT可以提供给企业实现业务敏捷性的这样一个框架。
范文三:SOA_面向服务架构
190
科技创新导报 Science and Technology Innovation Herald
2008 NO.25
Science and Technology Innovation Herald
管 理 科 学
科技创新导报
近 两 年 来 , 出 现 一 种 技 术 架 构 被 誉 为 下一代 Web 服务的基础架构,它就是 SOA (Service-oriented architecture,面向服务架 构)。SOA 是在计算环境下设计、开发、应 用、管理分散的逻辑(服务)单元的一种规 范。Ganter 将 SOA 描述为:“客户端 /服务 器 的 软 件 设 计 方 法 , 一 项 应 用 由 软 件 服 务 和软件服务使用者组成” 。 “SOA 与大多数 通用的客户端 /服务器模型的不同之处在 于 它 着 重 强 调 软 件 组 件 的 松 散 耦 合 , 并 使 用独立的标准接口。 ”
1 SOA模型
SOA 是设计和构建松散耦合软件的解 决 方 案 , 能 够 以 程 序 化 的 、 可 访 问 的 形 式 公 开 业 务 功 能 , 以 使 其 他 应 用 程 序 可 以 通 过 已 发 布 和 可 发 现 的 接 口 来 使 用 这 些 服 务 。
图 1代表 Web 服务体系结构的三个基 本 组 件 所 执 行 的 三 个 基 本 操 作:
(1) 服务提供者通过在服务代理者那 里 注 册 来 配 置 和 发 布 服 务;
(2) 服务请求者通过查找服务代理者 那 里 的 被 发 布 服 务 登 记 记 录 来 找 到 服 务 ;
(3) 服务请求者绑定服务提供者并使 用 可 用 的 服 务 。
2 SOA架构的特征及优点
(1) 模 块 化 服 务 :把 业 务 功 能 分 解 并 打 包 成 模 块 化 服 务 , 该 服 务 是 具 有 自 包 含 和 自描述特征的。服务可以根据需要进行混 合 和 匹 配 来 创 建 新 的 组 合 服 务 , 也 可 以 由 其他模块化服务组成。
(2)标准化接口:将 SOA 服务的内容和 具有自描述特征的接口进行分离。封装公 开 了 的 服 务 功 能 , 但 隐 藏 了 服 务 内 部 的 实 现和复杂性, 以便服务使用者发现和访问。
SOA 通 过 服 务 接 口 的 标 准 化 描 述, 从而使 得该服务可以提供给在任何异构平台和任 何用户接口使用。这一描述囊括了与服务 交 互 需 要 的 全 部 细 节 , 包 括 消 息 格 式 、 传 输 协 议 和 位 置 。
(3) 松 散 耦 合 :应 用 程 序 间 的 依 赖 关 系 得到最小化或完全消除。松散耦合可以保 护 SOA 服务不受其与之交互的系统和服务 内 的 更 改 的 影 响 , 从 而 能 够 跨 域 和 企 业 边 界 发 现 和 调 用 服 务 。
(4)跨平台和重用性:通过标准接口, 不 同 服 务 之 间 可 以 自 由 的 引 用 , 而 不 必 考 虑 所 要 引 用 的 服 务 在 什 麽 地 方 , 处 于 什 麽 平 台 , 或 者 是 由 什 麽 语 言 开 发 的 。 从 而 实 现 了 真 正 意 义 上 的 远 程 、 跨 平 台 和 跨 语 言 。 服务架构的核心思想是通过松散耦合的服 务 组 合 来 完 成 系 统 , 因 此 提 供 了 更 高 层 次 的重用性。
(5)集成遗留程序:SOA 中提供了集成 遗 留 程 序 的 适 配 器 , 屏 蔽 了 许 多 专 用 性 A P I 的 复 杂 性 和 晦 涩 性 , 大 大 有 利 于 遗 留 程序的重用,遗留系统可通过 Web service 接 口 来 封 装 和 访 问 。
(6) 服 务 是 自 治 的 、 可 组 合 的 :由 服 务 管理的逻辑驻留在一个显式边界中。服务 在 该 边 界 内 具 有 完 全 的 自 治 权 , 而 不 依 赖 于其他服务来执行这种管理。服务是可组 合的, 可 以 由 一 些 服 务 组 合 成 新 的 服 务 。
(7) 粗 粒 度 服 务 :服 务 粒 度 是 指 服 务 所 公 开 功 能 的 范 围 , 一 般 分 为 细 粒 度 和 粗 粒 度 。 其 中 , 细 粒 度 服 务 是 那 些 能 够 提 供 少 量商业流程可用性的服务。粗粒度服务是 那 些 能 够 提 供 高 层 商 业 逻 辑 的 可 用 性 服 务。选择正确的抽象级别是 SOA 建模的一 个关键问题。设计中应该在不损失或损害 相 关 性 、 一 致 性 和 完 整 性 的 情 况 下 , 尽 可 能地进行粗粒度建模。
(8)开放的标准:如 Web service 标准、 XML、SOAP、WSDL 以及其他标准。
(9) 支 持 多 种 客 户 类 型 :借 助 精 确 定 义 的服务接口和对 XML、Web service 标准 的 支 持 , 可 以 支 持 多 种 客 户 类 型 , 包 括 PDA、手机等新型访问渠道。
3 项目管理
项目是为完成某一独特的产品或服 务 所 做 的 一 次 性 的 努 力 , 一 般 要 涉 及 一 些 人 员 , 由 这 些 人 员 完 成 一 些 相 关 联 活 动 。 项 目 管 理 指 在 项 目 活 动 中 运 用 专 门 的 知 识、技能、工具和方法,使项目能够实现或 超过项目干系人(stakeholder)的需要和期 望 。 项 目 管 理 带 来 的 好 处 有 :能 够 更 好 控 制财务、资源(包括人力资源)、改进与客 户的关系、缩短开发时间、降低成本、提 高产品质量和可靠性、提高利润率、完善 公司内部协调、提高员工士气。
4 SOA与项目管理
采 用 S O A 的 好 处 更 灵 活 、 复 杂 性 减 小、增加重用性、更好的互操作性, 此外, 采 用 SOA 还 具 有 战 略 和 长 期 性 。 与 此 相 反,一 个 项 目 通 常 持 续 几 个 月 或 几 年,而且 需要在一定的时间范围内达到严格定义的 目标。一些 SOA 的优势只有通过坚持某些 可能使项目延期、增加花费、不能产生立 即效益的措施才能实现。项目管理需要做 一些能使自己将来获利的事情。为了解决 项目管理目标与长期的 SOA 利益的冲突, 应该首先分析哪些 SOA 利益可在短期内至 少被部分地实现,以及哪些 SOA 花费因素 可在最初的尝试中被避免。
面向接口:面 向 接 口 对 SOA 来 说 绝 对 是必要的。它可以最低限度地增加编程的 工 作 量 。 此 外 , 较 小 的 变 化 都 会 给 功 能 中 紧密耦合的部分,带来很多的麻烦,面向接 口 减 小 了 需 求 变 更 的 风 险 , 使 团 队 工 作 在 已 定 义 好 接 口 的 基 础 上 , 大 大 地 减 少 了 协 同 的 工 作 量 , 简 化 了 项 目 管 理 。 遵 循 这 种 设 计 模 式 , 不 但 不 会 增 加 项 目 的 花 费 和 持 续 时 间 , 反 而 会 减 少 项 目 开 发 周 期 和 意 想 不到的变更带来的风险。
标 准 化 :项 目 管 理 需 要 认 真 考 虑 在 不 同 模 块 之 间 进 行 标 准 化 通 信 的 花 费 和 利 益 。 标 准 化 可 以 简 化 任 务 , 因 为 只 有 一 个
SOA(面向服务架构)与项目管理
刘雪梅 1、2
(1. 济南军区空军指挥自动化站;2. 山东大学软件学院 济南 250002)
摘 要 :本文介绍了 SOA 架构的特点和优势、项目管理的定义,以及采用 SOA 架构与项目管理的关系。SOA 架构的面向接口、标准化、 自治和模块化、面向业务优势可以给项目管理带来好处,有利于项目管理达到它预期的目标。如果想充分发挥 SOA 架构的优势,要能 够把项目级获得的经验推广到企业体系架构级别。 关键词 :SOA 项目管理 Web service 架构 服务
中图分类号 :TP311 文献标识码
:A
文章编号
:1674-098X(2008)09(a)-0190-02
图
1 SOA
三层模型
管 理 科 学
2008 NO.25科技创新导报
标准需要遵循。同时,许多功能需要进行封 装,从而使其成为标准化的元素。除了封装 元素外,还可以使用中间件来完成标准转换的 任务,这样所有的模块不必自己实现不同的消 息类型,就能进行交互。这两种选择都需要 花费,因为封装需要编程,中间件需要购买,项 目管理者需要根据特定的环境决定是否标准 化。但从全局的观点来看,标准化的接口可 以在将来减少集成的工作量。
自治和模块化:自治和模块化对 SOA 来 说是必需的,因为服务作为基本的组件,应该 能为任何请求者提供特定的功能。然而有 时,快速、紧密耦合的解决方案比起恰当地 进行功能分离的解决方案更快速和廉价。哪 一种模式会给项目带来利益,取决于项目的规 模和复杂度。小的项目很可能采用紧密耦合 的方式更快速一些,但对大的项目来说,可以 从将任务模块化中获利,并使管理工作更简 单 。
面向业务:正确的粒度是 SOA 思想非 常 重 要 的 一 方 面 , 因 为 它 也 是 面 向 业 务 中 重要的一方面。一个服务应该能提供一个 有意义的业务功能。这个要求对小规模的 项目来说,能够获利,因为一个能够提供完 整功能组块的服务比起许多需要在接口两 边 被 理 解 的 小 的 功 能 来 说 , 更 易 处 理 。 与 前 面 提 到 的 类 似 , 大 一 些 的 项 目 可 能 会 这 方 面 受 益 , 尽 管 需 要 增 加 每 个 小 功 能 的 开 销 。
通过上面所讲的,我们可以识别出 SOA
会给哪些项目带来更大的利益。一个项目越
大越复杂,它从被分割成小的功能组块中获得
的利益就越大;项目的时间压力越大,从多个
点同时开始进行开发再集成就越重要.在一个
项目中,能够发挥 SOA 潜在优点的因素是复
杂性、规模和时间压力,SOA 可以妥善地处
理它们,它可以控制一些使项目达不到目标的
因 素 。
5 SOA从项目级到企业级
在项目级别进行 SOA 设计和开发方面
的 工 作 并 没 有 什 麽 错 , 大 多 数 企 业 也 都 是
从 一 个 个 定 制 了 范 围 的 项 目 开 始 的 。 此
外,之所以采用这种以项目为中心的 SOA
开发,是想把它看成一种试验,希望通过试
验来验证 SOA 解决方案。因此,关键是要
能够把项目级获得的经验推广到企业体系
架构级别。
一 般 而 言 , 在 企 业 的 I T 战 略 中 , S O A
是逐个项目的方式实现的。这个以项目为
中 心 的 开 发 方 法 是 目 前 大 部 分 企 业 实 现
SOA 的特征, 这是由于传统企业文化和基
于项目的资金投入模式促成的。尽管以项
目为中心的 SOA 活动提供了一定的好处,
但 真 正 的 企 业 级 别 的 SOA 支 持 才 能 够 提
供 更 大 的 灵 活 性 和 服 务 重 用 , 并 促 使 企 业
的业务和 IT 之间有更好的相关。因此,除
非 SOA 成为企业体系架构的一部分,并完全
进入到组织的开发、设计、部署和治理方法 中,否则就不能完全实现 SOA 的最高回报。 在企业级别成功实现 SOA 能带来更多的好 处,包括快速适应市场动向、缩短新解决方 案的上市时间、提供与业务需求的联系以及 减少长期 IT 成本。
6 结语
虽然对于 SOA 技术的争论一直就没有 停止过,处于争论中的 SOA 也正悄然演变, 我们将会发现 SOA 所真正适用和不适用的 场合,使 它 的 优 势 和 长 处 变 得 更 加 突 出 ,更 好的理解和使用 SOA,促进 SOA 的发展和 成 熟 。
参考文献
[1] 凌晓东.SOA 综述[J].计算机应用与软 件,2007,(10).
[2] T h o r s t e n H a u , N i c o E b e r t , A x e l Hochstein and Walter Brenner.Where to Start with SOA--Criteria for Se-lecting SOA Projects[J].
[3] 如何发挥 SOA 的最大的优势[J].中国传 媒科技,2007(7).
[4] Wesal Al Belushi, Youcef Baghdadi. An Approach to Wrap Legacy Appli-cations into Web Services[J].
3. 4 工期成本曲线图
工 程 施 工 中 , 业 主 通 常 都 要 求 承 包 人 抢 进 度 , 施 工 方 往 往 处 于 被 动 抓 进 度 的 地 位 , 而 这 时 对 成 本 的 考 虑 往 往 不 得 已 被 放 于次要地位。实际上实施一个工程有一合 理工期,在合理工期范围内,工程成本是最 低的,实 际 工 期 比 合 理 工 期 提 前 或 滞 后 ,工 程成本都将加大,编制这个曲线的目的,一 是找出合同工期跟合理工期的关系。二是 工程出现超期或业主要求提前工期时对成 本 的 增 加 有 一 个 估 算 。 横 坐 标 为 时 间 , 纵 坐标为工程造价额。当合同工期跟算得的 合 理 工 期 不 一 致 的 情 况 下 , 施 工 时 就 尽 量 寻 求 二 者 的 共 同 点 。
3. 5 开办费需求图
该 图 横 坐 标 为 开 办 费 明 细 项 目 , 纵 坐 标 为 金 额 , 在 开 办 费 明 细 项 目 的 基 础 上 可 绘制一条开办费累计曲线。开办费可理解 为 工 程 施 工 的 物 质 准 备 费 用 , 包 括 “ 四 通 一平” (水、电、路、通讯, 场地) 费、人员 及设备进场费、临时场地费、临时租房费、 进场时一次购置的生活及办公用品费、工 程 费 (本 工 程 专 用 机 械 设 备 的 购 置 及 安 装 费)等。工程实施时,开办费控制的随机性 比 较 大, 稍 不 注 意 就 可 超 支 。
3. 6 管理费控制表
现在项目投标时项目的管理费都考虑 较 少 , 而 实 际 施 工 时 往 往 花 费 不 少 , 所 以 ,
对 管 理 费 列 出 明 细 项 目 预 算 , 实 施 总 量 及
过 程 控 制 是 必 要 的 。
3. 7 主要材料设备使用控制表
在 一 般 工 程 中 , 材 料 及 设 备 占 工 程 造
价的比例较大。材料特别是地产材料的采
购供应因数量巨大,往往容易出问题,足以
影 响 工 程 盈 亏 , 因 而 对 主 要 材 料 设 备 的 管
理十分重要。对大宗材料设备的使用控制
一般分为货源选择、运输、计量、验收入
库等控制环节、看似简单,其实不简单。该
表应针对大宗材料设备的各个环节控制措
施 及 监 督 措 施 。
3. 8 施工索赔计划表
这 是 工 程 实 施 中 增 加 盈 利 的 计 划 表 。
施 工 企 业 组 织 实 施 一 个 工 程 , 主 要 目 的 是
通过实施项目取得利润, 实施项目是手段,
取得利润是目的。该表的横坐标为计划索
赔 的 项 目, 纵 坐 标 为 金 额 。
3. 9 工程分项盈亏汇总表
在 上 述 图 表 基 础 上 , 可 编 制 工 程 的 盈
亏总,帐,将 开 办 费 及 退 场 费 、 管理费、各
分项工程成本、索赔预期值、管理失误预
期 值 等 项 汇 总 形 成 实 施 工 程 总 费 用 , 与 合
同 价 相 比 , 盈 亏 多 少 , 一 目 了 然 。
3.10 资金平衡表
该 表 反 映 项 目 与 外 部 的 资 金 供 需 关
系 , 项 目 取 得 营 业 收 入 及 项 目 的 支 出 属 于
内 部 资 金 。 实 施 项 目 时 , 资 金 有 时 有 缺 口 有时有盈余,有 缺 口 时 需 外 部 资 金 补 充 ,有 盈余时资金可往外调出。该表反映工程实 施时补充或可调出资金的状况。表中保修 期 满 后 , 项 目 对 内 对 外 结 清 账 目 后 的 资 金 平衡余额应与工程分项盈亏汇总表的余额 相同,为 本 项 目 的 最 终 盈 利 额 或 亏 损 额 ,是 项目核算及上级考核的重要指标。
总 之 , 笔 者 认 为 以 上 三 部 分 内 容 , 是公 路 项 目 管 理 要 素 设 计 的 主 要 内 容 , 做 好 这 三项内容, 对于项目管理的成功非常必要。 参考文献
[1] 焦勃.施工项目的全面合同管理.施工企 业管理,2002(10).
[2] 叶华林等. 浅谈施工企业在工程活动中 的合同管理. 施 工 企 业 管 理 ,2005(2). [3] 品绍延.我国市场呼唤工程总承包.建筑 经济,2003(2).
[4] 刘始.管理型施工企业的几点思考.施工 企业管理,2002(2).
[5] 赵振宁,刘峰生.建设工程施工合同中承 包 人 风 险 分 析 与 防 范 . 施 工 企 业 管 理 , 2004(1).
(上接 189页)
191 科技创新导报 Science and Technology Innovation Herald
范文四:SOA 面向服务的架构
模拟题答案
1. 下面关于业务流程的描述哪些是错误的 ?
A. 业务流程由一系列活动组成
B. SOA中,业务流程可以包含人工操作
C. SOA中,业务流程可以执行数小时甚至数月
D. 任务由一系列步骤组成
E. 流程中任务的顺序可以调整
2. 下面关于 SOA 和 Web 2.0的关系哪些是正确的 ?
A.SOA 可提供更高的安全性、可靠性和可管理性
B. Mashup应用可通过可视化的方式来构建
C. Mashup 应用不可以组装 Web 服务
D. Web 2.0可完全取代 SOA
3. 将复杂的系统分解为多个不同的关注点分别加以解决是下面哪种原则的做法
A. 封装
B. 松耦合
C. 关注点分离
D. 单一实现
4. 下面哪个功能是 IBM SOA参考架构中流程服务的功能 ?
A. 对已有的应用和功能进行封装
B. 对同构或异构数据源的访问
C. 将多个服务组合起来
D. 应用与用户之间的交互
5. 下面哪些信息是包含在服务注册中心(Registry )中的 ?
A . 服务端点信息
B .服务策略信息
C .服务代码
D .服务版本管理信息
6. 下面哪些是 ESB 所具有的功能?
A .注册中心
B .身份验证
C .消息转换
D .服务寻址
7. 下面哪些是总线结构的特点 ?
A. 易于管理
B. 单点发生故障将整体瘫痪
C .易于扩展
D .功能更多
8. 下面哪些是实施 SOA 的优势 ?
A. 可降低 IT 的灵活性
B. 可实现业务上的灵活性
C. 可提高集成的投资回报
D .可更新已有的 IT 设施
E .提高集成的 ROI
9. Web服务是 SOA 中实现服务的首选技术,主要是因为:
A. Web服务是基于标准的服务实现
B . Web 服务是面向消息的
C. Web服务是针对具体编程语言的
D. SOA和 Web 服务是等价的
10. 两个应用中都有 NOTEBOOK 一词,但一个是指普通的笔记簿,一个是指笔记本电脑, 这两个应用通过 SOA 集成时如何不会发生冲突 ?
A. 通过使用 XML 名字空间
B. 通过 SOAP 消息
C. 重新修改名称
D. 通过管理制度
11. 下面哪些关于 SOA 和 Web 服务的描述是正确的 ?
A . SOAP 文档是 XML 格式的
B. 服务的接口是通过 XML 构造和发布的
C. 服务的查找可以通过 UDDI 进行
D. 服务的消息传递是基于 SOAP 的。
12. 下面有关 SOAP 的描述哪些是正确的 ?
A . SOA中服务消息是 XHTML 格式的。
B . 服务使用者在发送服务请求时,相关的任何数据都可以通过 SOAP 消息来携带
C. SOAP消息是和具体的编程语言相关的
D. SOAP消息可以使用不同的底层协议进行传输
13.SOA 的 WSDL 定义了服务接口,可以实现如下的哪些目的?
A. 可以隐藏服务提供者的实现细节
B. 将服务提供者的具体位置暴露给使用者
C. 可以通过服务接口描述服务
D. 可以通过服务接口给出服务实现
14. SOA中,服务使用者要访问服务必须知道服务的 :
A. 接口
B. 所在的服务器地址
C. 注册中心地址
D. 组合方式
15. 下面有关 SOA UDDI Registry的描述哪些是正确的 ?
A. 通过 UDDI ,服务提供者可以动态发布服务
B. 通过 UDDI ,服务使用者可以方便地查找服务
C. 通过 UDDI ,服务管理者可以对服务进行集中式管理
D. 通过 UDDI ,可以取代 WSDL 来描述 Web 服务
16.SOA 的松耦合可以通过下面的哪些技术实现 ?
A. Web服务接口
B. 每次调用 Web 服务时先查询 UDDI 服务器
C. 使用 ESB
D. 强制规定不允许服务的实现有变化
17.SOA中,一个 .NET 环境下的服务被替换成新的 J2EE 环境下的服务,服务的功能和接口 没有变化,则 :
A. 使用者的代码不需要进行修改就可以使用新服务
B. 需要修改 WSDL 文件的内容才可以使用新服务
C. 必须将新的服务注册到 UDDI 服务器
D. 需要为新的服务提供一个转换适配器
18. 下面有关 WS-BPEL 的描述哪些是正确的 ?
A. BPEL可对业务流程的执行进行描述
B. BPEL可对交互协议进行描述
C. BPEL只是描述性文档,是不可执行的
D. BPEL用于指定基于 Web 服务的业务流程行为
19. 哪一个标准针对技术规范中说明不清楚的地方提供了一系列指导方针 ?
A . WS-Security
B . WS-Transaction
C . WS-BPEL
D . WS-I Basic Profile
20. 下面有关 WS-Security 标准的描述哪些是正确的 ?
A. WS-Security加强了 Web 服务的消息完整性
B. . WS-Security加强了 Web 服务的消息机密性
C . WS-Security 可取代现有的数字签名技术
D. WS-Security本身提供了加密算法
21. 一个 Web 服务由多个其他 Web 服务组合而成, 使用 BPEL4WS 描述该 Web 服务时, 可以 与什么标准配合起来进行描述 ?
A. UDDI
B. WS-Coordination
C. SOAP
D. B. XML Parser
22. 下面哪种情况需要使用 SOA 分布式安全模型 ?
A. 要支持端到端消息级别的安全性
B. 多个应用中可能有各自的身份管理,需要联合身份管理
C. 需要访问企业防火墙之外的其他服务
D. 需要隐藏服务的实现细节
23. 下面有关 SOA 事务处理哪些是正确的 ?
A. WS-Transaction是 Web 服务事务处理规范
B. 服务的操作应该是有状态的
C. SOA的松散耦合特性使得其事务处理更加复杂
D. 对会话上下文的维护会对 SOA 基础设施的性能带来很大影响
24. 下面哪种业务交互模式适合于 SOA?
A. 点对点
B. 集线器
C. 总线
D. 都适合
25. 下面有关 ESB 的描述哪些是正确的 ?
A. ESB中可以进行消息验证
B. ESB中可以基于消息的路由
C. ESB必须使用 XML 协议进行通信
D. ESB可以提供连接服务
26. 配置和控制 ESB行为的首选是:
A. Mediation
B. Service registry
C. Endpoint listener
D. outbound service
27. 下面有关 Mediation 的功能描述哪些是正确的 ?
A. Mediation侦听输入的 Web 服务请求
B. ESB中对消息进行路由是由 Mediation 完成的
C. Mediation允许对总线的消息行为进行定制等
D. Mediation使得服务使用者和提供者可以使用不同的通信协议
28. 一个 SOA 应用中, 希望在一个集中的地方对服务请求者的身份进行验证, 最合适的地 方是:
A .服务提供者处
B . SOAP 头
C .防火墙
D. ESB
29. 下面哪些不适合提取为服务 ?
A. 选书
B. 支付
C. 配送
D. 填写收货地址
30. 下面哪些适合提取为服务 ?
A. 填写订单
B. 处理订单
C. 执行订单
D. 退款
31. 进行面向服务的分析与设计时,可以将业务流程描述为:
A. 多个业务服务的组合
B. UML模型
C. BPEL模型
D. Java代码
32. 下面哪些工作应该在识别服务时完成 ?
A. 业务分析
B. 建立详细的设计模型
C. 业务流程分解
D. 将现有公共方法发布为服务
E. 将现有的应用封装进 Adapter
33. “先提取业务流程, 然后针对流程中的各种活动定义服务” , 该描述所对应的提取服务的 方法是:
A. A.自顶向下
B. B.自底向上
C. C.中间汇聚
D. D.中间分离
34. 下面哪些任务是在部署阶段完成的 ?
A. 将服务配置使用某种安全的协议进行通信
B. 对服务进行安全性管理
C. 将服务组装在一起
D .搜集安全性方面的需求
35. SOA生命周期治理中,服务的监控是在哪个阶段 ?
A. 建模
B. 组装
C. 部署
D. 治理
36. IBM的经验中, 公司以生命周期这一术语来思考 SOA , 这个生命周期从哪一阶段开始 ?
A. 建模
B. 装配
C. 部署
D. 治理
37. SOA生命周期治理中,服务的配置和安装是在哪个阶段 ?
A. 建模
B. 组装
C. 部署
D. 治 理
38. 在服务的建模和组装阶段,下面哪些描述是错误的 ?
A. 服务的建模和组装阶段可使用 BPEL 来组合服务
B. 在组合服务时,需要知道服务的 QoS 、位置等信息
C. 在组合服务时,需要知道服务的编程语言及运行环境
D. 在组合服务时,需要知道服务的调用方式
39. 企业如果没有 SOA 治理,会带来哪些问题?
A .当面临市场变化时,不能迅速调整业务加以响应
B. SOA项目中每个人的角色和职责可能不明确
C. 企业的商业战略和 IT 之间可能难以保持一致
D. 没有 SOA 治理,就不可能实现服务的复用
40. 几个 SOA 构件之间要传递机密信息,最佳的做法是 ?
A. 修改每个服务的实现,加入加密机制
B. 通过 SOA 治理将 ESB 配置为对所有的消息进行加密
C. 通过 SOA 治理不允许通过 Web 服务传递机密信息
D. 通过 SOA 治理对服务进行重新定义
41. 下面哪些是 SLA 中的 QoS 需求 ?
A. 安全性
B. 可靠性
C. 性能
D. 编程语言
42. 通过 SOA 治理,服务发生变化后,可以做到哪些功能 ?
A. 可以通过注册中心通知所有使用者
B. 可以跟踪到哪些业务流程会受到影响
C. 同一个服务可以同时保留不同版本
D. 可以对旧版本的服务有计划地弃用
43. 下面有关服务版本治理的描述哪些是正确的 ?
A. 没有版本治理就不能修改服务的实现
B. 服务实现修改后,如果增加了新功能,可使用服务版本治理
C. 服务的接口不能有任何变化
D. 服务一旦被使用者开始使用,就不能进行修改,以便影响使用者 44. 对于治理,下面哪些描述是错误的 ?
A. SOA治理是 IT 治理的扩展
B. IT治理将企业治理的原则用来对 IT 提供指导和控制。
C. SOA治理主要是一个技术问题
D. SOA治理的生命周期与 SOA 生命周期相互配合、同时运行
45. SOA治理定义阶段可以定义下面哪些度量指标 ?
A. ROI
B. IT成本
C. 部署 SOA 治理的基础设施
D. 当企业面临新的商业机会,企业的商业运作能快速调整
46. 下面哪些是实施 SOA 的推动因素 ?
A. 企业组织结构上将进行调整
B. 企业需要不断提供新的服务
C. 企业不存在竞争对手的压力
D. 企业业务将进行调整
47. 在考虑是否采用 SOA 时,下面哪些是正面因素 ?
A. 企业的 IT 平台维护起来比较复杂
B. 企业需要进行扩张
C. 企业面临着新的挑战和竞争
D. 企业没有集成的需求
48. 下面哪些是 SOA 可以提供的好处 ?
A. 使得服务可以复用
B. 提高业务的灵活性
C. 购买新的 IT 设施,使异构环境成为单一的 IT 环境
D. 简化并购时的集成工作
E. 可以充分利用现有的 IT 资产
49. 实施 SOA 可以带来哪些好处 ?
A. 有助于淘汰旧的应用程序
B. 有助于地理上的扩张
C. 有助于消除“竖井”型的结构
D. 利于企业兼并和并购
50. 在下面哪些场合,更可以体现 SOA 在提高企业的竞争力方面的优势 ?
A . 企业存在着并购的可能
B. 企业 IT 环境复杂,缺乏统一的平台
C. 企业经常需要进行新产品的展示
D. 企业各方面保持相对稳定
51. 通过 SOA ,可以得到以下哪些收益 ?
A .使得业务流程变得更加稳定不变
B .易于进行产品和服务的展示
C .提高竞争力
D .提高 IT 投资回报率
52. 下面对于 SOA 的优点的描述哪些是正确的 ?
A. SOA有助于实施“竖井” (Silo)型的应用
B. SOA可以提高业务的灵活性
C. 能够对业务流程的变更提供快速响应是 SOA 最重要的优点
D. SOA可以提高 IT 投资回报率
53. 下面对于业务灵活性的描述哪些是正确的 ?
A .通过 SOA ,当企业面临新的市场机会时,可以快速改变业务流程
B. 业务灵活性只通过企业管理即可实现
C. 通过 SOA ,不修改应用程序的逻辑就可以修改业务流程
D. 业务灵活性是指编程人员能快速编码,开发出新的应用系统
54. 下面有关 SOA 的适用场合的描述哪些是正确的 ?
A. SOA异步通信的特点使其不适合实时性要求非常高的场合。
B. SOA最适合同步通信的场景
C .如果响应时间要达到毫秒级,不适合使用 SOA
D. SOA适合于海量的事务处理
55. 下面关于 SOA 准备情况和风险评估的哪些说法是正确的 ?
A. 可以判断是否企业是否已经为 SOA 作好准备以及所存在的风险
B .只需要分析业务现状即可
C .可以一次性地将所有风险都调查清楚。
D. 对企业当前的状态和未来的面向服务业务模型之间的鸿沟进行分析 56. 下面哪种情形表明 SOA 准备情况较好 ?
A. 企业对各种变化做好了准备
B .软件的变化是受业务驱动的
C .企业不需要灵活的业务模型
D. 业务人员和 IT 人员没有什么交流
57. 下面哪种情况表明 SOA 尚未准备就绪 ?
A. SOA前景已经获得各个部门的认可
B . SOA 没有得到管理层的支持
C .业务人员和技术人员使用相同的术语进行交流
D. 业务和技术需要紧密配合
58. 下面哪些是采用 SOA 所面临的挑战 ?
A. SOA缺乏标准的支持
B. 难以找到服务提供者
C. 服务的粒度难以确定
D. 难以展现 SOA 的业务价值
59. 下面哪些不是采纳 SOA 的障碍 ?
A. 渠道合作伙伴的销售能力比较弱。
B. 发明新产品时对客户的实际需求进行调查 .
C. 冒险型的管理风格
D. 竖井型的组织结构
60. 下面哪些观念对实施 SOA 是不利的 ?
A. 和客户的沟通纯粹是浪费时间。
B. 当前的业务流程还能用,不需要进行的革新。
C. 不同产品部门之间应该通力协作。
D. 企业现有的产品应该保留而不是抛弃
61. “发现可外包的服务”描述的是哪个 SOA 切入点 ?
A. 人员
B. 流程
C. 信息
D. 复用
E. 连接性
62. 下面哪些 SOA 切入点是以业务为中心的切入点 ?
A. 人员
B. 流程
C. 信息
D. 复用
E. 连接性
范文五:面向服务的体系架构
面向服务的体系架构
第一部分:新方法的商业驱动力
第二部分:作为解决方案的面向服务体系结构
第三部分:近距离审视面向服务的体系结构
第四部分:面向服务的体系结构所带来的好处
摘自 IBM 红皮书《Patterns: Service-Oriented Architecture and Web Services》(sg246303)第 2 章第 1 节
Min Luo,Mark Endrei,Philippe Comte,Pal Krogdahl,Jenny Ang,Tony Newling
International Technical Support Organization,Raleigh Center
在这一节中,我们简要地描述了面向服务的体系结构的发展。然后,我们探究了面向组件的开发与面向服务的体系结构之间的关系,并且说明了如何将组件作为实现服务的基础设施。
1.1 第一部分:新方法的商业驱动力
虽然 IT 经理一直面临着削减成本和最大限度地利用现有技术的难题,但是与此同时,他们还必须不断地努力,以期更好地服务客户,更快地响应企业战略重点,从而赢得更大的竞争力。
在所有这些压力之下,有两个基本的主题:异构和改变。现在,大多数企业都有各种各样的系统、应用程序以及不同时期和技术的体系结构。集成来自多个厂商跨不同平台的产品简直就像一场噩梦。但是我们也不能单单使用一家厂商的产品,因为改变应用程序套件和支持基础设施是如此之难。
在当今 IT 经理面临的问题之中,改变是第二个主题。全球化和电子商务加快了改变的步伐。全球化带来了激烈的竞争,产品周期缩短了,每个公司都想赢得超过竞争对手的优势。在竞争产品和可以从 Internet 上获得的大量产品信息的推动下,客户要求更快速地进行改变。因而,在改进产品和服务方面展开的竞争进一步加剧了。
为了满足客户提出的越来越多的新要求,技术方面的改进也在不断地加快。企业必须快速地适应这种改变,否则就难以生存,更别提在这个动荡不安竞争激烈的环境中取得成功了,而 IT 基础设施必须支持企业提高适应能力。
因此,企业组织正在从上世纪八十年代或更早的时期的相互隔离的垂直业务部门,到上世纪八十年代和九十年代关注业务流程的水平结构,向新的生态系统业务范例发展。重点是扩展供应链,支持客户和合作伙伴访问业务服务。第 19 页的图 2-1 展示了企业的这种发展。
图 2-1 企业的发展
我如何使我的 IT 环境更灵活且更快地响应不断改变的业务需求呢? 我们如何使这些异构系统和应用程序尽可能无缝地进行通信呢?我们如何达到企业目标而不使企业走向破产的深渊呢?
IT 响应者/支持者是随着企业的这种发展而并行发展的,如图 2-2 所示。现在,许多 IT 经理和专业人员都同样相信,我们真的快找到了一种满意的答案——面向服务的体系结构。
图 2-2 体系结构的发展
为了减少异构性、互操作性和不断改变的要求的问题,这样的体系结构应该提供平台来构建具有下列特征的应用程序服务:
? 松散耦合
? 位置透明
? 协议独立
基于这样的面向服务的体系结构,服务使用者甚至不必关心与之通信的特定服务,因为底层基础设施或服务“总线”将代表使用者做出适当的选择。基础设施对请求者隐藏了尽可能多的技术。特别地,来自不同实现技术(如 J2EE 或 .NET)的技术规范不应该影响 SOA 用户。如果已经存在一个服务实现,我们就还应该重新考虑用一个“更好”的服务实现来代替,新的服务实现必须具有更好的服务质量。
1.2 第二部分:作为解决方案的面向服务体系结构
自从“软件危机”促进软件工程的开创以来,IT 界一直在努力寻求解决上述问题的方案。在过去几年里,下面简要概述的核心技术进展使我们走到了今天。我们将简要讨论这些核心技术,而我们重点关注的将是这些技术如何帮助解决 IT 问题。
1.2.1 面向对象的分析和设计
在“Applying UML and Patterns - An Introduction to Object-Oriented Analysis and Design”中,Larman 将面向对象的分析和设计的本质描述为“从对象(物体、概念或实体)的角度考虑问题域和逻辑解决方案”。在“Object-Oriented SoftwareEngineering: A Use Case Driven Approach”中,Jacobson 等将这些对象定义为“特点在于具有许多操作和状态(记忆这些操作的影响)的物体”。
在面向对象的分析中,这样的对象是用问题域来标识和描述的,而在面向对象的设计中,它们转变成逻辑软件对象,这些对象最终将用面向对象的编程
语言进行实现。
通过面向对象的分析和设计,可以封装对象(或对象组)的某些方面,以简化复杂业务场景的分析。为了降低复杂性,也可以抽象对象的某些特征,这样就可以只捕获重要或本质的方面。
基于组件的设计并不是一种新技术。它是从对象范例中自然发展而来的。在面向对象的分析和设计的早期,细粒度的对象被标榜为提供“重用”的机制,但是这样的对象的粒度级别太低了,没有适当的标准可以用来使重用广泛应用于实践之中。在应用程序开发和系统集成中,粗粒度组件越来越成为重用的目标。这些粗粒度对象通过内聚一些更细粒度的对象来提供定义良好的功能。通过这种方式,还可以将打包的解决方案套件封装成这样的“组件”。
一旦组织在更高层次上实现了基于完全独立的功能组件的完备体系结构,就可以将支持企业的应用程序划分成一组粒度越来越大的组件。可以将组件看作是打包、管理和公开服务的机制。它们可以共同使用一组技术:实现企业级用况的大粒度企业组件可以通过更新的面向对象的软件开发与遗留系统相结合来实现
1.2.2 面向服务的设计
在“Component-Based Development for Enterprise Systems”中,Allen 涉及了服务的概念,“它是将组件描述成提供相关服务的物理黑盒封装的可执行代码单元。它的服务只能通过一致的已发布接口(它包括交互标准)进行访问。组件必须能够连接到其他组件(通过通信接口)以构成一个更大的组”。服务通常实现为粗粒度的可发现软件实体,它作为单个实例存在,并且通过松散耦合的基于消息通信模型来与应用程序和其他服务交互。第 22 页的图 2-3 展示了重要的面向服务术语:
服务:逻辑实体,由一个或多个已发布接口定义的契约。
服务提供者:实现服务规范软件实体。
服务使用者(或请求者):调用服务提供者的软件实体。传统上,它称为“客户端”。服务使用者可以是终端用户应用程序或另一个服务。
服务定位器:一种特殊类型的服务提供者,它作为一个注册中心,允许查找
服务提供者接口和服务位置。
服务代理:一种特殊类型的服务提供者,它可以将服务请求传送到一个或多个其他的服务提供者。
图 2-3 面向服务的术语
1.2.3 基于接口的设计
在组件和服务开发中,都需要进行接口设计,这样软件实体就可以实现和公开其定义的关键部分。因此,在基于组件和面向服务的系统中,“接口”的概念对于成功的设计非常关键。下面是一些与接口有关的重要定义:
? 接口:定义一组公共方法签名,它按照逻辑分组但是没有提供实现。接
口定义服务的请求者和提供者之间的契约。接口的任何实现都必须提供所有的方法。
? 已发布接口:一种可唯一识别和可访问的接口,客户端可以通过注册中
心来发现它。
? 公共接口:一种可访问的接口,可供客户端使用,但是它没有发布,因
而需要关于客户端部分的静态知识。
? 双接口:通常是成对开发的接口,这样,一个接口就依赖于另一个接口;
例如,客户端必须实现一个接口来调用请求者,因为该客户端接口提供
了某些回调机制。
第 23 页的图 2-4 定义了客户关系管理 (CRM) 服务的 UML 定义,它表示为一个 UML 组件,实现接口 AccountManagement、ContactManagement 和 SystemsManagement。在这些接口中只有头两个接口是已发布接口,不过,后者是公共接口。注意,SystemsManagement 接口和 ManagementService 接口构成了双接口。CRMservice 可以实现许多这样的接口,但是它以多种方式行为的能力取决于客户端在行为的实现方面是否允许有大的灵活性。甚至有可能给特定类型的客户端提供不同或附加的服务。在一些运行时环境中,这样的功能也用于在单个组件或服务上支持相同接口的不同版本。
图 2-4 已实现的服务
1.2.4 分层应用程序体系结构
如前所述,面向对象的技术和语言是实现组件的极好方式。虽然组件是实现服务的最好方法,但是您必须理解的一点是,好的基于组件的应用程序未必就构成好的面向服务的应用程序。
一旦理解了服务在应用程序体系结构中所起的作用,组件开发人员就很有可能会利用现有的组件。进行这种转变的关键是认识到面向服务的方法意味着附加的应用程序体系结构层。第 24 页中的图 2-5 演示了如何将技术层应用于程序体系结构以提供粒度更粗的实现(它更靠近应用程序的使用者)。为称呼系统的这一部分而创造的术语是“应用程序边界”,它反映了服务是公开系统的外部视
图的极好方法的事实(通过内部重用并结合使用传统组件设计)。
图 2-5 应用程序实现层:服务、组件、对象
1.3 第三部分:近距离审视面向服务的体系结构
面向服务的体系结构提供了一种方法,通过这种方法,可以构建分布式系统来将应用程序功能作为服务提供给终端用户应用程序或其他服务。其组成元素可以分成功能元素和服务质量元素。第 25 页的图 2-6 展示了体系结构堆栈以及在一个面向服务的体系结构可能观察到的元素。
图 2-6 面向服务的体系结构的元素
注意:面向服务的体系结构堆栈可能是一个容易引起争议的问题,因为各方面的支持者已经提出了几种不同的堆栈。我们的堆栈不是作为服务堆栈提出的。我们之所以在此提出它,是因为我们想要搭建一个有用的框架,在本书的剩余章节中,我们将通过这个框架来组织对 SOA 的讨论。
体系结构堆栈分成两半,左边的一半集中于体系结构的功能性方面,而右边的一半集中于体系结构的服务质量方面。这些元素详细描述如下:
功能性方面包括:
? 传输是一种机制,用于将来自服务使用者的服务请求传送给服务提供
者,并且将来自服务提供者的响应传送给服务使用者。
? 服务通信协议是一种经过协商的机制,通过这种机制,服务提供者和服
务使用者可以就将要请求的内容和将要返回的内容进行沟通。
? 服务描述是一种经过协商的模式,用于描述服务是什么、应该如何调用
服务以及成功地调用服务需要什么数据。
? 服务描述实际可供使用的服务。
? 业务流程是一个服务的集合,可以按照特定的顺序并使用一组特定的规
则进行调用,以满足业务要求。注意,可以将业务流程本身看作是服务,这样就产生了业务流程可以由不同粒度的服务组成的观念。
? 服务注册中心是一个服务和数据描述的存储库,服务提供者可以通过服
务注册中心发布它们的服务,而服务使用者可以通过服务注册中心发现或查找可用的服务。服务注册中心可以给需要集中式存储库的服务提供其他的功能。
服务质量方面包括:
? 策略是一组条件和规则,在这些条件和规则之下,服务提供者可以使服
务可用于使用者。策略既有功能性方面,也有与服务质量有关的方面;因此,我们在功能和服务质量两个区中都有策略功能。
? 安全性是规则集,可以应用于调用服务的服务使用者的身份验证、授权
和访问控制。
? 传输是属性集,可以应用于一组服务,以提供一致的结果。例如,如果
要使用一组服务来完成一项业务功能,则所有的服务必须都完成,或者
没有一个完成。
? 管理是属性集,可以应用于管理提供的服务或使用的服务。
1.3.1 SOA 协作
图 2-7 展示了面向服务的体系结构中的协作。这些协作遵循“查找、绑定和调用”范例,其中,服务使用者执行动态服务定位,方法是查询服务注册中心来查找与其标准匹配的服务。如果服务存在,注册中心就给使用者提供接口契约和服务的端点地址。下图展示了面向服务的体系结构中协作支持“查找、绑定和调用”范例的实体。
图 2-7 面向服务的体系结构中的协作
面向服务的体系结构中的角色包括:
? 服务使用者:服务使用者是一个应用程序、一个软件模块或需要一个服
务的另一个服务。它发起对注册中心中的服务的查询,通过传输绑定服务,并且执行服务功能。服务使用者根据接口契约来执行服务。
? 服务提供者:服务提供者是一个可通过网络寻址的实体,它接受和执行
来自使用者的请求。它将自己的服务和接口契约发布到服务注册中心,以便服务使用者可以发现和访问该服务。
? 服务注册中心:服务注册中心是服务发现的支持者。它包含一个可用服
务的存储库,并允许感兴趣的服务使用者查找服务提供者接口。
面向服务的体系结构中的每个实体都扮演着服务提供者、使用者和注册中心这三种角色中的某一种(或多种)。面向服务的体系结构中的操作包括:
? 发布:为了使服务可访问,需要发布服务描述以使服务使用者可以发现
和调用它。
? 发现:服务请求者定位服务,方法是查询服务注册中心来找到满足其标
准的服务。
? 绑定和调用:在检索完服务描述之后,服务使用者继续根据服务描述中
的信息来调用服务。
面向服务的体系结构中的构件包括:
? 服务:可以通过已发布接口使用服务,并且允许服务使用者调用服务。 ? 服务描述:服务描述指定服务使用者与服务提供者交互的方式。它指定
来自服务的请求和响应的格式。服务描述可以指定一组前提条件、后置条件和/或服务质量 (QoS) 级别。
除了动态服务发现和服务接口契约的定义之外,面向服务的体系结构还具有以下特征:
? 服务是自包含和模块化的。
? 服务支持互操作性。
? 服务是松散耦合的。
? 服务是位置透明的。
? 服务是由组件组成的组合模块。
这些特征也是满足电子商务按需操作环境的要求的主要特征,如第 301 页“e-business on demand and Service-oriented architecture”所定义的。
最后,我们需要说明的是,面向服务的体系结构并不是一个新的概念。如图 2-8 所示,面向服务的体系结构所涉及的技术至少包括 CORBA、DCOM 和 J2EE。面向服务的体系结构的早期采用者还曾成功地基于消息传递系统(如 IBM WebSphere MQ)创建过他们自己的面向服务企业体系结构。最近,SOA 的活动舞台已经扩展到包括 World Wide Web (WWW) 和 Web 服务。
图 2-8 面向服务的体系结构的不同实现
1.3.2 SOA 范围中的服务
在面向服务的体系结构中,映射到业务功能的服务是在业务流程分析的过程中确定的。服务可以是细粒度的,也可以是粗粒度的,这取决于业务流程。每个服务都有定义良好的接口,通过该接口就可以发现、发布和调用服务。 企业可以选择将自己的服务向外发布到业务合作伙伴,也可以选择在组织内部发布服务。服务还可以由其他服务组合而成。
1.3.3 服务与组件
服务是粗粒度的处理单元,它使用和产生由值传送的对象集。它与编程语言术语中的对象不同。相反,它可能更接近于业务事务(如 CICS 或 IMS 事务)的概念而不是远程 CORBA 对象的概念。
服务是由一些组件组成的,这些组件一起工作,共同提供服务所请求的业务功能。因此,相比之下,组件比服务的粒度更细。另外,虽然服务映射到业务功能,但是组件通常映射到业务实体和操作它们的业务规则。作为一个示例,让我们看一看 WS-I 供应链管理(WS-I Supply Chain Management)样本的定购单
(PurchaseOrder)组件模型,如图 2-9 所示。
图 2-9 定购单组件模型
在基于组件的设计中,可以创建组件来严格匹配业务实体(如顾客
(Customer)、定购单(Purchase Order)、定购项(Order Item)),并且封装匹配这些实体所期望的行为的行为。
例如,定购单(Purchase Order)组件提供获取关于已定购的产品列表和定购的总额的信息的功能;定购项(Order Item)组件提供获取关于已定购的产品的数量和价格的信息的功能。每个组件的实现都封装在接口的后面。因此,定购单(Purchase Order)组件的用户不知道定购单(Purchase Order)表的模式、计算税金的算法、以及定单总额中的回扣和/或折扣。
在面向服务的设计中,不能基于业务实体设计服务。相反,每个服务都是管理一组业务实体中的操作的完整单元。例如,顾客服务将响应来自任何其他系统或需要访问顾客信息的服务的请求。顾客服务可以处理更新顾客信息的请求;添加、更新、删除投资组合;以及查询顾客的定单历史。顾客服务拥有所有与它管理的顾客有关的数据,并且能够代表调用方进行其他服务查询,以提供统一的顾客服务视图。这意味着服务是一个管理器对象,它创建和管理它的一组组件。
1.4 第四部分:面向服务的体系结构所带来的好处
如前所述,企业正在处理两个问题:迅速地改变的能力和降低成本的要求。为了保持竞争力,企业必须快速地适应内部因素(如兼并和重组)或外部因素(如竞争能力和顾客要求)。需要经济而灵活的 IT 基础设施来支持企业。
我们可以认识到,采用面向服务的体系结构将给我们带来几方面的好处,有助于我们在今天这个动荡的商业环境中取得成功:
? 利用现有的资产。
SOA 提供了一个抽象层,通过这个抽象层,企业可以继续利用它在 IT 方面的投资,方法是将这些现有的资产包装成提供企业功能的服务。组织可以继续从现有的资源中获取价值,而不必重新从头开始构建。
? 更易于集成和管理复杂性。
在面向服务的体系结构中,集成点是规范而不是实现。这提供了实现透明性,并将基础设施和实现发生的改变所带来的影响降到最低限度。通过提供针对基于完全不同的系统构建的现有资源和资产的服务规范,集成变得更加易于管理,因为复杂性是隔离的。当更多的企业一起协作提供价值链时,这会变得更加重要。
? 更快的响应和上市速度。
从现有的服务中组合新的服务的能力为需要灵活地响应苛刻的商业要求的组织提供了独特的优势。通过利用现有的组件和服务,可以减少完成软件开发生命周期(包括收集需求、进行设计、开发和测试)所需的时间。这使得可以快速地开发新的业务服务,并允许组织迅速地对改变做出响应和减少上市准备时间。
? 减少成本和增加重用。
通过以松散耦合的方式公开的业务服务,企业可以根据业务要求更轻松地使用和组合服务。这意味资源副本的减少、以及重用和降低成本的可能性的增加。
? 说到做到
通过 SOA,企业可以未雨绸缪,为未来做好充分的准备。SOA 业务流程是由一系列业务服务组成的,可以更轻松地创建、修改和管理它来满足不同时期的需要。
SOA 提供了灵活性和响应能力,这对于企业的生存和发展来说是至关重要的。但是面向服务的体系结构决不是灵丹妙药,而迁移到 SOA 也并非一件可以轻而易举就完成的事情。请别指望一个晚上就将整个企业系统迁移到面向服务的体系结构,我们推荐的方法是,在业务要求出现或露出苗头时迁移企业功能的适当部分。