业务流程执行语言BPEL
（升级版）
业务流程执行语言BPEL
BPEL即业务流程执行语言，全称为Business Process Execution Language，是一种使用XML编写的编程语言。用于自动化业务流程，也曾经被称作WSBPEL和
BPEL4WS。广泛使用于Web服务相关的项目开发中，优点为具有可移植性和有效保护了投资。
BPEL是一门用于自动化业务流程的形式规约语言。用XML文档写入BPEL中的流程能在Web 服务之间以标准化的交互方式得到精心组织。这些流程能够在任何一个符合BPEL规范的平台或产品上执行。所以，通过允许顾客们在各种各样的创作工具和执行平台之间移动这些流程，BPEL使得他们保护了他们在流程自动化上的投资。尽管以前想使业务流程定义标准化，但BPEL已经引起了史无前例的兴趣，而且它最早在软件供应商中获得大量认可。
BPEL、WSBPEL和 BPEL4WS之间除了历史参考文献不同外，没有什么其他的不同。这些名字都涉及到相同的未决标准。“BPEL4WS”是起初规范的名字，它由BEA、IBM和Microsoft编写和公布的。“WSBPEL”目前是规范和未决标准的名称。当这个规范提交到OASIS时,出于Web服务相关标准的努力，按照OASIS命名方案更换了这个名字。尽管如此，大部分团体仍然简单地称这个标准为“BPEL”。
BPEL概述
BPEL是Business Process Execution Language的缩写，意为业务过程执行语言，是一种基于XML的，用来描写业务过程的编程语言，被描写的业务过程的每个单一步骤则由Web服务来实现。
2002年IBM、BEA和微软一起开发和引入了BPEL作为描写协调Web服务的语言。这个描写的本身也由Web服务提供，并可以当作Web服务来使用。
WF和WS-BPEL
SOA业务流程测试
BPEL4People在人和SOA之间建立桥梁
BPEL应用
BPEL是一种使用XML编写的编程语言。利用基于BPEL的可视化流程设计工具，开发人员可以使用拖放式图表创建在Web服务间自动交互的程序。这种活动通常被称作Web服务流程编排。虽然流程有简有繁，但是BPEL可以与运行在任意平台（例如J2EE和.Net）上的Web服务进行通信。
BPEL能够很好地将SOA的优势发挥出来。SOA是一种让IT与业务流程更加契合的基于标准的组织与设计方法论。通过标准接口和共享Web服务，SOA可以屏蔽IT环境中底层技术的复杂性，让更多的IT资产复用成为可能。这样一来，新的增强型业务流程可以更迅速地开发，并实现更可靠的提交。
解决服务的粒度的挑战
SOA与BPEL在铁路系统中应用
用于XML和Web服务的专业工具
将WebServices、BPEL与SOA结合
专注Web服务的Windows工作流基础
Verizon使用BPEL实现绿色SOA应用
使用ActiveBPEL编排、控制Web Services
BPEL与工作流的区别
BPM（业务流程管理）提供了一种图形化的自动执行与监测业务活动、集成企业应用以及管理手工任务的途径。从历史上看，BPM产品利用了自有的流程语言、设计工具和引擎。现在，BPM已经被认为是SOA架构的关键组成部分，那么缺少行业标准就成为这一领域的一个重大问题。
一种名为BPEL（业务流程执行语言）的新标准的出现为解决上述问题迈出了关键一步。BPEL最初是由BEA、IBM和Microsoft合作编写的，目前正在由OASIS组织进行审查和修改。
BPELvs工作流程基础
BPEL以外的因素 SOA的业务流程
BPEL与BPM 工作流程或融合一样吗？
专家观点
业务流程执行语言（BPEL）在开发者社区获得了广泛关注，业务流程建模标注（BPMN）在业务社区的重要性也越显突出。建立在这两个标准上的技术旨在简化分析师和开发者之间的交流以及SOA应用的开发。但是，要把用BPMN创建的业务模型转换为用BPEL写的应用，却仍然存在很大的挑战。
BPMN和BPEL如何产生的？
BPMN和BPEL有可能实现往返工程吗？
WF和WS-BPEL
Sri Nagabhirava是nleague服务公司的创始人和总设计师，专注于面向服务的方向为中心’的咨询和解决方案。
问：你能否解释一下WS-BPEL和Windows操作基础之间的区别？
答：Windows操作基础（WF）是.NET 3.0架构一种新的功能，为工作流程为基础的应用提供了一整套的服务。WS-BPEL是一种基于XML的高层次的业务流程程序设计语言。BPEL是使用XML来界定组成（Web）服务到（新）服务的业务处理执行语言。BPEL不利于业务流程模型。它不是像BPML，pi-calculus等建模语言。BPEL将要求一整套编排定义的互动与假定业务流程相结合的每一个过程，可以充分反映在一个单一的定义，包括所有可能的特殊路径。
(作者：Srinath’Sri’Nagabhirava来源：TechTarget中国)
SOA业务流程测试
Rami Jaamour, Parasoft SOA解决方案的Product Manager。 Rami Jaamour 是Parasoft SOA解决方案的Product Manager。他组成了WS-I测试工具工作组和Apache 软件基金会，WSS4J项目的一部分，执行Java的WS-Security一个开放源代码。Rami发表的文章是关于Web services安全和Web services发展自动化的测试方法。
问：是否认为，商业人士反对公司内部的IT人士，可以更有助于SOA的测试过程？
答：是的，商业模式和业务流程设计，或许使用BPM解决方案，IT可以采取的方法和执行SOA，也许使用BPEL 。您可以看到，SOA灵活性，可以引入显着的复杂性。这种过渡和映射并不总是直线前进，所以IT和业务之间的协作是需要考虑的地方，以能够更容易地适应映射现有的IT基础架构过程。
测试发生的可执行文件的进程来说，再加上资讯科技服务或一个子集，在运行过程中，使各种情况可以体现出来，在抽象的过程模型哪些是不会轻易可见。因此，商业分析师定义什么是“units”工作，而且什么是“units”工作不应该做的事情，在特殊条件下处理适当程序的行为。此外，核查认为，测试解决的使用情况最关键的是业务情况，因为在年底可能无法明确地测试所有可能出现的情况和路径，经历一个解决过程是最关键的，从质量管理的角度来看，从商业价值或影响的角度提供了一个理想的优先次序。
同时请记住，商业人士仍有自己的理解和全面的业务领域知识。BPM（SOA依靠应用软件）这一领域的知识是非常重要的，它促进真正的质量和生产率。即使是最好的映射和界定的业务流程，仍然不能取代域的专业知识。
(作者：Rami Jaamour 来源：TechTarget中国)
BPEL4People在人和SOA之间建立桥梁
在认可面向服务架构(SOA)的业务流程包括人的要素之后，现在有很多软件厂商出版了很多详细的规范。他们的目的在于将业务流程执行语言(BPEL)2.0的标准进行扩展，扩展到能够与人互动的程度
BPEL4People规范将在秋季被提交申请成为OASIS标准的一部分，但是其现在已经能够允许程序开发人员和架构师从参与的软件厂商的网站上下载获得。BEA公司技术和标准部门副总裁Ed Cobb如是说。其他的对规范提供支持的软件厂商包括IBM，Oracle，SAP AG，Adobe以及Active Endpoints公司等。
BPEL4People一直坚持亮点规范，SAP公司的行业准则部门的副总裁Michael Bechauf 解释说。WS-BPEL为人们扩展层添加的功能使用的是最近通过的OASIS WS-BPEL2.0的标准的顶层，并且其将人们的目标描述为能够在WS-BPEL过程定义当中成为一流的组件的可以合作的行为。伴随的这个规范的，是Web服务人工任务。他介绍了独立的人工任务的定义，包括财产，行为以及维持他们的行动。这两个规范都是专门设计的，因此他们既可以单独使用，也可以放在一起使用。Bechauf说道。
“BPEL4People规范为基于SOA的业务流程定义了一种方法，使得其可以通过警报和提醒的方式和人们进行交流。这些提醒和警报既可以发送到桌面有可以发到移动电话上。她解释说。规范监督工作队列也能处理包括当一名雇员生病或者出现其他不能继续工作的情况时将任务进行再分配的事件在内的情况。她还说到。
“举个例子来说，我们频繁的接到申请批准的电子邮件，而我也经常的需要提醒他们回复这些电子邮件。这个规范允许为这种流程建立模型，使得流程可以引发提醒的触发器。”
随着在SOA领域的六个软件厂商均已经对这个规范提供支持以及其即将成为OASIS标准过程的深入，BPEL4People将为程序开发人员提供一种一致的方法去描述不同环境下的人的互动过程以及包括多个组织在内的SOA应用。Jordan这样说道。
BPEL4People的目的在于避免在业务流程当中为了处理广泛的各种各样的人们交互的可能性而对建模和一次性代码编写的需要。
Jordan举了一个例子来说明BPEL4People是如何为一家电气公司工作，帮助他们对系统和涉及到解决能源耗损的人们的交互进行管理。
“例如，你在设备上安装了一些传感器，用它们来检查失误。“Jordan说道。”你可以自动进行事件的报告，保持客户服务的人们在通告的状态下使得他们可以和顾客通话。你甚至可以生成一份工作指令。但是在某种程度上，公司想要一个人去观察工作指令，并决定是否有什么专门为之设计的在允许流程发生之前的东西。一位运营专家可能想要关注这一点，并决定他们是否想要部署这家公司的维修人员或者基于已经发生的事件数量订立一个契约。
(作者：Rich Seeley 来源：TechTarget中国)
解决服务的粒度的挑战
对于我们的那些一直关注与XML，Web services和面向服务的技术的那些分析师，他们备受鼓舞的看到我们的那些听众，包括用户，供应商，以及咨询公司，他们都在问一些关于如何正确的建立构架的更加复杂而深入的问题。这一切看起来似乎是我们已经通过了低谷，并且我们的架构师已经有了关于什么是SOA和为什么他们需要它的一些好的想法。不再试着重新定义SOA是什么和它对于商业是什么意义，人们反而关注于如何正确的使用SOA这些更加重要的问题上。在那些方面，我们最近的一些对话都集中于如何构建“正确的”服务.关于这个问题的一个关键答案是确信我们构建的服务是以合适的粒度水平。
粒度是一个关于一个功能的需求模块必须以什么样的规模来满足即将到来的需求。组织细致的服务满足小单位的功能或者少量的数据。因此，为了构建复杂的商业过程，公司需要编排大量的类似的服务来有效的使这个过程自动操作，而这个处理过程是很困难的，通常是需要付出巨大努力的任务。粗糙组织的服务，尽管在一个单独的抽象接口中封装了大量的能力，减少了必须的服务请求的数目来完成一个任务，但是从不好的一面来说，这样就会返回过多的数据，或者很难再修改他们来满足不断变化的商业需求。这个选择的平衡，当然也是面向服务架构的一部分。
什么可以组成一个良好定义的服务?
在试图明白如何来划分适合粒度的服务的时候，第一个问题就是需要明白一个良好定义的服务接口必须是什么样的。一些人可能认为你所需要的就是正确的标准，然后你将会有一个良好定义的服务接口。从本质上而言，可以说良好定义的接口是一些可以被电脑理解的东西。尽管如此，你使用哪个具体的标准来定义一个服务接口并不重要，只要它为松耦合提供足够的信息。在一个SOA 中，我们的确更倾向于基于标准的交换，而不是非标准的交换，并且这似乎看起来WS-*概念栈的好的部分(特别的是 WSDL, XML Schema, WS-Security, WS-Policy,以及可能的 BPEL或者 WS-CDL)正在广泛的受到人们的接受。尽管在机器可理解的标准中有一些元数据契约是好的，但是如果简单的让这些规范对于用户来
说是可以获得的，这样并不能为如何定义服务接口和解决粒度挑战的问题提供任何的线索。确定的，很重要的是一个电脑能够理解一个提供的服务，但是这并不能使得一个服务有价值。实际上，其他的一些形式的架构也依赖于基于标准的接口，并且也没有产生我们所希望的松耦合的服务。在这一点，我们必须去掉我们的开发者的帽子，把我们的架构放上。
在我们最近的ZapFlash确定了一个服务契约有那些东西，我们讨论的事实是一个服务算不上服务，除非它是使用一个元数据编码的契约定义的。这个契约必须包含两个关键元素:规定了服务消费者和提供者两端的功能性和非功能性信息。在这种情况下，至少的，一个服务七月必须提供关于服务会做什么的明确的信息。还一句话说，一个服务必须清楚的说出它是意味着什么，并且它说了的意味着什么。用户不应该被留下来抓脑袋想在要求的输入被提供之后将会发生什么。所以，一个关于良定义的服务的更好的争论是一个服务是良定义的应该不只是意味着它只是可以被一个电脑理解的，而是要和服务所承诺提供的要完全的一致。基本地，一个人也可以理解这个服务契约，而不需要咨询额外的资源或信息。
现在，这个关于明确性的需求也逐渐的被松耦合的系统所要求了。通过一些东西，我们称之为架构的可以把这个明确的要求完成并且把服务的内部工作提供出来，或者可能提供具体的如何一个商业过程被组成的细节。尽管如此，为了让松耦合的系统工作，我们可以知道一些关于服务是如何工作的或者关于组装的过程，从而能够完成任务。即便这样，我们也许会有在与语义紧耦合的协作称之为可操作的松耦合。换一句话来说，我们需要了解服务将会做什么，同时也要知道它将会怎样通讯以使得它是有用的。从而，第一个挑战是构建一个够具体细致的服务契约元数据，但是不要太多的细节。
聚焦复用
我们仍然还没有回答那个问题及如何来决定服务的粒度的水平，尽管最后，我们可以构建良好组织的，良定义的服务和粗糙组织，良定义服务。很重要的是要知道一个特定的服务是否是单独使用的还是多用途的。你可以说最好的服务是最有用的一个，这是事实，
恰到要点。毕竟具有怎么多的冗余，良好组织的服务导致了大量的开销和低效率。很明显的具有更小的可用的粗糙组织的服务的集合在很多情况下都是一个更好的选择。尽管如此，很多开发者会把这条准则推向一个极端，并试图构建一个单独的服务，称之为，或者说，“做一些东西”是可以满足每一个单独得需求的。做某些东西将可以具有能够支持一些任意服务功能需求的一个简单接口，并且它将会产生一个相应的服务结果。
这个能做某些事情的服务的问题对于任何曾经试图实现这样的东西的人来说都是很明显的。从本质上来看，它不再是以恶可以使用的服务了，因为我们已经基本上只是把责任推给别人了，而不是让服务自己来决定自己的语义。我们只是把决定推延到更低水平的代码块上去了。本质上，我们只是把SOA看成某种类型的路由协议或者消息系统而不具有任何的固有的功能。这样的服务，明显的不能满足SOA的需求。
所以，如果通用目的的服务是一个转移注意力的问题，那么单独目的服务呢?这个问题的答案有一点拖拽。一些单目的的服务，尽管他们可能是非常良好组织的，并且只是完成特定的任务，但是他们可能异常的容易复用。那就是说，架构师也许能够把这些服务组装起来，从而能够满足很多情况的使用。相反的，可能面向领域的服务可能只能应用于特定的情况，但是事实是他们是特定于问题或者问题集合的，这正是使得他们对于商业是有价值的。并且这也是我们找到的关于试图解决服务粒度问题的第一个线索:不要关注与一个单独的服务，而是应该着眼于整个商业处理过程和在商业中服务是怎样满足多处理的需求的。一个公司越能让一个服务来完成更多的服务，那么这个服务也就越有用。对应的，如果可以调整一个服务在多个不同的处理中使用，那么需要知道的是它是否是在合适水平的粒度。
分解处理的角色
服务不是一格真正的技术概念，它只是商业想要从它的技术中获得他们的价值的一种抽象表示。同样的，我们应该关注于如何从商业的角度来定义服务——这就是说，从商业处理的角度来看，因为商业处理根本的定义了商业。
一个具体实现正确的服务的途径是:以某种商业过程为开始，然后把它分解成为递增的更小的处理子过程，直到你不能再作进一步的分解了。这些分解出来的子过程就变成了那些实现系统的候选服务。如果一个公司越多的把商业过程以这种方式分解，他们就越能看到子过程之间的公共性，从而能够有机会构建一个合适的可服用服务集合。
尽管如此，这种由上而下的过程分解方法有一个致命的弱点，那就是我们最后可能定义了一些不可能或者不够实际来实现的服务。从而，很重要的是同时经过现有商业逻辑的练习，就是基于代码级别的而不是元数据，并把它作为服务提供出来，这些服务将会作为具体的而不是全部的商业处理的候选服务，而不是采用实现处理的机制。这将跨越两个服务种类:在多处理之间的可服用的商业功能性服务和可以在组织内部为不同的服务提供值的良好组织功能性服务。
ZapThink的感受
通过这种服务定义训练的公司应该保证不要陷入这种常见的现象，致命的思维缺陷是认为一旦定义了他们的服务，就完成任务了。SOA，天生就需要不断的发展，即使公司开展的服务对于一段时间的商业是完美无缺的，但是商业会连续经历持续的变化，就需要新的服务以及新的公司服务。那些在一些时候还有刚好合适水平的粒度的服务，也许仅仅几周之后就会变得不适合了。
结果，把服务的粒度水平转化为特定的形式是没有意义的。公司必须不断的重复他们的服务设计，在一个粒度范围内构建良好定义的服务接口，然后当这些服务是合适的时候，就可以发布和使用这些服务了。面向服务架构将花他们相当多的时间把服务接口集合在一起，从而在及时地提供了足够多的关于他们商业的知识，他们可以实现在良好粒度同粗粒度组合以及单独目标同多用途之间的最优组合。
结果，开发者和建筑师们会抵制这种得到正确服务的激励。实际上，使他正确并不是那么重要，因为今天正确的明天或许就是完全错误的。毕竟，建立服务并不是SOA的目标——它正在构建一个架构，这个架构允许商业持续的改进他们的为商业所需要的有用服务的集合，并且能够调整不断进行的变化。建设这种有用的服务是为了打破多用途和特殊领
域的服务以及过度的定义和过多的不明确服务分界之间的平衡。这里没有固定的和已成定局的答案来说明哪些服务该针对特殊的公司，但是这里显然有更好的途径来是那些服务成为现实。刺激和奖励在商业中正在进行的争论将能够使得SOA对商业更有用，从而更值得去不断的书写和谈论。
(作者：Ronald Schmelzer 来源：TechTarget中国)
SOA与BPEL在铁路系统中应用
从旧金山湾区到硅谷的铁路系统最近完成了一次升级，来自二十一世纪的面向服务架构（SOA）满足了建于19世纪铁路系统的业务流程升级需求。
主要城市铁路走廊联合管理局（Capitol Corridor Joint Powers Authority ，CCJPA）副主任David Kutrosky说，在加州北部，随着汽油价格的上涨，越来越多的上班族和游客选择乘坐铁路，来替代自驾车出行。Oracle公司宣布，将在CCJPA列车推出使用无线手持设备的基于SOA票务系统，以取代纸质人工票务。
Kutrosky表示，SOA系统不仅为越来越多宁愿乘坐火车而不是开车的人群加快票务服务，而且随着加州北部上班族转向铁路系统，将会让行程更加愉快。
CCJPA是一项公共补助的服务，由美铁（Amtrak）、联合太平洋铁路公司、加利福尼亚州运输部（州交通）以及各机构和社区服务共同经营。基于SOA的票务系统已清楚定义了业务目标，并可以灵活处理不断上涨的油价所带来的交通需求变化，Kutrosky说。
“我们计划把这项服务作为一项业务来实施和运行，”Kutrosky说，“我们想留住客户，带他们上火车，让他们享受这种体验，并继续使用。”
此外，它还将为乘客提供更高的安全性，符合美国国土安全局的标准。他解释说，该票务系统将可以追踪32辆列车的乘客安全信息；每一辆列车每天途径超过170英里的铁路走廊，服务十六个站。这在加州尚属首次。
“我们能够为乘客提供的安全程度是航空业以外无法提供的。”Kutrosky说，“我们将首次知道谁在火车上，他们将要去哪里。”他进一步解释，如果火车发生意外事故或涉及到其他意外事故，CCJPA能够在三十分钟左右向执法机构和救援组织提供所有乘客的数
据。但如果是使用现在的人工系统，假如发生意外事故或其他问题，这至少要花三到四天的时间，才能够确认火车上的所有乘客信息。
基于BPEL的票务系统
Innowave技术有限责任公司是Oracle的一个合作伙伴，负责架构和实施工作。该公司的业务发展部副总裁Mike Adams介绍道，目前的票务系统依赖于不同颜色纸条和乘务
员的记忆来记录哪些乘客在哪个车站下车的信息。
该公司设计的自动售票验证服务（The Automated Ticket Validation Services）项目将通过提供基于BPEL（业务流程执行语言）的服务，让这种19世纪的办事方法实现质的飞跃，Adams说。目前已经完成规划，开发工作已经在进行之中。项目上马后，CCJPA
的乘务员将在乘客上下火车时，使用手持扫描器来验证和售车票。
扫描仪将使用无线Web连接，将CCJPA列车上的的手持设备连接到Amtrak的IT系统中。确保和Amtrak进行安全的基于Web服务标准的数据集成工作已经开始，Adams说。
“我们已经定义好了来自扫描仪的所需数据元素，所以我们可以通过安全的方法提供整合。”他说道。
SOA的票务系统将提供业务灵活性。如果在将来某天CCJPA要从无线过渡到WiFi，或者向执法机构提供数据集成，如国际刑警组织，我们可以很快速地实现这些改变，Adams 说。
正在开发的自动售票验证服务项目使用的是Oracle Fusion中间件、Oracle SOA套件和Oracle数据库。该服务将在湾区高速交通网（BART）的数据中心现有的IT硬件基础设施中进行托管，该数据中心为系统提供着日常的管理支持。
(作者：Rich Seeley 来源：TechTarget中国)
用于XML和Web服务的专业工具
Daniel Foody， Actional公司的CTO。作为Actional公司的首席技术总监，Dan Foody在通过Web服务把企业系统整合软件向轻松整合的方向转变方面的经验丰富。他是Web服务标准图队的积极参与者，该团队包括网络服务协同组织（WS-I）和结构信息标准化促进组织（OASIS），在这个团队中，他是Actional公司在OAISS管理协议技术委员会的带头人，致力于基于XML的Web服务管理标准。Dan在应用程序整合技术，包括中间设备、平台和Web服务方面的经验丰富，在SAP R/3、DCOM、CORBA 和Java等系统的复杂性方面的拥有渊博的知识。他是各种应用程序标准的作者，并对COM/CORBA交互作用的OMG标准作出了突出贡献。Dan拥有科内尔大学电机工程的理科硕士和博士学位。
问：用来证明服务中所表现的XML模式和业务逻辑这两者之间不同的更常用的工具是什么?
答：除了“usual suspects” (例如，UML工具等)之外，还有很多用于XML和Web服务的专业工具。例如使用XML模式进行检验，管理，转换的工具，例如Altova XML Spy and Contivo VMS等一些工具。对于表达和执行业务逻辑，最基本的“语言”是BPEL，许多的供应商都有工具可以使用BPEL(这些工具也经常和模式工具相结合)。当然，BPEL不
仅仅是描述服务的一种语言，它实际上更像是架构服务中的图解程序设计语言。
(作者：Daniel Foody 来源：TechTarget中国)
将WebServices、BPEL与SOA结合
Sneakerware不再为mike rulf(USinternetworking Inc. (USi)公司高级工程副总裁)提供应用程序管理方面的工作，所以最近几个月他在寻找一种综合Web services和BPEL 的SOA方法。
Sneakerware不再为mike rulf(USinternetworking Inc. (USi)公司高级工程副总裁)提供应用程序管理方面的工作，所以最近几个月他在寻找一种综合Web services和BPEL 的SOA方法。
AT&T今秋收购个人持有的USinternetworking公司(USi)。USi是全球领先的独立应
用服务供应商，致力于企业管理软件和解决方案及随需应变的服务，包括: Oracle 应用
套件以及来自Oracle的 PeopleSoft, J.D. Edwards 和 Siebel acquisitions 等应用软件。除了为财富1000客户提供数据中心和硬件服务，Rulf说USi公司的核心业务是为企业提供应用软件管理和咨询服务。
在政府规划需要严格管理功能审计(例如供应管理和身份管理)的时期，Rulf说，他发现包括 sneakerware在内的手工步骤等传统工作流程已经不能胜任工作需要。
“于是我们把注意力放到我们已经审计的流程上，”他解释到。“例如，当你在进行供应管理的过程中，你有一项任务就是‘我需要为供应的服务器获得一个IP地址。’”
通过Rulf关于过去供应管理过程是如何进行的例子，我们发现有一个专门“burned sneakers”的人管理供应过程。他会直接走进网络部门说，“请给我们为客户服务的三台服务器分配一个IP地。”一位网络管理员会回答说，“好，我会把它放到我的收件箱，
几个小时后你就会收到回复。”当供应管理员一离开这个房间，网络管理员就会编写一个Perl脚本，再出去走走，喝一杯咖啡，做一些其它网络工作，之后运行该脚本分配IP地址，完成日常文书工作，将结果提交给供应管理员。
网络管理员在回复供应管理员之前消磨额外时间，Rulf说，“因为他不希望让供应管理员知道编写、运行这样一个脚本是非常简单的事。”
如果有人对此表示怀疑，Rulf说当他与其它公司的一些IT专业人士讨论这个问题的时候，很多人都羞涩地微笑，点头同意。一些人告诉他，“是啊，我们公司里也正是这样的。”
当然，这样的工作方式不是非常有效率的，整个公司内不同部门签发的海量公文会带来大量的审计工作。当审计人员来审查看供应工作是否按照规章制度执行时，他们必须有敏锐的洞察力。这就是为什么Rulf要开发一项整合SOA、Web services, 和 BPEL的方法来代替包括sneakerware在内的传统工作流程。
他说:“你可以将BPEL想象为类固醇的分解过程。”在对用户进行应用管理的多个步骤中，BPEL协调器可以在基于不同系统的的任务更新的时候，完成信息交互，这种交互作用直至用户管理进程终结。同时，这种系统的在线批量审核处理功能可以有效的降低日常文书工作。
在对采用了BPEL供应管理系统技术的SOA和Web services的讨论中，Rulf和他的开发队伍指出了如何基于原Perl技术让管理自动化。
Perl技术是我们工作中引进的一个很好的组成部分，但是只有一些Perl的脚本语言，而大部分都是完成各个步骤工作的代码，同时相应的产生批量的文档，这就是为什么我们可以对每个工作步骤进行审核。我们只决定什么是我们需要产生的文档，然后将产生这些文档的代码打包，添加到我们的Web services中去。
回到先前我们提到的那个网管使用Perl脚本分配IP地址的事例，而Rulf他们可以
将这项服务打包进Web services，使用BPEL驱动来协调，跟踪和审核各个步骤已此来代替人工操作。
“我将其打包后，在安全模型下实现标准化，这对审核模式是十分重要的，即要确定和审核使用者是否有某项操作的权限。将一些错误处理和管理标准同时打包到BPEL中，
这样就可以解决一些可以预见到的意外情况和非法操作。我可以将这些部分打包，然后利用Web services系统来承载用户管理，从而来迎合审核制度。这些程序包可以使用BPEL 进程调用。这样就可以使每一个管理和审核步骤变得简化。”
BPEL是带有“电子追踪”特性的管理进程，而且是和审计人员工作相协调的。当审计人员想知道客户管理系统如何审核某个用户时，Rulf向他们演示了BPEL协调器如何进行工作的。
“BPEL为我们展示了这个的工作流程，记录并显示了什么人在什么时间对数据进行了怎样的变更，并沿着这样的变更，最后得到了什么样的结果。”
得到最后的信息后，审核人员也就得到了他们需要的结果。
Rulf表示:“这样的系统可以让审计人员更加快捷的得到审计需的图表，这要比一页页的翻看纸张要有效的多。这不仅仅是一个工作效率提高的问题，还可以大大的降低成本，使你从每天堆满文件的办公桌后走出来。总之，采用这样的审计系统和方法可以使成本降低两倍以上同时大幅度的提高了工作效率。”
Rulf在成本节约上还没有一个定量的精确的数据，但是有一些未经确定的事例表明，其可以将在审核上的成本降低15%。
(作者：Rich Seeley 来源：TechTarget中国)
专注Web服务的Windows工作流基础
工作流这个词语可能是软件工程领域负载意思最多的词语之一，从计算机科学101到最复杂的商业系统它基本上都成功地对应用程序的设计发挥着影响作用。在即将到来的新时期，我们将处理一个最近加入到这个世界来的新词语：Windows工作流基础(Windows Workflow Foundation，WWF)以及它将怎么样影响面向服务的设计。
工作流本身具有粒状服务的性质。换而言之，服务满足了小部分工作单元，这非常小的一部分工作单元在许多不同的场景中有利于被重用。这也反过来创造了将不计其数的结果拼接在一起作为工作流的可能性。因此从一个很简单的层面来说一个工作流只不过是一系列粘在一起来满足某种特定业务流程的服务。
在非常特殊的情况下，出现了许多解决这个工作流问题的方法：WSFL(Web服务流语言)，XLANG(业务流程设计中的Web服务)以及BPEL(业务流程执行语言)，这里仅举几例。其中，一个最有影响力的毫无疑问是业务流程执行语言(BPEL)了，部分原因是它不仅支持业界各大厂商，而且还从专卖店的角度帮助它们定制面向服务的架构。
但是尽管BPEL提供语义和深度从而来阐述详尽的Web服务场景，它仍然局限于在服务世界退居于夹缝的地位。如果你考虑严格地从服务创建工作流，你将得出一个非常现实的结论，那就是在许多企业中工作流需要非服务化应用程序或者非系统化的任务的集成，工作流将超出BPEL的范围或者其它任何目前适用于SOA的技术。鉴于这种可能性，Windows工作流基础(WWF)诞生了。
WF背后基本的前提是工作流的性质适合于跨越许多不同的层面或者软件足见。考虑一个工作流不仅由Web服务组成，而且还能够与桌面应用程序，Web服务以及遗留系统结合。它是一个强有力的抽象，是一个工作流的一部分，并且不需要服务化——严格按照SOAP/XML——像BPEL等方法是需要的。
基于BPMN的业务流程一体化建模方法 BPM业务分析员业务流程一体化建模 为了给业务分析员提供一种简单易懂、直接支持计算机仿真和执行的可视化业务流程建模方法，提出了业务流程一体化建模概念及方法。本文通过实际研发业务流程管理系统，验证了该方法的可行性。 0 引言 业务流程建模是指用图形、公式、表格或文字描述业务流程的特性，回答为什么做、做什么、怎么做、谁做等问题。文献指出业务流程建模方法主要有：①流程图(flow chart)，是最早用于业务流程的一种图形化描述方法，易学习、好理解，但存在无法清楚界定流程界限、不支持层次化描述业务流程等问题；②角色活动图(Role Activity Diagram，RAD)和角色交互图(Role Interaction Diagram，RID)，擅长描述角色与活动、角色与角色的交互关系，但不支持层次化描述业务流程；③IDEF0和1DEF3，IDEF0描述业务流程做什么，但没指明谁做；IDEF3回答了怎么做，但描述复杂业务流程难度大；④高级Pet“网有很强的数学基础，可以计算／仿真分析业务流程性能，如文献和文献，但用户的学习难度大；⑤统一建模语言(Uniform Modeling Language，UML)活动图易学习和使用，但模型的仿真和分析能力差。此外，业务流程建模方法还有事件驱动过程链(Event-driven Process Chain，EPC)f4l及其扩展EPC、事件一条件一行为(Event—Condition-Ac—tion，ECA)规则等。但是，这些方法没有一个可以同时满足业务分析员可视化设计、分析、仿真和执行业务流程模型需要。 业务流程建模是实现业务流程管理(BusinessProcess Management，BPM)的基础。实施业务流程管理可以提高流程效率，增强企业竞争力，“执行力就是竞争力。使用业务流程建模方法的终端用户是业务分析员。对业务分析员来讲，最理想的建模方法是简单、易学、好用，支持可视化描述业务流程，可以验证模型结构正确性，计算／仿真分析模型性能，支持计算机运行模型的方法。要实现这一目标。需要研究如何将模型的描述符号、存储结构、元素语义、仿真机制、执行机制等融合在一起。正是由于没有一种能同时满足业务分析员设计、分析、仿真与执行业务流程需要的建模方法，BPMN十XPDL+BPEL因此成为当前最流行的一种业务流程建模解决方案。 业务流程建模符号(Business Process ModelingNotation，BPMN)是业务流程管理倡议组织(BusinessProcess Management Initiative，BPMI)于2003年提出、被对象管理组织(Object Management Group，OMG)采纳的一种建模规范阳。它提供的图形建模符号易被业务分析员理解，是目前最流行的业务流程可视化描述语言。但是，BPMN 规范没有定义业务流程图(Business Process Diagram，BPD)的存储结构，Process元素语义不明，因此BPMN模型不能直接用于计算机交换、仿真、执行。基于可扩展标记语言(Extensible Markup Language，XMI。)的过程描述语言(XML Process Definition Language。XPDL)规范阳3是工作流管理联盟(Workflow Management Coalition，WfMC)推出的一种业务流程建模方法，支持用BPMN图形符号描述业务流程，定义了业务流程图的存储结构和仿真语义，XPDL模型可用于交换，但Process元素的显示语义与执行语义混在一起，不利于计算机执行。业务流程执行语言(Business ProcessExecution Language，BPEL)规范¨0]是结构化信息标准促进组织(Organization for the Advancement ofStruetured Information Standards，OASIS)推出的一种可以有效编制多个Web服务的执行语言，执行语义明确，可用于业务流程建模。BPMN规范支持将BPMN模型转换为BPEL模型用于计算机执行，文献研究了将BPMN模型自动转换成BPEI。模型的方法。但BPEL模型的结构／半结构化描述方式对于非结构化业务流程图来讲，有时很难实现转换，对业务分析员绘制业务流程图有太多限制；并且这种转换是单向的，转换后得到的BPEL模型，业务分析员可能无法读懂。为了统一XPDI。和BPEL，文献基于XPDL元模型和BPEL元模型设计了一个元模型，但没有给出元模型的仿真与
5. 业务流程分析p83 流程分析的目的是了解各个业务流程的过程，明确各个部门之间的业务关系，明确每个业务处理的意义，为业务流程的合理化改造提供建议，为系统的数据流程变化提供依据。 业务流程分析的步骤可以总结如下： (1)通过调查掌握基本情况。 (2)描述现有业务流程—绘制业务流程图。 (3)确认现有业务流程。 (4)对业务流程进行分析—知识和经验支持。 (5)发现问题提出解决方案。 (6)提出优化后的业务流程。 6. 业务流程再造(Business Process Reengineering,BPR)的概念 BPR是指对企业的业务流程进行根本的再思考和彻底的再设计，从而使企业的关键绩效指标，如成本、质量、服务、效率等，获得巨大的提高。 企业流程再造(BPR)应遵循以下原则： ·有一个明确的、具有启发性的目标，即共同远景。 ·充分考虑顾客的价值。 ·必须服从统一指挥。 ·充分做好横向及纵向沟通。 ·认识流程再造的两大要素—信息技术/信息系统和人员组织管理。 ·树立典范、逐步推进，充分利用变革的涟漪效应。 流程再造方法一般有两大类：全新设计法(Clean Sheet Approach)和系统改造法(SystematicRedesign)，前者遵循“推倒重来”的主张，从根本上抛弃旧流程，零起点设计新流程；后者继承逐步改善的思想即BPI的思想，辨析理解现有流程，在现有流程的基础上，系统渐进地创造新流程。 7. 数据流图DFD p87 结构化分析方法是一种面向数据流的软件分析方法，适合于开发一些数据处理类型的软件的需求分析的方法。 采用数据流图的方式进行数据流程分析一般应遵循以下原则： ·明确系统边界。 ·在总体上遵循自顶向下逐层分解的原则 ·在局部上遵循由外向里的原则
IDEner创意孵化项目系统建模 前言 以下分别采用业务流程建模和UML建模两种建模发放对系统设计进行建模。其中UML 面向对象系统设计建模中，我们采用了类图，对象图，Communication Diagram（通信图），状态图。 说明：由于参考文献问英文文档，有些翻译可能不是很贴切。 1. Business Process Modeling（BPM）业务流程建模 业务流程建模通过一系列的技术和标准实现对业务流程进行分析设计，实施以及执行。能够帮助识别，描述，分解业务流程。BPM支持三种流行的流程语言：Analysis languages，Service Orchestration languages,Collaborative languages。后两者语言能够直接生成代码。 1.1 Process Hierarchy Diagram（PHD）业务架构图 业务架构图给出了系统功能的视图，并且将一个流程分解成多个子流程。分析阶段分析师和经理用使用此图。 IDEner创意孵化系统的业务架构图如下。 图1 IDEner创意孵化系统的业务架构图 1.2 Business Process Diagrams（BPD）业务流程图 业务流程图给出了系统各个层面流程间的控制流和数据流的视图。业务流程图可以是业务架构图中的一个子流程。 对于系统的不同层面，有以下三种业务流程图 1.2.1 Top-level diagram 描述业务伙伴之间的关系。 对于图1 IDEner创意孵化系统的业务架构图中的Bind Advertise子流程我们进一步分解成业务流程图得到图2。
图2 Bind Advertise Top-level diagram 1.2.2 Choreography diagram 改图通过控制流将业务流程连接起来，可以有一个或者多个开始，也可以由一个或多个结束。 对于图 1 IDEner创意孵化系统的业务架构图中的Bind Advertise子流程得到的Choreography diagram 如图3 Bind Advertise Choreography diagram。 图3 Bind Advertise Choreography diagram 1.2.3 Data Flow Diagram（DFD）数据流图 数据流图能够表示数据的在系统中的传递情况，反映了体现为系统功能的业务流程间的数据交互情况。 图1 IDEner创意孵化系统的业务架构图中的Bind Advertise子流程的数据流图图4如下。
流程业务流程管理的方法与步骤(实战干 货)1 流程业务流程管理的方法与步骤（实战干货） 随着企业所面临的竞争越来越激烈，企业必须通过更加高效的运做系统来不断提高自身的应变能力和适应能力，这其中业务流程管理是最为重要和有效的方式之一。但我们同时发现，相当多的企业重视业务流程的规划，轻视对业务流程管理，于是在企业的内部管理中出现了很多问题，最为常见的问题是：1、有流程，无执行：企业制定的很多流程停留于书面，但真正被用于实践中的很少。流程形同虚设。2、流程与实际运做脱节：由于外部环境瞬息万变，企业的运做也随之而变，这本是好的，但指导业务规范运做的流程还停留在以前的状态，其最终的结果是对流程的放弃和不信任。 3、流程与流程之间的割裂：特别是集中在跨部门和跨业务单元的流程上，由于流程之间的割裂，导致企业内部存在着大量的界面冲突，于是只好借助大量的会议、更多和更复杂的流程来试图解决。其代价就是拿着公司的资源在做游戏。 4、没有业务流程管理混乱，有了业务流程管理僵化：这一点对于那些有上进心的企业一直是个头痛的问题。在效率和效果上难以找到最合理的解决方案。 5、业务流程的根本是业务，但流程业务的授权和监管不同步：导致的结果是当业务运做出现错弊时，责任不清，互相推脱，更加谈不上对于流程的改进了。
6、流程繁多，层次不清：许多企业制定了 大量的业务流程，但没有对流程进行分层和分级管理，以至于无法保证对业务目标的实现。 这些问题的根本原因都归于对业务流程管理的薄弱和失当。这里特别要强调的是业务流程管理不是在流程规划出来之 后才进行的，而是在流程规划之前就要进行管理。因此，良好的业务流程管理的步骤包括流程设计、流程执行、流程评估和流程改进，这也是一个PDCA闭环的管理过程。 逻辑关系：1）明确业务流程所欲获取的成果。2）开发和计划系统的方法，实现以上成果。3）系统地部署方法，确保全面实施.4）根据对业务的检查和分析以及持续的学习活动，评估和回顾所执行的方法。并进一步提出计划和实施改进措施。 一、业务流程设计： 业务流程设计是业务流程管理中最为重要的一个环节，它直接影响到未来流程实施中的效率和效果。在流程的设计阶段需要强调的系统化的设计，流程的系统化设计包括以下几个方面： 1、流程设计的目的：业务流程的目的主要包括管理稳定、规范运做、控制风险、增值服务和支持业务目标的实现。也就是说在公司业务目标的指导下，以风险分析为基础而制定的有助于管理稳定、规范运做和服务增值的业务流程。风险可以用数学方程式表示如下：R=pr（E）R代表风险，E代 表潜在的损失，pr代表由于管理失当而导致损失的可能性。
大家好 管理工程部的变革、供应链中心成立管理处，当时的初衷就在于设立流程管理的专职人员和部门职责，建立流程持续优化和审核的制度，最终推动流程落地，解决管理实际运行和体系两张皮的现象，两年过去了，我们自我反思，我们在这方面还做的很不足，体系和管理处还无法就流程、制度和体系方面做有效的整合，每次体系审核或者客户审核的时候，还存在体系规定和实际执行不一致的现象，为了体系审核编造一些过程文件和记录的现象还有存在，所以大家看了以下文章应该要有感触，管理处和体系部门应该有工作思路和想法，应该快速拿出具体的计划和行动，解决这些不正常的现象。我建议如下： 1、根据业务主流程或者价值链，分模块搭建起流程和文件的框架体系。能够通过这个框架体系一目了然掌握每个业务节点上的程序文件、作业规范、和记录表单是否完善。 2、管理处和体系定时对流程的执行进行审计和优化，不断充实这张框架图。 3、通过一至两年的运行，我们的整个管理的制度和流程会非常的系统化和体系化，而不至于目前这种现状，缺乏系统比较零散。而且和体系的运行处于两张皮的现象，所以务必要解决体系文件、管理制度和办法、业务流程和实际运作这几方面的无缝衔接。 请各部门认真阅读以下文章，并能学习到其有效的流程管理的方法，谢谢！ 业务流程持续优化的三个方法 流程在优化完成后，并不意味着结束，因为流程优化不是“一锤子买卖”，流程管理不是“一次性革命”，需要追求长治久安，进行持续改进。为保证流程的持续优化和落实，需要从以下两个方面入手： ?流程的持续改进不能完全由兼职人员完成，需要专门的人员负责。 ?流程管理不应是孤立开展，需要和制度、绩效有效结合。 一、设立专职的流程管理专员
石家庄方州担保有限公司 业务操作规程 第一章总则 第一条为明确担保业务操作程序，加强内部控制与管理力度，确立业务环节的制衡关系与岗位责任，提高工作质量与效率，特制定本规程。 第二条本规程用以规范担保业务的项目受理、评审、风险评估、法律性文件审查、评审委员会评议、决策后的执行与监督六个主要工作环节，以使各个环节、各岗位有章可循、各司其职，保障担保业务有序、高效进行。 第三条本规程适用于本公司开展的各类担保业务，规范各部门的操作行为。 第四条各部门、各岗位在执行中，应在业务制衡的基础上，相互协作、配合，坚持公司利益高于一切的原则，以高度的责任心和饱满的工作热情履行公司制定的岗位职责。 第五条公司评审委员会在特殊、加急等情况下特定批准的项目及业务，各部门、各岗位依然不得越权或违反规程操作，必须严格按照本规程所规定的操作程序，以高质量的工作效率完成特事特办的任务。 第二章受理 第六条本规程所称项目受理，系指公司接受担保客户的申请，启动担保项目评审程序。项目受理阶段，指从通过各种途径与担保客户接触开始，到完成《担保客户基本情况登记表》等基础资料，送达评审部责任人止。 第七条受理阶段主责任人为综合管理部经理和受理责任人；公司其他部门各岗位人员在综合管理部统一管理下亦有义务接待和受理相关的客户。
综合部经理直接负责和组织受理责任人向客户提供咨询和受理服务，本着申请客户依法注册、符合担保服务范围和有提供基础资料的能力三项条件，确定是否受理，并对受理的项目进行登记，建立与客户的沟通渠道。对于暂不符合三项条件的客户，暂不予受理，但应积极采集客户可提供的信息，建立并备案联系渠道。 第八条受理阶段的工作职责：登记、整理担保初审资料，着重、详细填写好《担保客户基本情况登记表》及相关信息资料，附《担保调查通知书》，按受理时间顺序登录项目，顺次分配至评审部评审责任人，同时详细建立本阶段内相应的项目跟踪进程表和基本数据库。 第三章评审 第九条本规程所称项目评审，系指评审部门对申请担保客户的技术水平、经营状况、管理状况、财务状况、资信状况、技术水平等方面进行深入调研和分析，提出明确评审结论，协调与贷款银行的合作关系，确定合同要约，落实反担保措施等诸项事务。 项目评审阶段，指从评审责任人接受待审项目开始起，到完成《担保客户基本情况调查验实表》《担保调查评审报告》《评审报告基本表》《评审报告审批表》和《担保合同编制依据报告》止。 第十条评审阶段主责任人为评审部经理、项目经理和助理以及其他有资格的评审责任人。对于评审阶段主责任人，本规程中统称为“评审责任人”。 评审阶段主责任人职责：按照规定的评审规范和程序，高效地完成担保项目的初审和详审工作，作出明确结论，并完成签约前合同准备及反担保方案的落实，为决策及担保执行提供全面、详实、准确的依据和基础资料。