SOA系统架构调研

SOA系统架构调研 1． SOA原理与应用 1. SOA原理 2. SOA技术构成 3. SOA实施应用 4. SOA治理 2． 开源SOA优势与劣势及选型 标准 excel标准偏差excel标准偏差函数exl标准差函数国标检验抽样标准表免费下载红头文件格式标准下载 1. 开源SOA优势 2. 开源SOA劣势 3. 选型标准 3． 开源SOA选型 1. Mule 2. Apache ServiceMix 3. JBoss ESB 4. Apache Synapse 5. 选型建议 四．工作流原理与选型 1. 工作流原理与应用 2. 开源工作流选型 五．视频发布系统服务体系结构 1. 服务模块详述 1.1. 视频编辑服务 1.2. 网络管理服务 1.3. 服务器管理服务 1.4. 中级服务器管理服务 1.5. 终端管理服务 1.6. 手机视频发布服务 1.7. 指纹管理服务 2. 服务结构体系 六. 视频发布系统SOA架构解决 方案 气瓶 现场处置方案 .pdf气瓶 现场处置方案 .doc见习基地管理方案.doc关于群访事件的化解方案建筑工地扬尘治理专项方案下载 1.视频发布系统SOA架构 一．SOA原理与应用 1.SOA原理 SOA（Service-oriented architecture，面向服务架构）。 SOA的价值在于跨越了不同应用系统、不同技术的整合，这种整合改变现有的商业模型。 SOA是在计算环境下设计、开发、应用、管理分散的逻辑（服务）单元的一种 规范 编程规范下载gsp规范下载钢格栅规范下载警徽规范下载建设厅规范下载 。这个定义决定了SOA的广泛性。SOA要求开发者从服务集成的角度来设计应用软件，即使这么做的利益不会马上显现。SOA要求开发者超越应用软件来思考，并考虑复用现有的服务，或者检查如何让服务被重复利用。SOA鼓励使用可替代的技术和 方法 快递客服问题件处理详细方法山木方法pdf计算方法pdf华与华方法下载八字理论方法下载 （例如消息机制），通过把服务联系在一起而非编写新代码来构架应用。经过适当构架后，这种消息机制的应用允许公司仅通过调整原有服务模式而非被迫进行大规模新的应用代码的开发，使得在商业环境许可的时间内对变化的市场条件做出快速的响应。 SOA也不仅仅是一种开发的方法论--它还包含管理。应用SOA后，管理者可以方便的管理这些搭建在服务平台上的企业应用，而不是管理单一的应用模块。其原理是，通过分析服务之间的相互调用，SOA使得公司管理人员方便的拿到什么时候、什么原因、哪些商业逻辑被执行的数据信息，这样就帮助了企业管理人员或应用架构师迭代地优化他们的企业业务流程、应用系统。 SOA的一个中心思想就是使得企业应用摆脱面向技术的解决方案的束缚，轻松应对企业商业服务变化、发展的需要。企业环境中单个应用程序是无法包容业务用户的（各种）需求的，通过将注意力放在服务上，应用程序能够集中起来提供更加丰富、目的性更强的商业流程。其结果就是，基于SOA的企业应用系统通常会更加真实地反映出与业务模型的结合。服务是从业务流程的角度来看待技术的--这是从上向下看的。这种角度同一般的从可用技术所驱动的商业视角是相反的。服务的优势很清楚：它们会同业务流程结合在一起，因此能够更加精确地表示业务模型、更好地支持业务流程。相反我们可以看到以应用程序为中心的企业应用模型迫使业务用户将其能力局限为应用程序的能力。  企业流程（enterprise process）是流经企业框架的空气，它赋予业务模型里的组件以生命，并更加清晰地定义了它们之间的关系。流程定义了同业务模型进行交互操作的专门方法。服务被定义用来支持业务流程，因而贯穿整个流程始终的是：各种服务组件在流程和逻辑实现过程中的装配操作。理解业务流程是定制服务的关键所在。  有利于企业业务的集成  传统的应用集成方法（点对点集成、企业消息总线或中间件的集成（EAI）、基于业务流程的集成）都很复杂、昂贵，并且不灵活。这些集成方法难于快速适应基于企业现代业务变化不断产生的需求。基于面向服务架构 (SOA) 的应用开发和集成可以很好的解决其中的许多问 题 快递公司问题件快递公司问题件货款处理关于圆的周长面积重点题型关于解方程组的题及答案关于南海问题 。 SOA 描述了一套完善的开发模式来帮助客户端应用连接到服务上。这些模式定制了系列机制用于描述服务、通知及发现服务、与服务进行通信。 3. 原则与技术构成 SOA是一种企业架构，因此，它是从企业的需求开始的。但是，SOA和其它企业架构方法的不同之处在于SOA提供的业务敏捷性。业务敏捷性是指企业对变更快速和有效地进行响应、并且利用变更来得到竞争优势的能力。对架构设计师来说，创建一个业务敏捷的架构意味着创建这样一个IT架构，它可以满足当前还未知的业务需求。 要满足这种业务敏捷性，SOA的实践必须遵循以下原则： 1. 业务驱动服务，服务驱动技术 从本质上说，在抽象层次上，服务位于业务和技术中间。面向服务的架构设计师一方面必须理解在业务需求和可以提供的服务之间的动态关系，另一方面，同样要理解服务与提供这些服务的底层技术之间的关系。 2. 业务敏捷是基本的业务需求 SOA考虑的是下一个抽象层次：提供响应变化需求的能力是新的“元需求”，而不是处理一些业务上的固定不变的需求。从硬件系统而上的整个架构都必须满足业务敏捷的需求，因为，在SOA中任何的瓶颈都会影响到整个IT环境的灵活性。 3. 一个成功的SOA总在变化之中 SOA相关技术说明： · Web Service: Web Service 是在 Internet 上进行分布式计算的基本构造块，是组件对象技术在 Internet 中的延伸，是一种部署在 Web 上的组件。它融合了以组件为基础的开发模式和 Web 的出色性能。 Web Service 和组件一样，能提供重用功能，同时可以把基于不同平台开发的不同类型的功能块集成在一起，提供相互之间的互操作。简单的说，一个Web服务就是一个能够使用XML消息通过网络来访问的接口，这个接口描述了一组可访问的操作。一个Web服务的特征是：由SOAP和WSDL包装的对象；适应松散耦合的网络环境，可通过Web服务，手段是SOAP消息；服务的行为、输入、输出都可以使用WSDL描述。 · SOAP: SOAP（Simple Object Access Protocol ）简单对象访问协议是在分散或分布式的环境中交换信息的简单的协议，是一个基于XML的协议，它包括四个部分：SOAP封装(envelop)，封装定义了一个描述消息中的内容是什么，是谁发送的，谁应当接受并处理它以及如何处理它们的框架；SOAP编码规则（encoding rules），用于表示应用程序需要使用的数据类型的实例; SOAP RPC表示(RPC representation)，表示远程过程调用和应答的协定;SOAP绑定（binding），使用底层协议交换信息。 · WSDL: Web Services Description Language的缩写，是一个用来描述Web服务和说明如何与Web服务通信的XML语言。 · UDDI: 是Universal Description, Discovery, and Integration的缩写。简单说，UDDI用于集中存放和查找WSDL描述文件，起着目录服务器的作用。 BPM: 规则引擎: ESB：ESB是提供诸如路由，转换，安全和协议转换这些功能的重要组成部分，这些功能有助于服务彼此之间的通信，并实现（BPEL）流程跟服务的通信。 ESB项目（Mule，ServiceMix，Synapse，Open ESB等） BPM项目（JBoss jBPM，Apache ODE，Open ESB BPEL组件等） 服务注册（Mule Galaxy，WSO2注册等） 业务规则引擎（Drools/JBoss Rules）。 4. SOA实施应用 SOA的实施具有几个鲜明的基本特征。实施SOA的关键目标是实现企业IT资产的最大化重用。要实现这一目标，就要在实施SOA的过程中牢记以下特征： (1) 可从企业外部访问 通常被称为业务伙伴的外部用户也能像企业内部用户一样访问相同的服务。外部用户可以访问以Web服务方式提供的企业服务。 (2) 随时可用 当有服务使用者请求服务时，SOA要求必须有服务提供者能够响应。大多数SOA都能够为门户应用之类的同步应用和B2B之类的异步应用提供服务。 (3) 粗粒度服务接口 粗粒度服务提供一项特定的业务功能，而细粒度服务代表了技术组件方法。 (4) 分级 在服务分级方面，须注意服务层的公开服务通常由后台系统（BES's）或SOA平台中现有的本地服务组成。因此允许在服务层创建私有服务是非常重要的。正确的文档、配置管理和私有服务的重用对于IT部门在SOA服务层快速开发新的公开服务的能力具有重要影响。 (5) 松散耦合 SOA具有“松散耦合”组件服务，服务提供者和服务使用者间松散耦合背后的关键点是服务接口作为与服务实现分离的实体而存在。这是服务实现能够在完全不影响服务使用者的情况下进行修改。 (6) 可重用的服务及服务接口设计管理 如果完全按照可重用的原则设计服务，SOA将可以使应用变得更为灵活。可重用服务采用通用格式提供重要的业务功能，为开发人员节约了大量时间。 (7) 标准化的接口 Web服务使应用功能得以通过标准化接口（WSDL）提供，并可基于标准化传输方式（HTTP和JMS）、采用标准化协议（SOAP）进行调用。 (8) 支持各种消息模式 SOA中可能存在以下消息模式。在一个SOA实现中，常会出现混合采用不同消息模式的服务。 无状态的消息。使用者向提供者发送的每条消息都必须包含提供者处理该消息所需的全部信息。这一限定使服务提供者无须存储使用者的状态信息，从而更易扩展。 有状态的消息。使用者与提供者共享使用者的特定环境信息，此信息包含在提供者和使用者交换的消息中。这一限定使提供者与使用者间的通信更加灵活，但由于服务提供者必须存储每个使用者的共享环境信息，因此其整体可扩展性明显减弱。该限定增强了服务提供者和使用者的耦合关系，提高了交换服务提供者的服务难度。 (9) 精确定义的服务接口 服务是由提供者和使用者间的契约定义的。契约规定了服务使用方法及使用者期望的最终结果。此外，还可以在其中规定服务质量。此处需要注意的关键点是，服务契约必须进行精确定义。 5. SOA治理 SOA通过组装一个或多个IT服务来定义业务服务的能力提升了重用的抽象层次，这是SOA的主要优势之一。这个优势使得业务以业务服务的方式来定义企业操作，而IT定义一组可以用来实现业务服务的IT服务。业务服务和IT服务之间的可追溯性通过在软件栈的多个层次提高重用，为企业带来了他们极需的IT 和业务对齐。 然而，SOA更重要的优势是业务机动性。这需要企业在IT和业务之间拥有真正的合作关系，并且已经完成业务目标和业务流程的分析、业务服务的分解以及支撑业务机动性的架构元件。 SOA治理指创建和管理用于计划、定义、设计、创建、测试和运营所有服务及自动业务流程的服务工厂。处在服务周期的不同阶段，实现SOA治理所需的工具有所不同： · 实现治理的最重要的能力是有效的双向沟通。 · 拥有标准的、企业范围的业务实体和消息模型对于开发适合企业的服务来说至关重要。一款为这些消息模型提供版本管理和发布功能的工具是企业的实物资产。在多个物理表示对应于同一逻辑业务实体的场合，详细描述这些离散表示之间映射关系的数据字典也相当关键。 · 使用通用数据库或存储空间来为业务需求、业务规则、术语和参照标准等提供版本管理和发布的功能，并依据业务实体和（或）业务流程建立索引，可以为重用提供很大的支持，还能减少不必要的重复劳动并降低运维系统的复杂度。 · 有必要为所有的技术需求文档提供管理、发布和升级等功能，这些需求包括架构原则、架构决策、策略和标准、最佳实践、推荐设计模式、清单以及清单指导等。 · 使用模型驱动的设计方法，在这种方法中，大部分的分析，设计甚至测试都是通过可视化工具进行的，并且大部实际代码都是自动生成而非手写的。因为模型比源代码更容易被理解，它可以帮助读者确保设计出精准描述业务和技术的需求并且代码准确地反映设计。 · 提供管理合规检查结果的工具 · 对于已创建很多服务（50个或者更多）或者开始将服务提供给第三方使用的企业来说，服务目录或服务注册表就变得更加关键。理想情况下，服务注册应该根据目标用户分成两个独立的部分： · 于潜在服务消费者（例如内部部门、合作伙伴或客户），目录或注册库应该包含以下信息：可以公开使用的服务详细信息（包括其版本细节）；如何获得这些服务的使用权；如何从技术角度去访问这些服务（如，通过服务描述语言WSDL定义服务接口）；治理服务使用的SLA条款等。除此之外，还应该包含对计划中的新服务以及服务版本的详细信息，以获得关于服务的内容和价值的反馈。该目录或注册库不应该包含任何关于服务实现的细节；SOA的一个关键特征是任何服务的实现可以在服务“契约”（即接口，如WSDL）不变的情况下随时被修改。一般来说，每个服务的描述信息应该只能让那些潜在的服务使用者看到；还有一些服务只为内部使用者所见。 · 对于服务开发人员，应当有更广泛的内容，包括服务内部信息，如非功能性需求，详细设计等。这部分注册库还应包含不能被直接发布成服务的底层组件，例如用来组装复合服务的独立代码段。 · 存放源代码或配置信息等资产的一个或一组注册库。在从测试到产品阶段迁移新服务或新系统时，或者软件维护时，能够重建特定物理配置的能力显得非常重要。 · 要实现任何实际层面的服务运营治理，工具和基础设施非常关键。这些工具和基础设施应能监控服务和自动流程执行的所有信息，包括它们的使用频率、版本、服务响应时间以及错误情况和系统能力监控等。 · 随着企业级SOA越来越成熟，相关数据会越来越多，如关于服务开发和运行效率的数据，关于SOA开发和治理工作的重要性，业务影响以及SOA对整个企业的价值的数据等。同时，要生成很多报表，按月、按季度、按年或者随需生成。好的工具可以很大程度上提高创建这类表格的效率；我们看到很多这样的解决方案，其中有简单的业务数据分析/报表生成工具，也有非常复杂的实时监控服务以及流程运行状态的“面板”等。 二. 开源SOA优势与劣势及选型标准 1. 开源SOA优势 开源工具软件SOA解决方案能够提供如下好处: ·简单性 开源工具软件解决方案很容易找到和很容易实施，许多架构师和开发人员都熟悉这个技术的架构。开源工具软件团体推动开源工具软件开发人员提供使用方便的框架和平台，开源工具软件解决方案还能够让企业迅速创建一些解决方案以提供有形的和可衡量的好处。. ·支持多种客户类型 借助精确定义的服务接口和对XML、Web服务标准的支持，可以支持多种客户类型，包括PDA、手机等新型访问渠道。 ·更好的伸缩性 依靠服务设计、开发和部署所采用的架构模型实现伸缩性。服务提供者可以彼此独立调整，以满足服务需求。 ·开放性 开源工具软件本身的灵活性允许比专有工具软件产品更大(的)自由和个性化，这就意味着一个机构能够从开源工具软件的安装中看到与自己的业务关系更密切更大的价值。 ·价格负担能力 开源工具软件订购模式使SOA产品比专有工具软件更便宜。开源工具软件SOA解决方案的好处在SOA实施的六个阶段中的每一个阶段都能够实现。这六个阶段是1.商务流程理解；2.IT评估；3.SOA设计和确定；4.SOA服务实现；5.SOA集成和治理基础设施；6.流程编排和组合。 在前三个阶段，工作(的)重点是商务流程、当前(的)IT设计和SOA设计，开源工具软件订购模式提供了比传统SOA解决方案更便宜和更灵活的价格结构，这有助于SOA设计工作更快(地)进行，不用担心每个处理器(的)许可证费。 在第四个阶段，也就是SOA服务实现阶段，机构必须要确定如何开发和部署应用程序和数据服务。利用开源工具软件应用服务器和(或者)数据服务平台能够提供更大的灵活性。在享受与商业工具软件产品同样水平的技术支持和安全的同时，架构师和开发人员还能够轻松开发和部署一些使他们能够提高效率和加快完成解决方案平台。此外，这种社区模式能够推动这些平台对功能和质量的要求，这些正是架构师和开发人员寻找(的)需求。 SOA发展的第五个阶段是集成和治理基础设施。这是整个部署中(的)“粘合剂”，使SOA解决方案能够发挥作用。架构师需要选择服务、应用程序和用户交流和相互沟通(的)方式，这个阶段做出的一个主要决策通常包括选择一个企业服务总线，这实际上是SOA部署中的智能集成构件。 2. 开源SOA劣势 3. 选型标准 当评估一个开源软体时，请确保该产品或服务有一个大型的用户社区，对用户的支持历史记录良好，并且有一个长远并且合理的发展路线图，再加上几个成功的部署案例。你的整个堆栈或者所有工具都可以是开源的，或者你也可以用一些开源替代品补充你的商业软件。到底采用哪种方式，由你自己根据需要决定。我强烈建议所有的供应商评估考虑至少一个开源厂商。 三．开源SOA选型 1. Mule Mule 是一个基于ESB架构理念的消息平台。它是可升级的、高分布式的对象代理，可以通过异步传输消息技术来无缝的处理服务与应用之间的交互。 Mule 的核心是一个基于SEDA的服务容器，该容器管理被称为通用消息对象（Universal Message Objects /UMO）的服务对象，而这些对象都是POJO。它支持20多种传输协议(file,FTP,UDP,SMTP,POP,HTTP,SOAP,JMS等)，并整合了许多流行的开源项目，比如Spring,ActiveMQ,CXF, Axis,Drools等。虽然Mule没有基于JBI来构建其架构，但是它为JBI容器提供了JBI适配器，应此可以很好地与JBI容器整合在一起。而 Mule更关注其灵活性，高效性以及易开发性。以下为架构图： 优点： Mule ESB是一个以Java为中心的ESB，这让Java开发者能很容易地上手。它拥有强大的XML模式集合，它们创建了一个真正清洁可读的XML配置并提供了代码补全支持。当你想实现一项转换逻辑或者路由逻辑时，你能够很轻易地开发出一个简单的Java类/Spring bean/脚本文件，把它引入到XML配置中。如果必须要指出Mule的一个不足之处，那就是缺乏对于热部署的支持。 另一方面，Mule让集成流程的创建变得容易和简单。它有非常广泛的路由器，易于扩展，并有很多可选的开箱即用的连通性、路由和转换。使用Mule，使你能够在数分钟内让相当复杂的集成流程启动并运转起来。 1. 架构简单清晰、容易上手 2. 它有非常广泛的传输器、路由器和转换器，且易于扩展 3. Mule不需将消息转换成统一的格式，而只在需要时进行转换，提高了性能 4. 开发过程中无需关注Mule代码，只需通过配置即可将服务暴露，减少了侵入性 5. 文档清晰而完善 缺点： 1. 没有实现ESB规范 2. 缺乏对于热部署的支持，无法热部署新的集成流程（企业版支持）。 2. Apache ServiceMix 是JBI规范的一种实现。它包涵了许多JBI组件，这些组件支持多种协议，比如JMS，Web服务，Camel以及BPEL组件，支持Spring，通过CXF支持Web服务，XML配置等，ServiceMix为每个JBI组件都提供了一个简易的XML配置语言，为部署你的集成解决方案提供了热部署功能。同时也实现了EIP，规则和调度。Apache ServiceMix 也整合了其他的开源项目，比如Apache ActiveMQ,Apache CXF,Apahe Camel,Apache ODE以及Apache Geronimo。以下为架构图： 优点： 让热部署新的集成流程变得容易，可热插拔集成组件，并且是基于JBI标准，并用DSL去开发集成流程。 1．基于JBI规范 2．可以热部署 3．支持Camel（可以用DSL去开发集成流程） 缺点： JBI规范确实引入了一个困难级别，对XML的关注并不总是适合在集成领域中遇到的需求。 1．JBI规范带来了使用上的繁琐，且JBI规范没有得到太多的青睐，前途未卜 2．过多依赖XML的配置 3．由于所有消息要进行标准化处理，即生成和解析XML文件，所以会导致性能下降 4． 开发过程中需要实现框架特定接口(MessageExchangeListener)接收和处理上述标准消息，侵入性强 3. JBoss SOA JBoss 企业SOA平台是一个全面的开源SOA产品，其设计目标是加快企业内部和企业之间的业务执行速度。JBoss 企业SOA平台有助于实现更出色的业务表现，并且比专有的SOA平台更简便、更开放和更具成本效益。JBoss 企业SOA平台的目标是在从小规模集成项目到企业级SOA集成的各类部署中实现最大的灵活性。JBoss 企业SOA平台建立于领先的开源项目基础之上，其中包括JBoss ESB、JBoss jBPM和JBoss Rules，其轻量占用和简便的安装可实现低成本的运营。这些领先的开源项目为JBoss 企业SOA平台提供了下列的功能： JBoss ESB – 应用和服务集成及中介、转换、注册 JBoss jBPM – 服务整合、工作流（人员和服务） JBoss Rules – 业务政策和规则管理，以及集成、基于消息内容的路由规则 该平台还包括可扩展集群、J2EE技术和高度可定制的基础，能够满足不断变化的企业需求。该平台集合了 SOA、企业应用集成（EAI）、业务流程和规则管理（BPM）和事件驱动架构（EDA）技术，能够对服务和应用及业务过程自动化进行集成，提高业务生产效率。通过以下方面，该产品将协助企业改善和加强业务的执行工作： · 利用面向服务的架构简化应用集成 · 实现传统手工业务的自动化，从而在业务过程中消除手工处理的不利因素 · 通过减少和消除业务过程中不必要的人工干预来减少业务过程中的错误 · 使数据处理过程中的错误更少，加快客户服务速度，从而提高客户体验质量 · 建立在成熟的开源项目上，提供同类最佳SOA部署必需的集群、故障切换和负载平衡能力，加强企业扩展性和可靠性 4. Apache Synapse Apache Synapse是构建在Apache Axis2之上的。Synapse的关注点是路由，转换，消息验证以及基于web服务和xml标准的注册。它支持HTTP, SOAP, SMTP, JMS,FTP ,MTOM/XOPPOP3/IMAP/SMTP 等传输协议，还支持多种web服务规范(WS-*)，比如WS-Addressing,WS-Security,WS-Policy以及WS- Reliable Messaging。在它的最新版本1.2中加入了对FIX(Financial Information eXchange,金融信息交换协议 ) 和 Hessian  的支持。同时它还支持多种流行语言，比如Java, JavaScript, Ruby, Groovy等。 5.选型建议 目前主流的SOA架构为JBI,SCA,SDO三种， 使用广泛的SOA ESB开源产品主要有Mule，ServiceMix及Jboss SOA，以下是一些选型比较： ServiceMix提供了JBI支持，BPEL集成，关注XML消息和热部署功能，但缺点在于它的学习曲线，首要要理解JBI结构才能很好的掌握应用ServiceMix，而且ServiceMix本身体积比较大，需要花较多的时间去理解。 Mule提供了以Java为中心的模型，支持jBPM，支持消息无关，能在短时间内启动复杂的集成流程，且学习曲线短，易被JAVA架构师或者开发人员上手掌握。但没有热部署功能。 ServiceMix和Mule是活跃社区中成熟开源ESB的绝佳范例，它们代表了基于JBI的ESB和以Java为中心的ESB的方法。 Apache Synapse是面向Web服务的ESB的选择，它是基于Apache Axis2的，当要获得WS-*支持和Rest支持时，Synapse显然是一个需要考虑的ESB。 在不使用ESB的集成解决方案方面，可以通过Spring框架，在应用程序级别，不需要单独的集成容器时，将JAVA应用程序轻易的集成进来。 选择为使用哪一个，其实取决于系统需求。当面临的是关注XML标准的集成场景时，ServiceMix就是个不错的选择。如果需要低级别的集成，Mule可能是个好的选择。这两个ESB都是不错的开源集成解决方案，对于大多数集成问题都能很好地解决。 选择Mule选择不实现JBI的理由：为保持其轻量级和灵活性，提高效率和易用性。 Mule提供了一个JBI适配器来与JBI容器保持联通性。 综上所述，Mule和Servicemix都实现了ESB的核心功能，都提供了广泛的可用组件和良好的扩展性，从功能上看差别不大，但从稳定性、易用性和性能上比较，Mule可能是更好的选择。 4． 工作流原理与应用 1. 工作流简介： 工作流：把工作中的各个业务环节连接起来，让任务按照制定的方向流转，这就是工作流，实现这样功能的系统就叫工作流系统。 工作流引擎是一种软件，它通过软件的形式来定义、执行并管理业务流程（如请假、报销、公文审批等），并应用到例如OA，协同办公，ERP，生成排程等业务系统或领域，这既是工作流的思想，也可说是工作流的原理。通过工作流引擎当中提供的人工任务，实现业务流程自动运行过程中人的参与（复核、审批等）。 目标业界的工作流产品实现主要遵循的标准有两个：BPEL和WFMC。 对于一个完整的工作流产品来说它应该有一个流程设计器、一个流程管理跟踪工具（流程引擎）、还要有一套核心的API及可以对外提供服务类（业务平台）。 相关元素： · 任务：工作流中的每一个工作环节叫做任务，每个任务在流程图中以节点的方式展现，也叫任务节点。 · 模版：一个固定的被其他对象参照的数据。例如流程模板，任务模板等。 · 实例：一个参照模版创建的数据，例如流程实例，任务实例等。 · 流程模板：用来描述业务流程的模板，以可视化的图形的形式展现，流程模板定义了工作流的任务节点、流向、交互信息（例如业务表单）和流转条件等信息。 · 流程实例：依附于流程模板运行的一个实例，表示一个实实在在的工作过程，所以的流程实例都是通过流程模板的启动节点启动的。 · 任务模板：流程模板上的任务节点叫任务模板。 · 任务实例：在流程实例中，由任务模板产生的实例就叫任务实例。 · 处理实例：任务实例是用来与用户交互的，每当用户登录系统来完成一个任务实例的处理，都产生一个处理实例，来记录此次对任务的处理情况。一个任务实例可能经过指派、回退等多次处理，每一次处理即一个处理实例。一个处理实例是由一个任务实例和一个处理者（对应具体的处理人）实例组成的。 · 处理者：是指可以处理任务的一个类型，它指的是一组的集合，为了区分处理人而定义，例如部门、组织机构、岗位、角色或个人，在流程模板中为每个任务节点配置处理者。 · 流程数据：指流程按照流程模板流转时由引擎产生的数据，例如流程实例、任务实例、处理者实例都统称为流程数据。 · 业务数据：指与用户交互时产生的数据，这部分数据与具体的业务相关，例如一个销售单，业务数据在流程图上流转从而实现日常工作。业务数据与流程数据无关，没有流程数据业务数据可以独立存在。 相关标准： (1) BPEL BPEL（业务流程执行语言），即WS-BPEL（Web服务业务流程执行语言）的简称，是一种可执行的XML语言，可以用来对Web服务之间的交互加以建模。这种建模对成功地实施业务流程管理（BPM）和面向服务架构（SOA）具有重要意义，它使您可以通过组合、编排和协调 Web 服务自上而下地实现面向服务的体系结构 (SOA)。BPEL是由微软、IBM和其他公司共同推出的，经努力，OASIS组织在2004年推出了BPEL标准。 BPEL的最主要用途之一就是在分布式系统上为Web服务交互建模。BPEL通过一个单一的控制器服务，为多个服务应用提供复杂编制。用对应的WSDL契约描述它时，流程本身就可以被看成WSDL中的一个服务。 提到BPEL，通常把它和业务流程管理标注（BPMN）联系起来，BPMN的目的也是为可简化BPM建模流程。BPEL和BPMN的共同发展继续推进BPM和SOA的发展。 (2) WFMC 工作流标准组织（ WFMC ）是在1993年成立，这是由多家公司联合成立的国际标准组织。其目的是通过制定工作流技术及其标准，提高不同工作流产品之间的连通性和协同工作能力。通过使用标准可以使不同的产品之间协同工作，也可以改善工作流产品与其他IT服务（电子邮件、文档管理）之间的集成。 工作流管理系统通过对业 务、公文流转进行分析以及抽象，将不变和变化的部分进行划分，用户可轻松的通过 可视化的工具对事项的流程、流程环节涉及的人员(角色)、流程环节的表单、流程环节的操作进行修改，从而到达了应对不断变化的需求的目的，而工作流管理系统通常提供的流程监控、查询统计模块更是极大程度的为用户优化流程提供支持，以提高企业、政府的工作效率。 工作流管理系统应用： 工作流管理系统，简称WFMS，经过对业务、公文流转过程的分析以及抽象，工作流管理系统围绕业务交互逻辑、业务处理逻辑以及参与者三个问题进行解决，业务交互逻辑对应的为业务的流转过程，在工作流管理系统中对应的提出了工作流引擎、工作流设计器、流程操作来解决业务交互逻辑的问题，业务处理逻辑 对应业务流转过程中的表单、文档等的处理，在工作流管理系统中对应的提出了表单设计器、与表单的集成来解决业务处理逻辑的问题，参与者对应到的为流转过程 中环节对应的人或程序，在工作流管理系统中通过与应用程序的集成来解决参与者的问题。 工 作流管理系统为方便业务交互逻辑、业务处理逻辑以及参与者的修改，多数通过提供可视化的流程设计器以及表单设计器来实现，为实现工作流管理系统的扩展性，多数提供了一系列的API。 一个完整的工作流管理系统通常由工作流引擎、工作流设计器、流程操作、工作流客户端程序、流程监控、表单设计器、与表单的集成以及与应用程序的集成八个部分组成。 (1) 工作流引擎 工 作流引擎作为工作流管理系统的核心部分，主要提供了对于工作流定义的解析以及流程流转的支持。工作流定义文件描述了业务的交互逻辑，工作流引擎 通过解析此工作流定义文件按照业务的交互逻辑进行业务的流转，工作流引擎通常通过参考某种模型来进行设计，通过调度算法来进行流程的流转(流程的启动、终 止、挂起、恢复等)，通过各种环节调度算法(SPLIT、AND、OR等)来实现对于环节的流转(环节的合并、分叉、选择、条件性的选择等)。 (2) 工作流设计器 工作流设计器为可视化的流程设计工具，用户通过拖放等方式来绘制流程，并通过对于环节的配置来实现环节操作、环节表单、环节参与者的配置。 工作流设计器为用户以及开发商提供了快速绘制、修改流程的方式，工作流设计器的好坏决定到工作流管理系统的易用性。 (3) 流程操作 流程操作指所支持的对于流程环节的操作，如启动流程、终止流程、挂起流程、直流、分流(单人办理)、并流(多人同时办理)、联审等，象这些流程操 作都是可直接基于引擎所提供的环节调度算法来直接支持的，而在实际的需求中，通常需要自由的对于流程进行干涉，如取回、回退、跳转、追加、传阅、传阅办理 等，而这些流程操作对于工作流引擎来说是不合理的，因此必须单独的去实现。流程操作支持的好坏直接决定到一个工作流管理系统的实用性。 (4) 工作流客户端程序 工作流客户端程序为工作流系统的表现形式，通常使用Web方式进行展现，通过提供待办列表、已办列表、执行流程操作、查看流程历史信息等来展现工作流系统的功能。 (5) 流程监控 流程监控通过提供图形化的方式来对流程执行过程进行监控，包括流程运转状况，每个环节所耗费的时间等等，而通过这些可相应的进行流程的优化，以提高工作效率。 (6) 表单设计器 表单设计器为可视化的表单设计工具，用户通过拖放的方式来绘制业务所需的表单，并可相应的进行表单数据的绑定。 表单设计器为客户以及开发商提供了快速修改表单的方法，表单设计器的易用与否以及功能的完善与否影响到工作流管理系统的易用性。 (7) 与表单的集成 通常业务流转需要表单来表达实际的业务，因此需要与表单进行集成来实现业务意义，与表单的集成通常包括表单数据的自动获取、存储、修改，表单域的权限控制、流程相关数据的维护以及流程环节表单的绑定。 与表单的集成的好坏影响到工作流管理系统是否能提高开发效率。 (8) 与应用程序的集成 通过与应用程序的集成来完善工作流管理系统的业务意义，主要涉及到的是与权限系统以及组织机构的集成。流程环节需要相应的绑定不同的执行角色，而流程操作通常需要与权限系统、组织机构进行关联。 示例：Jbpm工作流步骤： 1、加载（发布）流程定义 通过Jbpm的designer插件，或者是用其他工具，制定出processDefinition ，然后将其加载到应用中的过程。这个加载可以是写入内存中，或者是直接写入数据库等。 2、启动流程 创建流程实例的过程。具体创建实例的方法有多种，可根据自己的需要自行选择。 3、处理任务 在流程流转的过程中，JBPM引擎会为我们生成任务的实例，我们就需要针对这些任务实例来进行处理，然后结束这些任务实例，并推动流程的流转。 4、记录流程的相关状态 记录流程状态这点包括且不限于以下内容： 1）流程实例的开启 2）任务实例的创建 3）任务实例的开始执行 4）任务实例的结束 5）流程实例的结束 2. 工作流选型 目前主流的商业和开源的工作流引擎 商业： (1) Oracle BPEL Process Manager Oracle BPEL工具套件是一套比较好的BPEL工具，包括引擎和定制工具以及管理控制台。Oracle BPEL Process Manager 通过将一系列同步和异步的服务组合到一个端到端 BPEL 流程流中，简化了基于面向服务的体系结构 (SOA) 开发应用程序的流程。Oracle BPEL Process Manager 为设计、部署和管理 BPEL 业务流程提供了一个开发人员易于使用的可靠的解决方案。 (2) JDeveloper BPEL Designer JDeveloper BPEL Designer 扩展了 Oracle JDeveloper 10g 的功能，并支持使用 BPEL 进行业务流程的建模、编辑和设计。它提供了一个图形化和用户友好的方式构建 BPEL 流程。JDeveloper 使用 BPEL 作为其原生格式，因此构建的流程是可移植的。 (3) IBM的WBI Server Foundation WBI Server Foundation由运行环境和开发环境组成，它的开发环境是WSAD-IE，在WSAD-IE中完成流程开发后，将流程的EAR应用部署到运行环境中。 WBI Server Foundation 的运行环境提供一个高效的J2EE工作流引擎，它由流程导航(Navigator)、人员交互相关的工作项管理(WorkItem Management)、工厂(Factory)、内部和外部接口、客户端(Client)等部分组成。 开源： (1) JBoss Jbpm JBPM是一款基于LGPL开源协议的开源工作流产品，它没有采用BPEL或WFMC标准去实现流程引擎；JBPM采用的是一套自有标准，一种轻量级的XML结构的流程描述语言JPDL， JPDL是JBPMProcess Definition Language的缩写，相比WFMC和BPEL两种标准而言，JPDL语言更加简单，也更容易读懂。JBPM提供了基于Eclipse的流程设计器。以WEB应用的形式提供了对流程的管理与控制因为JBPM采用Hibernate对流程数据进行持久化，所以JBPM可以运行于任意数据库之上。 JBPM 是一个支持复杂的企业级应用的可扩展的工作流管理系统。用直观的流程语言来表示商业流程图的术语比如，任务，异步通讯的等待状态，定时器，自动操作等等。把这些操作绑在一起，JBoss JBPM就有了最强大和易扩展性的控制流机制。对于企业应用来说JBoss JBPM只有很小的倚赖性，可以很容易的作为JAVA库来使用，当然它也可以用在吞吐量极为关键的J2EE集 群应用服务器环境中。JBoss JBPM可以同任何数据库配置，可以部署在任何应用服务器上。 JBPM目前支持三种不同的流程语言：JPDL，WS-BPEL 和 Seam框架的Pageflow。未来JBPM还会支持更多的流程定义语言。JBPM提供了开发流程、发布流程、执行流程、管理角色任务、管理商业流程、协调Web Service等功能。  JBPM是最适合扩展的代表，是在所有开源引擎中最适宜被商业化应用的一款。首先其流程建模模型是基于Activity Diagram（活动图）的，并在引擎构建上融入了FSM和PetriNet思想，所以其内核和根基比较牢固扎实。其次，自从被JBoss收购后，其3. x系列的结构更加趋于微内核，Plug-in思想也更加深入。其同时还提供了对BPEL扩展，存储支持JBoss Hibernate实现，集成了JBoss seam，规则引擎准备采用JBoss rules，并准备集成JBoss Messaging。这样，不论从内核和外围应用，JBPM都具有了强劲的动力。 JBPM的运行模式有两种：独立模式、嵌入式模式： 独立运行模式下，JBPM流程引擎会作为一个单独的组件，部署到应用服务器当中，通过提供Service为外部的应用提供工作流服务。目前大多数工作流产品都采用这种模式实现。 嵌入式运行模式，在这种模式下JBPM流程引擎作为具体应用的一个模块。这种模式较适合一些规则较小的项目，处理方式灵活。 优势： 1) 开发部署方便 工作流管理系统能够简化企业级软件开发和维护。降低开发风险，通过使用状态和动作这样的术语，业务分析师和开发人员使用同一种语言交谈。这样开发人员就不必将用户需求转化成软件设计了。实现的集中统一，业务流程经常变化，使用工作流系统的最大好处是：业务流程的实现代码，不再是散落在各种各样的系统中。加快应用开发，软件不用再关注流程的参与者，开发起来更快，代码更容易维护。部署更加方便，流程的改变不需要把全部的代码重新部署，而只是需要更改一下商业流程的描述文件。 2) 业务流程管理 使用JBPM可以提高业务流程管理的效率，可以更加灵活的控制业务流程，使流程可以按照业务的需要重新设计。并且在开发过程中更加重点的关注流程，从而使流程更加流畅和简单。同时使用JBPM可以提高对迭代开发的支持。如果软件中业务流程部分不容易更改，企业就会花很大的精力在开发前的业务流程分析中，希望一次成功。但是现实是，在任何软件项目开发中，这都很少能实现。工作流系统使得新业务流程很容易部署，业务流程相关的软件可以一种迭代的方式开发，因此使用工作流系统使开发更有效、风险更低。 JBPM可以完全的记录流程的执行情况，每一步的操作都是被记录到数据库中，可以方便以后的审计和报表生成。 (2) Shark Shark是一款遵循WfMC的XPDL标准开源工作流引擎，并且同时遵循OMG组织的Workflow Management Facility规范。XPDL的两个最重要的概念是Process和Activity。XPDL中的Activity是基于UML1.x中的活动图的概念。活动图天生的适于工作流程建模，它相对于状态图的一个最大的优点是容易做并发线程的分叉控制，这些并发线程可以同时执行也可以顺序执行；它还有一个优点是有泳道的概念，可以控制工作流引擎中的任务的产生。 在所有开源工作流引擎中，Shark的体系最为完备和复杂。其一直秉承着“模块化”的思想，所以比较容易扩展。但是自从被Together公司收购后，Shark的商业化色彩已经越来越浓，改称为Together Workflow Server，并仅以Community Edition的形式提供了部分开源代码供参考。 (3) OSWorkflow OSWorkflow是最轻量型的代表，也是一款非常灵活和低级别定位的工作流引擎的实现框架。低级别定位的意思是说，它不是定位在解决流程模型对象和运转场景，而是提供一套可维护调度的机制，供开发人员自主扩展。这个维护流程调度机制OSWorkflow选择的是基于行为（Action）的FSM理论，所以OSWorkflow更像是一个复杂而灵活的有限状态调度机。 Osworkflow有个重要概念是State，State是由step和status联合表达的，一个State就是一个step中的某个status；而state的转换由action来驱动，类似状态图中的event,因为一个event对应一个action OSWorkflow在国内项目应用得较多，很多国内的简易审批流程项目都是基于其引擎二次开发而来。这主要是由于OSWorkflow是基于Action驱动的，而国内的客户也很容易接受这样的操作习惯。但OSWorkflow所依赖的FSM模型对于分支、聚合、子流程的支持度很低。 选型比较： 目前,在工作流领域，具有代表性的开源工作流产品有Shark、OSWorkflow 和JBPM。 在此对这三大工作流引擎进行分析比较，如表： 通过对上表的分析可以得出：BPM 是比较适用的开源工作流引擎。因为相对于Shark，JBPM 更加灵活，而且以当前流行的Hibernate作为它的持久层，这使它能在不同的数据库服务器上轻松部署并方便地进行管理,另外还有全面的文档；相对于OSWorkflow，JBPM 更加简单，可以作为嵌入工作流，给了开发者更大的灵活性。同时，JBPM系统最大的特色是使用自己的流程定义语言JPDL 来精确描述业务流程，过程建模结合了UML 活动图和状态图的知识，为用户提供了可视化的面向图形的编辑流程定义的方法，业务人员 能很直观的与软件进行交互，更好的发挥了电子政务系统的作用。 IBM 软件工具： 1. Model Phase 建模阶段 Websphere Business Modeler：是一个流程建模工具，但相对易用性差 Rational Software Architect 2. Assemble Phase 集成阶段 Rational Appliction Developer Websphere Integration Developer：是IBM为SOA Methodology 设计的最重要的工具，所有的SOA概念都在这一个工具中得到或多或少的体现，WebSevice, SCA, BPEL, ESB 都有支持，简单来讲就是根据SOA概念来可视化的进行业务集成的开发工具，可以代替 Websphere Business Modeler画BPEL。 Websphere Portlet Factory 3. Deploy Phase 部署阶段 Websphere Application Server Websphere Portal Server Websphere Porcess Server：IBM的流程服务器,该服务器平台构建的次序是这样的 Websphere Application Server -> WAS Network Depolyment -> Websphere ESB Server -> Websphere Process Server。Websphere Process Server本身就是 IBM SOA 的运行平台，WebSevice, SCA, BPEL, ESB 这些内容都可以在上面部署和运行。 Websphere ESB Websphere Message Broker Websphere MQ 4. Manage Phase 管理 Tivoli Access Manager Websphere Business Monitor: 业务流程监控工具。 5. Governance 治理 Websphere Service Registry and Repository Rational Asset Manager 面向业务服务的开发： SOA是一套成熟的方法论和架构体系，发布了SCA(服务组件架构)，SDO(数据服务对象)，随着ESB的成熟，标志无论在方法论还是技术实现方面，SOA都成为了新一代首选，先进，成熟，标准的应用架构. SOA是一个完整的软件架构体系，包括运行环境，编程模型，技术标准，策略及方法论，其核心思想是服务，并涵盖服务的整个生命周期：建模，开发，装配，运行，管理。核心是业务驱动，目标是为了满足随需应变的业务需求。 每个业务服务表示一个完成的业务单元，多个业务服务组成一个完整的业务模块，多个业务模块组成一个子系统，多个子系统组成一个完整的项目或产品。比如订单服务覆盖订单可以独立开来，可以被多个业务模块复用，在容器外部可以根据具体的业务需求表现为Web Service,RMI,HttpInvoke等，与其他系统进行交互。 面向服务编程，所有的业务服务以IOC的方式注入到系统中，系统的业务逻辑，事务，领域模型，数据仓库都由业务服务单元处理，各个业务单元通过组合，可以形成一个业务组件为上层体系提供服务。为异构系统提供基于SOAP和WSDL的Web Service访问，为富客户端提供RMI远程调用。 业务服务管理模块可以为内外部系统提供服务注册功能，把基础框架，各应用系统和组件库中的组件提供的各种业务功能注册为一个服务，具体的技术实现包括Web Service,RMI,MQ等，同事提供服务的订阅，发布和监控机制。 同时业务服务还可以注册到工作流系统中，通过业务表单的形式为企业流程管理提供服务。 jbpm，“精简”的开源流程引擎 　好的开源工作流引擎不多，jbpm和osworkflow算是其中两个有特色而且比较容易实际应用的。目前一些国内的中小型流程应用项目，就是在jbpm或osworkflow的基础上扩展实现。jBpm采用了Activity Diagram的模型，而osworkflow则是FSM的模型。 　当然，这仅仅是jbpm3之后的事情。自从被Jboss收购之后，jbpm对早先的2.0构架进行了重组，整个结构完全本着“微内核”的思想进行设计。 　现在这里从技术角度来分析jbpm3的优点，简单罗列几个大家都容易看见的： 　（1） jbpm的模型是采用UML Activity Diagram的语义，所以便于开发人员理解流程。 　（2） jbpm提供了可扩展的Event-Action机制，来辅助活动的扩展处理。 　（3） jbpm提供了灵活的条件表达式机制，来辅助条件解析、脚本计算的处理。 　（4） jbpm提供了可扩展的Task及分配机制，来满足复杂人工活动的处理。 　（5） 借助hibernate的ORM的优势，jbpm能够很容易支持多种数据库。 　当然，还有一些优点，是很多开发人员并不太注意的，比如： 　（1） jbpm的Node机制非常灵活，开发人员可以很容易定制“业务化语义的节点”，并满足运行时候处理的需要。 　有很多灵活的优点，当然也少不了存在一些“局限”。 　（1） 很显然，只能有一个start-state。 　（2） jbpm依靠Token来调度和计算，在同一个时刻中，一个ProcessInstance只允许一个Token对象只存在一个Node中（分支当然用Child Token对象处理）。所以本质上就不支持“multi-instance”模式。 　（3） jbpm作为一款开源的工作流引擎，其更多的是关注“如何辅助你更容易的让流程运行完成”，但是并不记录“流程运行的历史和轨迹”。这一点可能是东西方文化的差异性所在，因为国内的流程应用，比较关注“运行轨迹”。 　至于其他的一些局限，比如不支持“回退”、“跳转”等操作，这也是因为东西方文化的差异所在。西方人认为“往回流转的情况肯定也是一种业务规则所定义，那