面向服务的架构.docx

《面向服务的架构.docx》由会员分享，可在线阅读，更多相关《面向服务的架构.docx（21页珍藏版）》请在三一办公上搜索。

1、(一)基础：什么是BPM商业流程管理？CNET中国PC 类型:转载 作者: csdn 责编:小蝎 时间:2006-10-23 BPM是流程自动化的应用，帮助企业进行业务流程的分析之外，另可利用IT技术，自动化组织内各部门的原本以人力及公文传递的流程。 根据数据整合软件供货商Ultimus的定义，BPM主要精神在于管理企业的流程。除工作流程自动化系统之外，还必需提供企业应用软件整合（EAI）与交换的功能、流程成本效率评量与绩效管理，以及流程初始设计的模型最佳化工具，用以涵盖企业管理流程中所有的必要环节。 分析师建议，决定BPM工具之前，企业必须用严谨的态度检讨目前使用的软件，决定业务角色的授权，

2、权衡数据模型（data model）与分析工具（analytical applications），并建立未来采用BPM后的假想情境。 目前包括IBM、微软、BEA也努力催生商业模型标准，联合起草网络服务（Web Services）商业流程执行语言（BPEL4WS）。业界相信，先建立商业流程模型，再从这些流程模型中建立应用程序进而监视这些模型，将有助在企业内部的IT部门与业务主管之间建立起环环相扣的自动化流程（二）体系架构蓝图-SOA和BPM的合并CNET中国PC 类型:投稿 作者: BEA 责编:小蝎 时间:2006-10-23 面向服务的体系架构（Service-oriented archi

3、tecture，SOA）已经成为软件工程中一个最重要的主题。无疑，随着Web服务的推广和广泛接受，以及支持基于SOA解决方案开发的case风格的IDE这一新浪潮的兴起，SOA已经成为构建企业级分布式应用程序的首选蓝图。与此同时，业务流程管理（business process management，BPM）作为操作灵活的新企业并为其建模的主要支持者，正在强力反弹。 面向服务的体系架构（Service-oriented architecture ，SOA）已经成为软件工程中一个最重要的主题。无疑，随着Web服务的推广和广泛接受，以及支持基于SOA解决方案开发的case风格的IDE这一新浪潮的兴起，

4、SOA已经成为构建企业级分布式应用程序的首选蓝图。与此同时，业务流程管理（business process management ，BPM）作为操作灵活的新企业并为其建模的主要支持者，正在强力反弹。基础结构厂商已经使BPM成为他们出售的系列产品的主要组件，瞄准机会的厂商使用专用的BPM系统提供垂直的业务解决方案，纯使用BPM的厂商正在得到更加广泛的接受。 尽管两种趋势均显露出了征兆，它们的趋同现象仍不明显，而且关于这种现象没有统一的看法。它们是互补的表示法吗？它们会重叠吗？我该如何一起使用它们？这样做有没有另外的优点？此外，为什么80年代末期的企业流程重构（BP reengineering）失

5、败了，而第三次BPM浪潮却将要取得成功呢？ 在这一系列三篇文章中，我将解决这些问题。首先，我将讨论一个体系架构蓝图的最佳实践如何将面向服务体系架构与BPM框架合并，从而为构建健壮的企业级集成解决方案并对其建模提供可重复的方案。我描述了为什么在当今，任何使用技术支持其任务陈述需要的企业比以往更能拥有合适的体系架构蓝图。最后，我讨论了什么是实时交易的挑战，以及BPM方法如何能够实现企业灵活性、智能企业建模、系统开发和以客户为中心的运作优点。 在第二篇文章中，我将应用BPM技术来为一个支持“用于汽车保险”业务场景的软件解决方案建模和设计体系架构。我将讲述两种设计：一种纯BPM设计和一种混合型设计。我

