SOA技术研究报告.doc

科 学 技 术 研 究 工 作 报 告基于SOA的数据仓库架构张芳宁V1.0青岛大学邵峰晶教授科研梯队 2010年 04 月 28 日文档修订记录版本编号或者更改记录编号*变化状态简要说明（变更内容和变更范围）日期变更人批准日期批准人*变化状态：A增加，M修改，D删除，N正式发布文档审批信息序号审批人角色审批日期签字备注目 录前 言5第一章 概述61.1 术语61.2 为什么需要SOA71.3 SOA 的主要应用场景81.4 什么是SOA81.5 SOA 的特点81.5.1 重点关注服务81.5.2 松耦合91.5.3 重构的灵活性91.5.4 对标准的支持101.6 SOA 带来的好处10第二章 技术资源122.1 研究机构122.2 国内外厂商122.3 国内外网站、会议与技术刊物122.4 国内外标准122.4.1 标准组织122.4.2 标准分类13第三章 SOA技术参考架构223.1 SOA 技术参考架构223.2 SOA 相关元素233.2.1 资源233.2.2 新开发服务243.2.3 人员243.2.4 其他平台253.3 适配器253.4 连通服务263.5 协作服务263.6 流程服务273.7 业务服务273.8 交互服务283.9 信息服务283.10 运行管理服务与工具293.11 资源管理服务与工具293.12 安全服务30第四章 SOA的关键技术314.1 关键技术概述314.2 服务的描述314.3 服务的注册和查找324.3.1 服务注册中心324.3.2 服务查找334.4 服务的管理334.5 服务间的通信344.5.1 通信协议354.5.2 通信模式354.5.3 通信模式364.6 服务的应用364.6.1 服务应用的相关工具364.6.2 流程服务功能374.6.3 统一操作界面384.6.4 多渠道支持384.7 服务的开发394.8 服务质量属性404.8.1 安全性404.8.2 可靠传输424.8.3 事务性424.9 优势与适用性434.10 实施中需要考虑的问题44第五章 基于SOA的数据仓库实例455.1 传统分布式方案的缺陷455.2 基于SOA的数据仓库实现价值465.3 基于SOA的数据仓库设计475.3.1 系统总体架构设计475.3.2 系统用例分析485.3.3 系统功能结构设计495.4 基于SOA的数据仓库服务包装规范505.5 系统总体结构设计515.5.1 WEB服务层525.5.2 应用服务层535.5.3 数据库服务层535.6 系统关键技术与实现方案535.6.1 数据交换标准制定535.6.2 服务的描述545.6.3 服务发布与撤销545.6.4 服务转换器设计555.7 一次服务请求实例56前 言随着数据仓库理论与技术的发展，越来越多的大中型企业或组织都构建了数据仓库系统，这些系统整合企业的历史数据，为企业制定决策提供了依据。但是，随着企业的发展和数据仓库系统的广泛应用，传统数据仓库的缺陷也开始显现，企业信息系统越来越臃肿，信息系统不断的重复建设使得企业的运营成本越来越高，企业的信息化建设渐渐成为企业的噩梦。面向服务的体系结构（service-oriented architecture，SOA）是一个组件模型，它将应用程序的不同功能单元（称为服务）通过这些服务之间定义良好的接口和契约联系起来。接口是采用中立的方式进行定义的，它应该独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种这样的系统中的服务可以以一种统一和通用的方式进行交互。SOA 是一种IT体系结构样式，支持将您的业务作为链接服务或可重复业务任务进行集成，可在需要时通过网络访问这些服务和任务。这个网络可能完全包含在您的公司总部内，也可能分散于各地且采用不同的技术，通过对来自纽约、伦敦和香港的服务进行组合，可让最终用户感觉似乎这些服务就安装在本地桌面上一样。需要时，这些服务可以将自己组装为按需应用程序即相互连接的服务提供者和使用者集合，彼此结合以完成特定业务任务，使您的业务能够适应不断变化的情况和需求，在有些情况下，甚至不需要人工干预。从技术角度而言，SOA带来了“松散耦合”的应用程序组件，在此类组件中，代码不一定绑定到某个特定的数据库（甚至不一定绑定到特定的基础设施）。正是得益于这个松散耦合特性，才使得能够将服务组合为各种应用程序。这样还大幅度提高了代码重用率，可以在增加功能的同时减少工作量。由于服务和访问服务的客户机并未彼此绑定，因此可以完全替换用于处理订单的服务，下订单的客户机-服务将永远不会知道这个更改。所有交互都是基于“服务契约”进行的；服务契约用于定义服务提供者和客户机之间的交互。通常，您将通过创建“基于消息的”系统来实现此目标。第一章 概述1.1 术语l SOA：Service Oriented Architecture，面向服务的体系架构l WSDL：Web Service Definition Language，Web服务描述定义语言l SOAP：Simple Object Access Protocol，简单对象访问协议l UDDI：Universal Description Discovery and Integration，统一描述发现和集成l BPEL：Business Process Execution Language，业务流程执行语言l 服务服务是SOA 系统的基本元素，以明确且与实现无关的标准化接口完成业务功能定义，服务可在不同业务过程中被重复使用，而且具体的服务实现不依赖特定实现语言与工具。l 资源这里的资源指业务系统中所涉及到的企业、公众、政府部门和组织间存在的可用于业务处理的数据、信息、知识以及软硬件产品等。l 连通服务连通又称服务总线，是面向服务架构的骨干，在完成服务的接入，服务间的通信和交互基础上，还提供安全性、可靠性、高性能的服务能力保障。连通服务的一个典型实现就是企业服务总线（ESB）。l 协作服务协作服务是连通服务的一个重要补充，主要通过WebServices 方式实现服务之间以更松散耦合方式进行通信和交互，可以简单认为其就是整个服务通信和交互环节中的WebServices网关。协作服务也提供安全性、可靠性、高性能的服务能力。l 流程服务流程服务支持复杂业务流程的设计，运行和监控管理。业务流程通过将若干服务按流程方式组织定义来实现，支持短时间运行的自动流程和可能长时间运行的有人工介入的流程。1.2 为什么需要SOASOA提供了一种构建IT组织的标准和方法，通过建立可组合、可重用的服务体系来减少IT 业务冗余，并加快项目开发的进程。SOA 允许一个企业高效地平衡现有的资源和财产，这种体系能够使得IT 部门效率更高、开发周期更短、项目分发更快，在帮助IT技术和业务整合方面有着深远的意义，它可以：l 缩小业务和技术的鸿沟以业务为中心SOA 改变了以往以技术为中心的信息系统建设模式，使得IT 技术重新回到业务支撑的角色。IT 技术的目标是为业务、应用服务，而不是IT 技术本身的发展。业务人员可以像组装硬件一样从业务角度即时构造应用，从而缩小业务和技术的鸿沟。l 软件资源的共享与重用SOA提供了一种把原有的组件按一定的标准封装为具有文档形式接口描述的服务，从而使服务的使用者和服务之间是一种松耦合关系。这样，一方面可以把遗留系统封装为服务加以复用，提高了投资回报率；另一方面，可以直接调用外部服务提供商提供的服务从而起到复用的作用。l 应用的随需扩展灵活性和敏捷性SOA的松耦合特性给应用带来了极大的灵活性。服务使用者和服务提供者在保持接口契约一致性的情况下，可以独立演化。基于SOA 的应用可以看成是一组服务以及服务之间松散耦合的集合。因此，一方面新的服务可以很容易地加入这个松散集合，另一方面也可以根据业务需求重新编排集合内的服务，以生成新的复合服务。因此基于SOA的应用具有易于改变、易于扩展的特点，从而支持了业务的快速反应和敏捷性。总之，面向服务架构（SOA）试图将网络上需要共享的各种资源统一以服务的形式进行封装和接入，让它们在物理上保持分布自治的同时实现以“虚拟信息中心”为基础的逻辑上的一体化管理，以透明的方式进行资源的优化选取、按需中介和有效访问，并能够支持用户主动参与应用配置。SOA 主要通过复用性、灵活性和共享性从技术上支持上述目标。SOA 以服务为基本单元，更加贴近于企业的商业活动，业务建模和流程编排的复杂度会有效降低，重用性也会有效提高。因此，采用SOA，可以让IT更加关注于业务流程而非底层IT基础结构，从而获得竞争优势的更高级别的应用程序开发架构。1.3 SOA 的主要应用场景SOA的主要应用场景有：l 跨部门资产联合使用l 组织内部或组织之间应用整合需要，可以适应未来变化，实现对已有资产的保护，简化开发l 互联网环境下虚拟企业的建立，可以利用互联网上的服务进行组合提供新的业务服务l 为用户提供多渠道支持服务，服务接口的统一，有利于与服务展现方式和服务渠道的多样化1.4 什么是SOAOASIS标准组织在SOA参考模型（RM）中对SOA的定义为：SOA（Service Oriented Architecture）是一种软件体系结构范型，可以组织和使用处于不同所有者控制下的分布式功能。对SOA的理解多种多样，从技术角度看，SOA就是一种体系架构，它描述了一种IT基础设施，使得不同的业务服务可以相互交换数据，参与业务流程，通过灵活的互相协作方式来完成具体的业务操作。这些业务服务独立于编程语言，独立于实现方法，独立于运行环境。1.5 SOA 的特点1.5.1 重点关注服务SOA支持面向服务的开发方法，是对前续的面向过程、面向消息、面向数据库和面向对象开发方法的补充。服务从更高抽象层次上定义，直接与业务相对应，且其实现可采用面向过程、面向消息、面向数据库和面向对象等不同开发方法。与面向对象的调用接口相比，服务一般定义较粗粒度的接口，会接收更多的数据，消耗更多的计算资源。服务一般是用来解决应用间互操作问题，以及将服务组合成新应用或新的应用系统，而不是为应用创建具体的业务逻辑。通过SOA，围绕服务构建IT 系统，有利于IT 系统更靠近实际业务要求，使IT 系统更容易适应业务变化的要求，另外，对已有应用系统，通过服务化封装，可以使这些系统得到更好的重用，能有效保护对已有应用系统建设的投资。1.5.2 松耦合松耦合是软件设计中一个重要概念，SOA 强调服务间的松耦合。在SOA 中松耦合包括以下几个方面：l 接口松耦合接口耦合是指服务请求者与服务提供者之间的耦合。度量的是请求者与服务提供者的依赖性。接口松耦合强调服务请求者仅需要根据已发布的服务契约和服务水平协议（或称服务等级协议）就可以请求一个服务，任何时候服务请求者都不需要了解服务提供者对内部实现的信息。即服务接口封装了所有的实现细节，使服务请求者看不到这些实现细节。l 技术松耦合技术耦合度量的是服务对特定技术，产品或开发环境的依赖程度。技术松耦合强调服务请求者和服务提供者的实现和运行不需要依赖与特定的某种技术，或某个厂家的解决方案或产品，从而减少对某个厂商的依赖。在SOA 系统中服务请求者和服务提供者可以使用不同技术实现，可以在不同厂商的环境中运行。l 流程松耦合流程松耦合度量的是服务与特定业务流程的依赖程度。强调服务不应与具体的业务流程相关，以便能够被重用于多种不同的业务流程与应用。这一点强调的是服务的可重用性，在SOA 系统中对业务服务的合理规划，使得一个业务服务可以在多个业务流程中得到复用，并且随着业务要求的改变，一个服务可以在变化后的新的业务流程中能够得到继续使用。1.5.3 重构的灵活性在SOA系统建设中，基本的单位是实现业务功能的服务，而不是实现业务逻辑的对象，过程，函数等较小的技术单位。服务与实际业务功能相关，具有明确的接口。这些服务可在不同的业务流程中得到重用，提高了服务的价值；其次在使用中只需按其接口要求进行访问，屏蔽服务实现细节，服务实现的修改不会影响到服务访问方的逻辑，提高了业务流程的适应性；另外，一旦业务流程变更，仅需对服务进行重新编排，并不修改服务本身，提高了业务流程实现的灵活性。重构的灵活性，不仅可以使业务服务可以有更好的重用性，也使得业务流程更容易重构，使IT系统具有了更好的灵活性，可以快速面对变化的市场需求。1.5.4 对标准的支持为了强调互操作性，在SOA系统中，服务需要尽量符合开放标准。与服务相关的技术几乎都存在相应标准，通过对标准的使用可以得到众多好处，包括：l 减少对特定厂商的依赖；l 为服务请求者增加了使用不同服务提供者的机会；l 为服务提供者增加了被更多服务请求者使用的机会；l 增加了使用开放源代码的标准实现，以及参与这些实现的开发机会；在SOA系统中，除强调需要遵守技术标准（如SOAP，WSDL，UDDI 和WS-*）外，服务层的数据模型和流程模型也有需尽可能基于一些成熟的业务领域标准或纵向的行业标准。1.6 SOA 带来的好处按SOA方法构建应用系统，可获得技术、业务层面的不同优势。在技术层面带来的好处有：l 开发过程更有效，缩短开发周期l 更利于重用l 简化维护l 增量采纳，在统一的规划下，系统可以通过试点后分步骤建立l 流畅的演进，可以逐步改进业务目标在业务层面带来的好处有：l 增强业务机动性，有更好敏捷性l 更好的配合业务，可以优化业务框架l 改善客户满意度l 提高现有IT资产的投资回报率l 降低集成成本，节省费用l 降低对厂商的依赖和降低转换成本，获得技术的独立性第二章 技术资源2.1 研究机构正文为宋体小四，段落缩进2字符，1.5倍行距2.2 国内外厂商正文为宋体小四，段落缩进2字符，1.5倍行距2.3 国内外网站、会议与技术刊物正文为宋体小四，段落缩进2字符，1.5倍行距2.4 国内外标准2.4.1 标准组织与SOA技术相关的主要标准化组织有：l W3C（World Wide Web Consortium，万维网联盟）该标注组织主要进行Web标准（HTTP、HTML、XML等）的制定工作。制定的与SOA 有关的技术标准主要有SOAP、WSDL、WS-Choreography、WS-Addressing、WS-Policy、XML-Encryption和XML-Signature。l OASIS（Organization for the Advancement of Structured Information Standards，结构化信息标准促进组织）该标准组织成立时主要关注SGML（Structured Generic Markup Language）间的互操作。当前SOA相关技术标准的制定和推进工作是该组织的一个主要工作方向，相关技术标准有UDDI、WS-Security、WS-BPEL、WS-Composite Application Framework、WS-Notification 、WS-ReliableMessage 、WS-Policy 、WS-RemotePortlets 、WS-Distributed Management 和WS-Resuore Framework。l WS-I（Web Services Interoperability，Web服务互操作组织）该组织主要工作是确保各种Web服务实现的互操作性，该组织不直接定义标准，主要工作是提出一些标准应用的概要（Profile），以指导Web服务标准的应用。2.4.2 标准分类随着近几年SOA概念的推广及相关技术标准的发展，SOA逐渐为众多的用户所接受，并在电子政务及企业应用的建设中逐步得到应用。但是，面对众多纷繁复杂的SOA相关技术标准，IT企业在开发SOA相关软件产品及用户实施SOA进行选择时，往往分不清楚哪些技术标准是他们所需要的，而且相当部分的SOA技术标准的定位，有一定的重合。因此，选择适合的SOA相关技术标准，成为IT企业和实施SOA用户的面临的难题。下面，简单介绍一下部分SOA相关技术标准，并作简单分析。l SOA相关技术标准分类 标准与规范基本相似，但略微不同，规范是标准的建议文档。标准一 般是由业界公认的标准化组织制定和发布，而规范多为厂商或非标准化组织发布。本文不对它们进行区分，统一称为标准。SOA相关技术标准有多种分类方式，本 文介绍两种。n 分类方法一一种方法是将其分成三类，即XML标准集、Web服务标准集和SOA参考模型：Ø XML标准集主要包括两类，一是基于纯文本的编码技术，XML信息集、XML Schema、XML Query和XSLT 2.0等。二是允许不透明的二进制数据与传统的基于文本的标记交织在一起的编码技术。如XML二进制优化封装协议(XML-binary Optimized Packaging，XOP)、SOAP 消息优化(Transmission Optimization Method，MTOM)等。XML标准集是促进SOA发展的头等功臣，它们多数是由W3C组织制定，并得到了众多软件厂商及用户的支持和 使用，如不管是Java阵营还是.NET阵营，乃至其他软件开发技术，大都提供XML标准集的工具包。XML标准集不但是用于SOA数据描述和处理的最佳 标注，它还是其他SOA相关技术标准的基础，如Web服务标准，都是以XML来进行描述的。Ø Web服务标准集Web服务 标准集已经初具规模，内容涵盖传输层、消息机制、编程模型、服务发现和描述、可靠性、事务处理、安全和管理等方面。如WSDL用于Web服务的语义描 述，WS-Policy用来描述Web服务的能力和策略等，WS-Security、SAML等用来描述Web服务相关安全性要求，等等。目前，多数 Web服务标准集，由OASIS组织制定，有些Web服务标准尚不完善，正在发展中。Ø SOA参考模型SOA发展早期，不 同厂商宣扬的SOA参考模型不尽相同，随着相关技术标准的发展，各个厂商的认识逐渐统一。当前，OASIS已经制定了SOA的参考模型SOA-RM1.0 规范，它提供了一个整体的抽象框架，它用来理解SOA先进技术理念的抽象框架，是在面向服务环境里的重要衔接方式，是标准逐步统一的重要发展进程，也是服 务支持的详尽规范。SOA参考架构，能够在企业的SOA整体计划中提供一个很具有全局性的整体框架加以指导，但却不能在现实的SOA执行中提供太多具体可 行的意见。虽然已经有了SOA参考模型的推荐性标准，但标准化组织和厂家在SOA的参考架构上还没有统一。n 分类方法二SOA相关技术标准的另一种分类方式，是根据技术标准在 SOA 中的角色功能，将其分为三大类：服务层次上的信息交互规范、基础通信标准规范、元数据标准规范。根据各种标准规范在SOA 体系中的角色功能，可以将 SOA 协议栈分为 7 层，如图1所示。从底向上，包括传输层、消息层、描述层、管理层、服务组合层、表示层，其中除了ebXML和电子商务相关的技术标准(如资源注册的 ebRS、消息表示ebMS、外部服务资源编排的WS-CDL等)外，大多数在国内已经得到了相当的应用，如东方通科技的应用集成产品 TongIntegrator和应用服务器TongWeb，都支持部分Web服务的相关技术标准。传输层作为传统的传输协议，在SOA技术实现中，依然发 挥着重要的作用;消息层SOAP已经是Web服务消费的消息传输载体的首选;Web服务描述标准WSDL，虽然在语义方面的描述还不完善，但它已经被绝大 多数厂商和用户接受并使用了;在管理层的相关技术标准，目前还在发展完善，国内实际应用的还不多，但诸如常用的安全要求WS-Security、可靠传输 要求WS-Reliability等，已经有用户和厂家开始考虑使用;服务组合层，已经有不少的商业及开源组织，基于BPEL标准来开发业务流程管理软件 了;表示层的标准如JSR168和WSRP，主要用于Portal软件的开发。图2.1.SOA协议栈分层结构l SOA相关技术标准比较说明由于SOA相关技术标准太多，图2.1中，并没有完全列举出所有的SOA相关技术标准。下面，就 部分相似的SOA相关标准进行比较说明，以便进行SOA开发时，能够基于了解认识进行选择。n WSDL与OWL-SW3C 组织提出的标准的Web服务描述语言WSDL，它从句法层面对Web服务的功能进行描述，包括4个不同的粒度：数据类型(Data type)、消息(Message)、方法(Operation)和访问端口(PortType)。这只是提供了Web服务的接口描述，对服务的行为约束 和属性描述缺乏进一步的支持。OWL-S是语义Web服务标记语言的标准，它比WSDL更能向用户提供可理解的服务资源的描述形式，提高服 务选取与推荐的准确性。语义Web服务的主要方法是利用Ontology来描述Web服务，然后通过这些带有语义信息的描述实现Web服务来实现服务的自 动发现，调用和组合。语义Web和Web 服务是语义Web服务的两大支撑技术。OWL-S是连接两大技术的桥梁，目前对语义Web服务标记语言研究最重要的组织就是DARPA组织，其研究组 OWL Services Coalition提出了语义Web服务标记语言OWL-S(原DAML-S)。语义Web服务及相关标准 (OWL-S等)对于Web及Web服务应用的深化具有重要意义，同时也具有很好的发展前景。目前OWL-S等语义Web服务相关标准的应用还主要是研究 性、示范性的。n XML Web服务与ebXMLSOA中的服务，当前多以Web服务技术实现和解释，传统的Web 服务及其相关协议，都是以XML为基础进行扩展的，因此把它称为XML Web服务。其实，在XML Web服务之前，ebXML已经出现，鉴于此标准复杂而完善，因此它在传统的电子商务领域，用处较广。就具体的内容和定位而言，两者有一定的区别。1) 消息传输技术XML Web服务和ebXML都使用SOAP作为消息传输技术，但是XML Web服务服务定义了松散耦合的协议堆栈，该堆栈由可靠传输 (WS-Reliability) 和 安全 (WS-Security) 的各个规范组成，而ebXML将所有这些功能都融入到自己的消息传递标准和ebMS中，从而使用混合技术。2) 服务描述和发现XML Web服务分别使用WSDL和UDDI标准，UDDI注册机制是基于目录的体系结构，其注册内容包括技术模型和业务模型，本身可扩展但目前其注册的内容和 描述还不够丰富和完整，图3为UDDI的数据模型及关系图。而ebXML将服务描述和发现机制对应两个标准，一是注册信息模型ebRIM， 二是注册服务规范ebRS。ebXML注册机制要比UDDI丰富和完善的多，它的注册机制用途广泛，可以表示范围广泛的数据对象，包括 xml 模式、业务流程描述、ebXML Core Component、UML模型、一般贸易合作伙伴信息及软件组件。为了支持如此多样的数据，使用一个定义良好的信息模型而不是目录，将ebXML注册设 计得更像一个数据库，图2为ebXML的注册信息模型ebRIM的组织结构示意图。3) 业务流程协作基于Web服务的业务 流程协作和服务编排，有WS4BPEL、WS-CDL、基于XML的工作流XPDL等，这些基于XML和Web服务的标准都彼此相对独立，甚至是不同的组 织制定。ebXML标准也包含业务流程协作的标准，如ebCPPA、ebBPPS。总之，ebXML是一个独立的规范集，具 有内部一致性，而且不依赖于新兴标准和规范，它的用途主要定位在有特殊要求的电子商务方面，目前，ebXML已被国家确定为国标推荐，但其应用看起来还要 有一段路要走。而XML Web服务由于其内容相对简单，技术实现容易，对应的一系列协议栈相对松耦合，因此其在构建SOA的应用中使用越来越广泛。图2.2 ebXML的注册信息模型(ebRIM)图2.3 UDDI数据模型及其关系图n SCA/SDO与JBI/JDOSCA(Service Component Architecture)，即服务组件架构，提供了一种编程模型，可以支持基于SOA的应用程序实现。SCA是一种模型，可以支持实现服务组件的各种技 术，连接服务组件的各种存取方法。对于组件，不仅包括不同的编程语言，也包括这些语言使用的框架和环境。对于存取方法SCA合成操作支持各种通讯、服务存 取技术，如：WS、MQ、RPC。SCA规范包括了Assemble Model和Client Model两部分。前者约定了如何将异种组件(Java类，BPEL，Web Service)组装并发布成SOA服务，是SCA最大的特点和最核心的概念;后者则约定了如何在异种语言环境中调用SOA服务。通过这两部分的规范，就 可以完全解决了服务从服务端到客户端的跨语言、跨环境的问题。图2.4为SCA的服务组件组装模型。服务数据对象(SDO)的设计初衷是为了统 一和简化应用程序处理数据的方式,使用SDO,应用编程人员可以用一致的方法操作异构数据源,包括关系型数据库,XML数据源,Web services和企业信息系统 。JBI是Java商业集成(Java Business Integration)的简称。JBI的制订者们认为传统的EAI和B2B解决方案使用非标准的技术，这使得用户往往被锁定到特定的方案和产品提供商 上，与此同时，没有任何一个单独的提供商可以覆盖EAI和B2B领域的所有问题。因此他们提出这个标准以期解决这个问题。这个标准定义了一个标准的体系结 构允许第三方的组件插入到标准的基础设施上，并且即使这些组件是有不同提供商提供的，它们也可以以一种可预见的和可靠的方式互操作。从高层次上看，JBI 定义了可以从可插入组件构建集成系统的体系结构，这一结构中组件的交互使用一种经过中介的消息交换机制，而这一消息交换模式是基于WSDL 2.0或WSDL 1.1的。图2.5为JBI环境组成及结构。图2.4 SCA服务组件组装模型图2.5 JBI环境组成与结构JDO，即Java Data Object，它定义了持久保存类与JDO运行时环境之间的关系。JDO的设计目的是用来广泛支持不同的数据来源，甚至包括一般不被认为是数据库的来源。 因此用“数据存储空间”(datastore)一词泛指以JDO 访问的底层数据来源。从上面的分析来看，SCA/SDO定义了与具体 技术无关的服务组件组装模型及服务间访问的数据结构表示方式，SCA的定位，主要在于细粒度的组件和服务组装方式。SCA/SDO由于技术无关性及众多厂 商的参与，他们得到了大多数厂商的支持。而JBI/JDO，它们都是基于Java的技术，JBI更多的像服务总线的Java标准定义，其粒度比SCA，而 且更多的是服务间的通讯和组装模式，而JDO是基于Java的数据对象表示，因此它们使用的范围受到限制，当前支持的主流厂家也不多，但是开源的实现相对 还是比较多的。n WS4BPEL与WS-CDLWS4BPEL，即Web Service Business Process Execution Language的简写， Web服务业务流程执行语言，它是一种可执行语言，能够与各种促使业务流程自动化的软件系统相兼容。Web服务编制，通过说明性的方式(而不是编程的方 式)表达了进行Web服务合成的需求。此标准主要用于组织内部的业务流程管理及服务编排，目前越来越多的BPM产品基于此规范实现。WS- CDL，即Web Services Choreography Definition Language，Web服务编排定义语言，它定义为在多个交易伙伴之间建立形式化关系，它不要求所有被集成的端点(endpoints)都有Web服务 基础设施。此规范更多地用于组织之外的服务与流程编排，目前在国内还不常用。另外，XPDL也可以用于服务的编排和组合，但它主要用于传统 的工作流定义，目前它也是BPM产品实现的重要技术标准。n JSR168与WSRPJSR168是java 规范要求(java specification request ，jsr)的缩写，它为创建portlet建立标准的api，它是为实现porltet、基于java的门户服务器和其他web应用程序之间的互操作性而 设计的。JSR168的主要价值在于它被独立软件开发商(isv)所广泛采用。在采用JSR168之前，企业应用程序开发商不得不支持所有开发商门户的不 同portlet集，支持多个门户开发商不同的portlet集在类似业务信息、内容管理、检索和分析这样的领域中非常令人头疼。使用JST168规范， 现在开发商只需要支持一种portlet集。目前，JSR168在基于Java技术开发Portal产品上，得到了广泛的支持，但也仅限于Java技术。WSRP，即Web Services for Remote Portlets的缩写，它定义了如何利用基于 SOAP 的 Web 服务在门户应用程序中生成标记片断的规范。通过定义一组公共接口，WSRP 允许门户在它们的页面中显示远程运行的 portlet，而不需要门户开发人员进行任何编程。对于最终用户，这些 porlet 就和运行在他们本地的门户上一样，但是实际上这些 portlet 来自于远程运行的 portlet 容器，并且交互是通过 SOAP 消息的交换来实现的。在面向服务的体系结构中利用 WSRP 将是一个强大的组合，从而使面向呈现的 portlet 应用程序可以被发现并重用而不用任何额外的开发和部署活动。WSRP是由OASIS组织制定，目前已得到多数厂商的支持，鉴于它基于Web服务标准，而且 技术相对独立，因此随着此标准的逐渐完善，相信越来越多的Portal生产企业会支持此标准。第三章 SOA技术参考架构3.1 SOA 技术参考架构一个完整的SOA 应用系统，其组成元素包括：SOA 基础技术平台、辅助工具、资源、应用服务、使用SOA系统的人。SOA 技术参考架构主要描述SOA 基础技术平台与辅助工具，同时描述这两部分与其他外围相关元素之间的关系。SOA技术的参考架构如图3.1所示。图3.1 SOA技术参考架构图SOA 技术参考架构主要描述一个SOA 系统中提供基础技术平台和辅助工具的功能模块和相关对象。定义的SOA技术参考架构包括两大部分，即运行时的平台功能模块，设计、开发和管理时的功能模块。参考架构各模块之间满足松散耦合特性，具有定义良好的接口，可通过拆分与组合，来针对性构建满足不同应用场景需求下的技术系统。SOA 参考架构是SOA 基础技术平台产品和辅助工具产品实现的重要参考依据；是开发SOA应用系统时确定系统架构，选用SOA技术的重要参考依据；是保证长风联盟SOA支持产品与解决方案互操作性的重要基础。下面介绍SOA技术参考架构的各个主要组成部分，及其互相之间的关系。3.2 SOA 相关元素SOA参考架构的核心是基础技术平台和辅助工具。SOA相关元素指与SOA参考架构核心相关的元素，包括使用SOA 基础技术平台的人员，在基础技术平台上运行的新开发服务，集成到基础技术平台中的已有资源，以及与基础技术平台可以进行互操作的其他平台。3.2.1 资源资源是SOA系统中被集成的对象，这些对象一般已经存在。在SOA系统中资源通过适配器接入基础技术平台中，以服务形式对外提供服务或使用其他服务。资源具有统一的服务接口，使用统一的接入方式。通过对已有资源的封装，增强重用能力，充分发挥其已有的作用。资源与基础技术平台关系如图3.2所示：图3.2 资源与基础技术平台的关系图资源通常分为两类：数据资源和应用资源，其中：l 应用资源应用资源特指已有的应用系统，是能够完成特定业务处理的现有系统的总称。应用资源如同其他服务一样，既可以为其他服务提供服务消费；也可以消费其他服务。应用资源通过开放接口，以适配器为桥梁接入SOA的基础技术平台中。l 数据资源数据资源主要针对无法开放操作接口的应用系统，或只需对外提供数据服务的特定场景而设立，可以是格式化数据和非格式化数据，例如数据库和各种文件就是典型的数据资源。数据资源主要供SOA系统中的各种服务进行加工处理，进行深度的应用。3.2.2 新开发服务新开发服务包括：l 基本服务，通过编程工具形成的，在业务服务中运行的原子性服务l 流程化服务，通过流程工具定义的，在流程服务中运行的由基本服务组合形成的服务新开发服务均可使用已有的服务。服务描述信息通过资源管理服务进行存储和管理，服务运行信息由运行管理服务进行存储和管理。新开发服务与SOA参考架构关系如图3.3所示。图3.3 新开发服务与SOA参考架构关系图3.2.3 人员使用SOA系统的主要角色包括：l 设计人员，进行业务分析和建模，使用业务分析和建模工具l 开发人员，实现具体的SOA系统，包括流程定义，服务编码，资源集成等，使用集成开发工具l 管理人员，对SOA系统运行进行监控管理，使用运行管理工具l 操作人员，对SOA系统进行业务操作，通过交互服务使用SOA系统中的服务，或进行数据和业务的处理人员在SOA中具有重要使能价值，人员与SOA参考架构的关系如图3.4所示：图3.4 人员与SOA参考架构关系图3.2.4 其他平台SOA 强调互操作。在一个所有者控制域下（如一个组织内部），可以通过基础技术平台实现互操作；在所有者控制域之间（如多个组织之间），有可能使用不同的基础技术平台实现，需要实现平台之间的互操作。平台之间的互操作一般通过协作服务实现。3.3 适配器适配器解决已有资源面向SOA的服务封装，实现已有资源的可重用性。通过适配器，已有资源仅需要与SOA 基础技术平台中的连通服务相连接，而不需要与每个服务直接相连，就可以实现服务之间的互操作。适配器支持将各种已有资源以统一的方式接入SOA 基础技术平台，与连通服务相联。通过适配器已有资源（包括数据和应用）以服务方式提供服务，也以服务方式消