6、还将讲述一些新兴的建模工具和标准，并讨论一些建模和各种体系架构选择和策略方面的难题。 在第三篇（也是最后一篇）文章中，我将使用BEA的WebLogic Platform 8.1 构建一个POC。我将讨论BEA的IDE新引入的可视化编程范型及其优缺点，和构建完全分布式的企业级应用程序所需的一些技术。我还将解释，为什么流行的请求/响应模式的WEB协议与基于事件的流程建模，以及它在进行架构决策时的意义不一致的原因。 体系架构模式 谁需要它们? 软件工程是艺术还是科学？在科学中，我们有明确的定义、定理和证据。在艺术中，我们有工具和技术、趋势以及最佳实践。科学中提出了一些假设，其中一些变成定理，另外一些

7、在经过数个世纪的研究之后得到验证，还有一些永远没有答案。在艺术中，新技术带来新的趋势，比如新闻和数字摄影。如果软件工程是一门科学，定义我们在日常业务语言中使用的所有术语不应该是一件困难的事情，像服务、Web服务、面向服务的体系架构、BPM和BPM系统（BPMS）。的确，我可以利用数学精度来证明一个数据库查询算法的正确性。但是，我能够以一种干脆、简洁且通常会被接受的方式来回答，J2EE中的B2B集成是与纯.NET Web服务解决方案相对的正确答案吗？据我了解，对于我们中间的一些人来说，这不是问题。最后，任一种常见的贸易出版物的随机调查指出，每个人都可以给出自己的定义，而有些人甚至质疑IT存在的本

8、质。我不得不得出结论，软件工程仍然是艺术多于科学。这正好是我们需要合适的最佳实践、框架和可重复过程的原因。 模式封装了最佳实践，简练地定义了域问题，描述了使问题值得关注的原因，并提出了解决方案。模式并没有解决独特的问题。专业人员结合各种模式来解决更为复杂而且有时更为独特的问题。Christopher Alexander说：“模式同时也是发生在世界上的事件和告诉我们如何创建该事件的规则，以及我们必须创建它的时刻。它既是过程，也是事件。”我回想起我一直以来最喜欢的定义：对象是带有状态或数据及行为的数据结构。就目前来说，可以把Web服务看作带有一个方法的对象。就像BEA WebLogic Platf

9、orm 8.1所实现的那样，会话式Web服务看起来更像是真正的对象：对它进行一次初始化，然后一直执行方法。万一您仍然不能肯定Web服务是粗粒度的对象，考虑：(1) IBM、BEA和 Microsoft宣布了WS-Eventing规范。它就像是优秀但老式的对象观察者模式。(2) 开放式网格服务体系架构（Open Grid Services Architecture）实现了网格服务协议的Web服务接口继承。因此，Web服务提供数据和行为（Alexander的定义中的事件和规则），而BPMS 实现模式的流程组件。SOA是一个用于解决企业集成和系统开发问题的体系架构模式。 我们已经看到，SOA不是体系

10、架构趋势的革命，而是它经过一段时间发展的演变成果。它围绕为企业构建分布式系统而发展。诚然，Web服务以一种普遍接受且无二义性的方式提供底层技术，以解决系统连接性问题。也许是头一次，Web服务成功地解决了互操作性的问题，而这是 CORBA、COM、 DCOM和 RPC 做梦也从未想过的事情。我肯定，作为中立语言，XML对此也准备一展身手。然而，SOA中包括进来的BPMS框架是一个新的、革命性的元素。Howard Smith 和Peter Fingar 描述的第三次浪潮是指一组全新的概念、框架和主流产品。它正在显著改变企业转化的方式，从而灵活地管理和运行全局的和协作的电子商务实体。 业务流程管理的

11、出现已经有一段时间，它更多地用于工业中，而与IT无关。并发工程和六西格玛被开发用来解决生产和流程改进中的及时协作问题，并且确实取得了相当的成功。然而，在80年代晚期，出于多方面的原因，业务流程重构管理获得的成功非常有限。但是最根本的原因是，重构是纸上谈兵。没有软件来支持这样一个复杂的任务。BPM在没有考虑IT系统的情况下设计了自适应的企业。正如David Taylor 所写： “对连续性流程优化的需要要求从根本上重新考虑如何设计和构建信息系统。提出解决固定问题的固定解决方案已经不再够用。” 信息系统，像它们支持的业务模型一样，必须在本质上就是自适应的。 Taylor提出一种基于OO的开发技术，

12、作为开发自适应IT的一种方法，这种技术称为聚合工程（convergent engineering）。然而，OOP无法成功解决分布式计算和企业集成的问题。另外，负责对企业建模的业务分析人员也没有采用OO。 BPMS将流程建立为用于建模、软件设计和运行时执行的统一结构。过去，开发趋势一直在影响我们对企业建模的方式。功能式编程使功能需求技术流行起来。关系数据库带来了RDBS分析和设计的流行。面向对象的编程则为OO分析和用例开发铺平了道路。但是在大多数情况下，业务分析人员不会使用开发专门术语，因此产生了对需求可跟踪性中通常影响的另一种翻译的需要。 BPM规范正在快速演变为标准。市场中已经出现了支持业务

13、建模、优化和运行时执行的产品。正如BEA的WebLogic Platform 8.1和其他BPMS产品所实现的那样，以流程为中心的BPMS 方法用于系统开发生命周期，它消除了对运行时阻抗不匹配的业务需求。 灵活的企业拥有自适应的业务和自适应的IT系统。如果构建企业解决方案的过程中出现一个新的问题，那么它一定是需求变化的速度。它的速度之快是前所未有的。BPMS引擎添加了一个新的层到传统的开发堆栈（参见图1）中，并引入服务质量来解决企业集成中的根本问题。BPMS引擎使编程最易变的部分集成点的软布线变得容易。软布线是以正式语言显式描述的，并由BPMS引擎（又名有限状态机引擎）执行。正如BEA Web

14、Logic Integrator和其他BPMS产品所实现的那样，业务与IT资源可以同时在一个可视化的只能IDE中查看和修改流程。只需轻击鼠标，便可部署到运行时BPMS执行引擎。业务模拟可以运行，而性能工程可以在系统完成之前完成；这种方式听起来就像CASE工具。SOA和BPMS工具将灵活企业的实时执行仪表板带向主流。（图01） 在本文余下的部分中，我将描述一个典型的金融服务企业的开发，并提出一条通向基于BPMS的SOA的迁移路径。该路径是增量的，但是它需要战略思考和对未来远景的承诺。作为回报，它将允许投资的早期回报，并将遗留企业转化为完全自适应的灵活企业。 从企业远景到组织筒仓（Silo） 企业

15、从远景开始。CEO和董事会采用远景和行业使命陈述。C级管理人员定义策略，并适当地安排流程来管理执行（参见图1）。定义功能角色和责任，然后创建企业界线。业务分类（Line of business，LOB）在本质上可以是水平或垂直的（参见图2）。垂直LOB具有以下特征： 独立的操作域。 特有的管理和策略。 开发和维护自己的IT自动化孤岛。 足够大以至于可以创建多种业务分类；例如，抵押贷款证券、市政公债、货币市场，等等。（图02）水平LOB具有不同的特征集合： 提供业务控制。 管理的支配和一致。 需要访问由垂直LOB管理的数据。 合适的手动流程和书面报告。 在第二个信息纪元（不要与第二次浪潮混淆）中

16、，我们使用了各种编程技术来链接自动化孤岛，从FTP、数据库复制、EAI和消息收发开始。此方法产生了一整套新问题： 接口的多重性: 一份Morgan Stanley Dean Witter报告表明，通常的金融服务客户需要维护6000个接口，为此每年花费2500万美元，而且每年还需构建900个新的点到点接口，为此需另外花费2500万美元进行构建，并且还要花费400万美元进行维护。 调停流程: 必须在每一个仓库上实现，需要消耗有价值的时间和昂贵的资源。这是一项常用技术，用于检验由多个实体修改的引用数据。 流程: 在中间件中进行硬布线。在分析过程中捕捉流程所花费的时间和金钱属于浪费。企业最重要的资产流

17、程隐藏在n(n-1)个意大利面式接口的迷宫中。 开发新的水平流程：需要多个LOB 的协调。 实现特定和专用的接口：需要专门化和一次性编程。重用消失，维护方面的投入显著增加。 异常难于跟踪： 错误解析通常需要访问多个系统。人工干预和解释是不可避免的。找寻答案需要花费大量宝贵时间，并对客户满意程度和收益性方面的大致情况有着直接影响。 流程无处不在。您能发现它们吗？ 对于企业来说，流程可以是客户层面上的，也可以是内部的，或者可以是更大流程的组成部分。我们在同样的企业中可以找到内部流程。流程通常涉及到人与系统的交互，或者只是系统之间的交互（参见图3）。交易流程是大规模流程的一个很好的例子。行政管理部门

18、的交易人员在他的销售订单系统中接收一个来自对冲基金管理人员的交易执行命令，或者他接到一份传真或一个电话。交易人员检查库存系统的安全性或资金，并借助他的交易对手执行交易。可以制造纸质入场券，而交易助手可能必须在下行系统中进入它。（图03） 当因为下行系统之一错误地再进入，而帮助台分析人员收到一份异常报告时，另一个内部流程启动了。然后，他在内部记事薄之一中查找数据（原始进入记录），请求来自事务部门的传真（我们假定讨论的交易超过了结算日期），而且因为他在两天内没有收到回复，也许他会再次重复同样的行为。这个流程最终当分析人员解决了问题时终止，当然，除非他调到另一个部门或者调出公司。然后，顾问们必须参与

19、进来，跟踪问题和流程，这通常需要一大笔钱。 每月的客户声明是定期性企业范围内流程的一个传统例子，通常为水平LOB所特有。在大多数情况下，客户在被不同LOB支持的产品中拥有帐号，例如，股票、U.S.证券和外汇。在月末发送多个声明将会十分混乱。法律和一致性问题还需要交叉引用多个仓库的数据。Patriot和 Sarbanes-Oxley Acts (一个新的业务流程，但是不赚钱)的一个主要问题是要访问由大量LOB所拥有的数据，有时还要环绕半个世界。EAI技术和消息收发试图借助早先阐明的限制解决这些问题。 通向灵活性的道路：以BPM为中心的SOA 让我们考虑带有Web服务的、以BPM为中心的SOA如何

20、将现有的遗留企业转换为自适应性的企业。水平流程和异常管理是用于SOA启用的理想候选者，可以演示可调整的和速度快的ROI。没有经历业务流程再造的严谨，我们必须定义良好的流程图。流程图也是实行业务流程重新设计的第一步。如果使用BPMS 设计工具(Proactivity, Intalio, Interfacing Technologies)，您可以把度量关联到流程和行为，例如，性能、开销、IT资源、FTE、逝去的时间、容量，等等。许多BPMS设计工具允许您运行模拟，并继续进行流程优化（运行what-if场景），但是这并非本文的重点。对于我们的重点来说，以下列出的是良好流程图的一些特征： 考虑流程而不

21、是功能 : 流程告诉您完成什么工作以及如何完成。功能描述谁在哪里来完成它。 从客户的观点出发： 考虑从外部业务事件开始的流程，例如，一次交易、一份订单、一个主张、一个报价请求。 在更宽泛的意义上并基于不同的服务质量来划分客户类别： 您生态系统中的性能、供应商、业务伙伴。 流程反映状态变化：交易订单、现金支付。从可管理的流程数量610开始。记住，大多数人最多只能保留一个页面上的七样东西。 定义核心流程和子流程：这里没有科学理论，只有最佳实践。然而，要当心P-calculus2 和Petri-nets；它们将在接下来的10年内带给BPM科学的严密性。 将流程分解为行为 下一个目标是通过分解行为来定

22、义小单元。我们将这项工作称为Elementary Business Services (EBS)。如果您从多维矢量代数开始回想，空间中的任意一点都可以被定义为单元矢量的线形组合。在我们的例子中，我们以可以通过编排EBS子集来构造任何流程的方式定义了所有EBS。正如您可能猜想的那样，我们将EBS实现为Web服务。识别EBS的正确集合和粒度水平很重要。这与设计对象的重要程度相同。相同的规则和技术封装、状态相关性、内聚性、松散耦合和重构同样适用，这并不使人惊奇。 EBS的业务量体现出了大量实际优点： 1. 它是要重用的最终指南。可以通过任何想像得到的方式编排EBS，以形成新的LOB。 2. 连续性流

23、程改进不必等到IT适应新的业务模型。 3. EBS对企业生态系统中的企业和业务伙伴可用。 4. 放弃使用一个系统并不是一个一蹴而就的过程，而是一个循序渐进的过程。 5. 可以以一种易于管理且性价比高的方式合并和获得IT。 6. 可以几乎实时地设计和执行一个新的业务流程。 从图4中可以看出，我们可以使EBS在BEA WebLogic Platform 8.1（集成组件）的一个实例中可用。从技术上说，在BEA WebLogic Integration中，Web服务被称为业务流程资源。我们使用IDE编排新流程，使用门户添加UI，然后将它部署为一组EJB来执行。就是这么简单！现在流程是一项IT资产了，

24、就像数据库表、存储过程、遗留COBOL书籍和专用的计算c库。（图04） 许多金融服务机构的业务分类是水平的，管理高净值的私有客户。在启用了BPMS SOA的企业中，开发IT基础结构来支持这样的新LOB完全可以与正确放置业务模型并行完成（参见图5）（图05） 考虑A 现象，它们并没有创造任何新的EBS。所有EBS位于任何其他邮件订单一览表书店中的恰当位置：定购书籍，检查库存，信用卡付帐，打印声明，准备装运，给客户发送电子邮件。但是它没有创建新流程，没有质疑已经建立好的流程，甚至不用花费什么力气。 正如Howard Smith 和 Peter Fingar所说的那样：“在BPM的第三次浪潮中，筒仓

25、式思考和点到点的技术集成被灵活的、基于业务流程的体系架构所代替。”此外，Gartner Group 现在声明，继续将业务逻辑硬布线到软件或中间件中或者坚持人工步骤的公司将输给部署流程管理体系架构的竞争对手。 实时处理业务 退一步说，预测将来是很困难的事情，但是我们用非常科学的态度对待它，而且始终试着这么做，不管对还是错。统计和预测是关于预测将来的两门科学。投资组合评估和保险统计研究是有关预测的科学。实际上，我们的预测仅仅基于我们已经经历过的、过去的性能和趋势。实时处理业务需要预测未来的业务情况。然而，基本的业务协议和框架必须合适。今天，技术革新、BPMS和SOA是将业务目标与IT相结合的基础。

26、流程提供一个封装了变化的新层。90年代早期，PowerBuilder和VB风格的工具使客户端/服务器和关系数据库系统的开发流行开来，通过与此相同的方式，BPMS引擎将在未来建立流程驱动的企业。事实上我预测，在我们的一生中，我们将看到对运行时流程的需求，该类流程用于实时变化或对自修改流程的需要。无疑，人类希望能够掌管该类变化，但是通过使用UDDI- ( 代表流程)找出最可能的服务契约和使用描述域专业知识和市场情况的规则进行决策，BMPS能够使这项工作更加容易。随着BPMS的普及，灵活性将被极端自适应所代替。结束语 在本文中，我描绘了合并SOA和BPM的蓝图。从一幅企业的自顶向下流程图开始，我们定

27、义了基本业务服务的组合选择。垂直LOB拥有并部署EBS。Web服务实现它们，并使它们对企业可用。通过使用BPMS引擎的一个实例，可以设计、开发、测试新的流程，并通过结合现有的EBS，在数日内添加业务值。 在我的下一篇文章中，我将：(1) 讲述用于给现实世界业务保险流程建模的BPM技术，并提出一个纯BPM解决方案和一个混合解决方案；(2) 使用Web服务和JMS连接设计EBS并实现它们；(3) 提出一个使用WebLogic Platform 8.1的物理基础结构；并 (4)讨论面向服务体系架构中的BPMS难题和新出现的模式。 直到：流程无处不在。您能发现它们吗？(三)简单到复杂，BPM技术促进S

28、OA发展CNET中国PC 类型:转载 作者: 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把业务流程视为独立于应用程序及其运行的

29、平台的可复用组件。 从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。 除平台提供商以外，开源厂商也试图占领

30、拥有自己的SOA却缺乏服务的市场。JBoss公司在2005年10月发布的企业过程管理引擎，围绕业务过程执行语言（Business Process Execution Language BPEL）提供了一种可插拔的体系结构、扩展的任务管理以及新的可扩展性。BPEL虽然是用来编排Web服务的，但依然适合用来集成，而不是深入的业务逻辑。 BPM无论从技术还是方法上都将促进SOA的发展。在此过程中，大型平台厂商IBM、BEA、SAP、Oracle等将会尝试建立一种新SOA标准；而开源厂商努力构建一套工具，不把自己禁锢于用一种方法构建SOA。 从BPM的IT需求与SOA技术角度上看，BPM与SOA的融合

31、也具有先天优势。BPM的范围覆盖了企业运营的各个环节，如生产、销售、物流、财务等企业经营活动，甚至延伸到供应商和经销商。其产品开发包括6个部分，从基础开始为：开发语言，如BPEL、Java等；BPM服务器，包含EAI/BPM平台产品；BPM工具，包括用户接口工具、过程建模工具、软件需求工具等；BPM套件；BPM知识架构；BPM系统和其应用。由此可见，BPM的IT需求与SOA技术具有以下相似点： 1BPM涵盖范围广泛，需要完成因事件触发的完全不相干的事件，此特点正与SOA的松散耦合特点相吻合。 2BPM需要多部门、区域的协同。在此中环境中网络环境的安全性可由SOA技术构架中的WS-Securit

32、y、LDAP(Lightweight Directory Access Protocol-轻量级目录访问协议)、PKI(Public Key Infrastructure-公钥基础设施)架构和数位签章等机制来完成。 3BPM系统构成元素种类繁多而复杂，包含分布于各模块的企业逻辑和规则。而SOA可以看作是B/S模式、XML/Web Service技术与管理软件的延续。 当前多数SOA环境能提供系统管理工具给系统管理员使用，协助管理SOA架构下模块的安装、移除、启动等。目前能够实现SOA的产品包括：Microsoft Biztalk Server, webMethods Business Inte

33、grator, IBM SeeBeyond, TIBCO和Vignette。在SOA提出以前，大部分BPM产品在流程图中采用自有定义流程逻辑。 4企业BPM系统的实施往往从最简单的开始，逐渐提升为复杂的BPM系统。而SOA模块化的特性正好吻合了此特性。 (四)分析:BPM与SOA之间的区别及联系CNET中国PC 类型:转载 作者: newhappy2008 责编:小蝎 时间:2006-10-23 关于业务流程管理(BPM)和面向服务架构(SOA)之间关系的讨论热闹非凡。二者也是多年来的热门话题，但是关于它们的讨论通常都出现在互不相关的论坛上，讨论它们的人通常也属于不同的圈子。不过现在这种情况正

34、在改变，因为这两个概念以及相关技术的使用者和提供者正日渐将二者结合起来看待。 BPM阵营通常声称，SOA对于实现BPM来说不是必需的。只需部署一个BPM套件，就可以更快地实现目标而不会带来多少复杂性。SOA阵营则注重于如何从一般意义上解决企业IT的复杂性。该阵营通常声称BPM是SOA的一个特性，但是它是SOA解决方案的一部分，而不是一个单独的东西。当SOA领域的人士谈到BPM时，该术语通常与服务编排或流程整合同义，而不强调对业务分析人员友好的建模或人员交互，而后者对BPM阵营来说非常重要。 为了澄清这些误解，我认为有必要阐明BPM与SOA的不同本质:SOA是一种架构方法;BPM则是一组协调活动

35、。 因此，可以很容易地得到使用SOA或不使用SOA的BPM，反之亦然。我们来看看不同组合的优点。 如果部署一个不使用SOA的BPM套件，则可以获得快速创建、执行和监控/管理业务流程的能力。业务流程的模型可以由业务分析人员创建，但是其完整实现则需要与底层IT系统的集成(以及定义用户如何与该流程交互，但是现在我们暂不考虑)。BPM套件(如BEA的AquaLogic BPM Suite)支持使用各种不同的技术(面向服务的或不是面向服务的)对应用程序和数据库进行轻松访问。实现由代码和来自于并依赖于底层系统接口的元数据组成，因此，对底层数据库和应用程序的任何更改都将导致对业务流程的更改。 如果组织和IT

36、环境规模比较小，并且由同样一组人来控制所有的系统(包括BPM套件)的话，这是完全可以的。如果底层系统完全不更改的话，这种方法同样运行良好。 但是，如果BPM套件由一个小组部署，并消费来自另一个小组的系统的服务，那么协调和管理每个小组中的更改的任务很快就会变得非常困难。这是SOA要解决的典型问题，因此，SOA可以应用于BPM套件的部署，就像应用于其它地方一样。 如果BPM作为SOA的一部分进行部署，这意味着当一个业务流程连接到底层系统时，它连接到由企业服务总线所提供的代理服务，这样就隐藏了底层应用程序和数据库的复杂性。这具有以下优点: 将业务流程连接到系统的过程会更简单，因为IT可以公开更有用的

37、接口，比如聚合的数据服务或使用标准协议而不是专有协议的服务。这减少了实现流程所需的IT工作量，并允许流程人员将精力集中于流程，而不是粘合流程与底层系统所需的技术。 它使得实现更为健壮，因为对底层IT系统的更改不必影响流程所使用的接口。 它在BPM套件之外提供了一个独立的控制和管理层。这允许IT小组更好地管理他们所拥有和维护的服务的策略和资源。 SOA还支持从BPM套件中获得对它所连接到的系统的更好可见度。IT小组可以在服务注册库中注册服务，流程开发人员(甚至可能是业务分析师)可以在构建流程时浏览这样的注册库。这确保了服务可以被正确地使用和重用，而且通常简化了业务流程，因为使用正确的服务可以将流

38、程本身的复杂性降至最低。 无疑，这些优点只有在IT基础架构足够复杂，并且/或者BPM项目达到一定的范围和规模时才能显现出来。因此，在很多情况下，应该首先开发出BPM，而将SOA组件留待以后考虑。 最好的方法是一开始就让业务运作团队和IT企业架构小组保持良好的对话，并针对未来进行规划，同时支持战术性执行。这就需要正确地组合产品。例如，BPM套件本身应该能够提供丰富的连通性，以便无需全面应用完善的SOA来使得BPM运行，这一点非常重要。类似地，BPM套件应该支持SOA，这样BPM与SOA才不至于存在于独立的竖井中，这也很重要。 (五)OASIS总裁Patrick Gannon谈SOA与开放标准CN

39、ET中国PC 类型:转载 作者: Cnet 责编:小蝎 时间:2006-10-23 Patrick Gannon：今天来给大家介绍一下SOA 对产业的一些好处和标准对产业的一些影响。这一页是我的简单介绍。主要介绍一下开放标准和SOA 对公司的发展有哪些影响。今后的电子商务将会搭建在SOA 的平台上，现在SOA 和开放标准还处于初期阶段。这一页幻灯片是介绍了一下SOA 的基本情况。为了达到SOA 所承诺的前景，需要建立一个共同的框架体系和标准体系。公司要在SOA 投资，必须要获得一些收益，这样保证他们的资产有更好的流动性，也保证他们的资产有长期保值的能力。所谓流动性就是灵活多样的意思，也就是说S

40、OA 的标准体系和核心技术要能够满足各式各样应用的需求。SOA 很重要的特性是能够让你对软件的投资有长期的保值性，能够避免重复投资，可以让你的软件模块可以重复地使用。 为了达到这些目标，有一些很基本的工作需要做。我们必须要有一个共同的体系结构和一套共同的词汇表，大家都知道每一个软件的变量代表了什么意思。现在的问题是各个行业一些主要的技术厂商，他们看的都局限于他们这个行业或者是自己的技术体系来考虑整个软件应用的问题。这个问题是不同的词汇表，不同词汇的意义和不同的表示方法都对使用软件技术的发展带来了障碍。我们的解决方法是什么？在商业业务层面创造互操作性。 其中一个方法是实现跨部门的应用互动和应用的

41、集成。为了达到这个目标，开放标准是其中一个很重要的措施。很多公司问为什么我们需要标准？我们看到为了建立标准体系需要很多的投入，一个标准组织就是为了让业界的企业一起共同做标准的工作，降低大家分头做标准的成本。软件公司需要知道他们做什么标准、同时应该了解标准是怎么产生的，通过什么样的方式使标准有一个基本的接受情况。我们请了Delphi Group Research 做一个标准的调研，看整个企业对标准的认识，和目前对标准研究的看法。有三个重要的调研结果。采用开放标准使得企业的软件可以重复使用，数据也可以在不同的平台上进行共享。第二个结论是采用了开放标准，企业的研发工作可以在更大的协同范围，甚至是摄入

42、最终用户来进行共同的开发。我们看到开放标准对于Web Service 的使用是非常重要的。 OASIS 是一个国际标准组织，主要是针对先进的结构化数据的信息标准。OASIS 不光只是研究和产生标准，同时也跟其他国际组织一起合作来推动标准的采用和技术的发展。OASIS 有一个非常开放的组织结构，可以让会员很容易在组织里面表达自己，目前有650 个不同的企业会员，来自80个国家。OASIS 在Web Service 、电子商务、eBusiness 和文档管理方面是目前世界上权威的标准组织。通过13年的努力，OASIS 已经得到广泛的承认，OASIS 不仅可以直接向国际标准组织、国际电联和联合国相关

43、标准组织直接提交标准提案。 OASIS 不光只是由技术厂商参加的标准技术组织，实际上有35的成员来自于客户，也就是说可以对甲方有影响力的部门，还有大概15的研究单位。OASIS 也是一个发展很快的组织，我来中国很重要的目的是希望能够参与快速发展的亚太地区的经济活动。 这是OASIS 在亚太地区目前的成员，这是在大陆地区的会员成员，我已经参观过了书生、长风联盟和神州数码，以及互联网中心。根据我这个星期在这边的感觉，我认为很快会有更多的公司参加OASIS 这个组织。我邀请大家能够参与OASIS 这个组织。 OASIS 是为SOA 和Web 服务的发展提供重要的指导作用。OASIS 的工作覆盖了SO

44、A 和Web 服务一些非常重要的领域。这是OASIS 在SOA 和Web 服务里重要的领域和技术工作组所覆盖的一些SOA 和Web 服务的重要领域。OASIS 不但是推动标准的研发和发布，也推动标准的全面采用。OASIS 是有25个技术委员会在SOA 领域里展开技术的研究工作。对于公司对eBusiness 有兴趣的公司，有一个商业编排工作组。标准、访问权限控制也是OASIS 在SOA 和Web 服务领域里的重要工作。 Web 服务的管理也是我们一个很重要的技术研究工作。可靠的消息传输也是我们的工作之一。这是UDDI部分的工作。你们看到在OASIS 里对SOA 和Web 服务做了大量的研究和标准

45、建设工作，这也是很多公司参加OASIS 的直接目的。大家都知道当一个公司在新技术方面做投入时都会涉及到一个潜在的风险。SOA 可以帮助公司降低采用新技术的风险。企业今天可以做什么呢？一个是可以参加OASIS 组织，或者是可以观察、了解一下OASIS 组织能做什么。因为这些标准都是在全世界推广和采用的，所以非常重要的是要让在中国的软件企业或者是中国的最终用户能够对他们的技术需求和他们的一些要求很明确地表示出来。表示出来以后，能够影响标准的产生，而且标准是在全球范围内推动的。其中软件公司在OASIS 的工作是提出新的研究方向。其中一个例子就是书生公司已经在上个星期提出了UOML在OASIS 里立项。我相信肯定有很多其他的公司可以把他们创新性的技术提案通过OASIS 这个平台建立起来。对于小的公司，没有很多钱来参加像这种标准组织的话，也可以多看一看标准组织能不能对你们的市场活动带来好处。 除了标准的研究工作以外也跟很多组织合办活动，把会员的一些技术在更大的范围里展示。对于最终客户来说，OASIS 对他们也有很多好处。对于最终用户如果能够把他们对技术的需求明确提出来之后，可以在明确的过程中考虑进去。OASIS 有很多会员是政府部门，这些政府部门参加的原因是他们希望观察标准的研究情况，