2008年5月19日星期一

SOA_022:BPMN、XPDL、BPEL 辨析

◆ BPMN是一种图形化的业务流程建模工具。XPDL和BPEL是实现模型的两种方式。BPMN可以转化为XPDLBPEL
◆ XPDL是一种基于XML的流程定义语言,其中定义了流程图具体“长相”,主要是为了不同业务流程建模工具之间可以互相交换流程建模图。比如:无论建模工具是否支持BPMN建模,都应该可以把模型保存为XPDL格式,方便与其它建模工具交换。
BPEL是一种编排Web服务的编程语言,由业务流程引擎“编译”并执行。它没有定义流程图具体“长相”。另外,BPEL的主要支持基于Web服务的自动化业务流程,没有人工活动的定义,也没有考虑任务列表等问题。但业务流程往往需要人工参与执行,为此需要对BPEL进行扩展。事实上大多数BPEL产品都自行扩展了对Human Workflow的支持,一般借助是BPEL异步服务调用的方式变通实现。新的补充规范BPEL4People、WS-HumanTask尚未正式提交给OASIS

关于XPDLBPEL的区别下面这张图非常形象:






参考文献
1. http://forums.microsoft.com/msdn/showpost.aspx?postid=347855&SiteID=1
2.

SOA_021:XPDL介绍

【WfMC】:Workflow Management Coalition 工作流管理联盟。
【XPDL】:XML Process Definition Language 基于XML的流程定义语言。
XPDL是一种流程设计格式。它用“图画”的方式展现流程。
每一个节点的属性包括位置坐标、大小、所属角色、有哪些活动,是否有定时器,调用哪些Web服务等等。
XPDL2.0完全支持BPMN1.1。XPDL最新版本是2.1。
XPDL使得不同的流程建模工具可以互相交换流程建模图。更多信息请访问:http://www.wfmc.org/standards/xpdl.htm

SOA_020:BPMN介绍 (摘录+整理)

【BPMI】:Business Process Management Initiative 业务流程管理促进会
【OMG】:Object Management Group 对象管理组
【BPMN】:Business Process Modeling Notation 业务流程建模符号
BPMN提供了一套标准的图形符号来描述业务流程,即业务流程建模语言。
所有人员(业务分析人员、业务开发人员、业务管理人员)都使用BPMN来描述业务流程,最大程度地消除了理解上可能存在的歧义,保证业务流程的实现完全忠于设计。BPMN最初由BPMI制定,现在由OMG管理,目前版本是1.1。更多信息请访问:
http://www.bpmn.org/

以往的业务流程模型和真正的系统设计实现往往是脱节的,而使用BPMN创建的模型可以转换成XPDL或BPEL,从而保证了二者的完美统一。

BPMN标准的图形符号如下:
1. 四种基本元素
(1)Flow Objects:包括Event,Activity,Gateway。
(2)Connecting Objects:包括Sequence Flow,Message Flow,Association。
(3)Swimlanes:包括Pool,Lane。
(4)Artifacts:包括Data Objects,Group,Annotation。

2. 流对象 (Flow Objects)
流对象是核心元素。

2.1 事件 (Event)
业务流程中发生的事件。用圆圈表示。事件会影响流程的状态。
一个事件一般有一个触发器或一个结果。
事件有三种类型:开始、中间、终止。

2.2. 活动 (Activity)
业务流程中的某个特定的业务,如登录,注销。用圆角矩形表示。
活动有两种类型:Task 任务,Sub-process 子流程。

2.3 网关 (Gateway )
业务流程的分支与合并。用菱形表示。
3. 连接对象 (Connecting Objects)连接对象将流对象连接起来以组成业务流程。
3.1 顺序流 (Sequence Flow)用实线实心箭头表示,代表流程中将被执行的活动的执行顺序。
3.2. 消息流 (Message Flow)用虚线空心箭头表示,用来表示2个分开的流程参与者(业务实体或业务角色)之间发送或者接收到的消息流。
3.3 结合关系 (Association)用点状虚线表示,用于显示活动的输入输出。
4. 泳道 (Swimlanes)
用以区分不同的功能和职责。

4.1 Pool
代表流程中的一个参与者。主要用于2个独立的实体或者参与者之间的物理划分,通常在B2B的交互流程中出现。

各个Pool中的活动通常是有自身的流程的。因此,顺序流通常不会越过多个Pool的,而消息流是可以的,如下图就是一个带Pool的业务流程图。
4.2 Lane
Pool的子划分,用来对活动的组织和分类。

Lane常用来将活动按照角色划分,流程可以在一个Pool中跨Lane流转,但是在同一个Pool中消息流通常不跨Lane流转。


5. 描述对象 (Artifacts)
用来描述流程中的对象。


5.1 Data Object
Data Objects are用于描述活动所需或者产生的数据。他们用连线与活动连接起来。

5.2 Group
用于描述和解释目的,不会影响流程的流转。

5.3 Annotation
提供一些附加性的文本信息给流程图的阅读者。




问题1:如何把BPMN能否转化成XPDL?
//TODO


问题2:如何把BPMN能否转化成BPEL?
参见BPMN规范中的
Mapping BPMN to BPEL Example

参考文献
1.
http://en.wikipedia.org/wiki/BPMN
2. 《BPMN规范简介》作者:
http://gocom.primeton.com/blog11165_19935.htm
3. 《BPMN 简介》作者:
http://grid-qian.javaeye.com/blog/148620

2008年5月13日星期二

SOA_012:SOA 集成架构



SOA 集成架构分为五层,每层使用不同的技术和标准,五层一起构成了一个完整的SOA应用。

1. 业务服务层:抽象服务,创建服务。
(1)WSIF:Web Services Invocation Framework.(由Apache WebService项目组提供)
WSIF提供了一套API用于调用Web services,无论这些服务是由谁提供的。
WSIF中提供的API允许编程者通过WSDL描述内容和web服务调用的抽象层打交道,而不是直接使用SOAP来调用web服务。
好处:使用WSIF后就可以使用统一的编程模型来调用web服务而不需要了解该web服务是如何实现和被访问的(Java、EJB、Servlet、.Net、C#)。

2. 服务总线层:功能 连接各种不同的服务,路由和转换消息,为服务增加各种策略。
(1)SAML:Security Assertion Markup Language. (由OASIS制定)
SAML是一个基于XML的标准,用于在不同的安全域之间交换验证和授权数据。
安全性断言是关于用户身份的语句,只能通过接收断言发布者的站点信任获得支持。
好处:解决 Web Browser Single Sign-On(SSO)和 role-based access control(RBAC)问题。

在SAML中,发布断言的站点叫“发布者”、“断言方”、或“源站点”。接收断言并信任它们的站点叫“信任方”或“目标站点”。
举例说明1:用户甲先登陆A站点,然后访问B站点。
B站点将向A站点发送SAML请求(包括浏览器凭证,SOAP消息),返回通过验证的用户名(包含时间之窗)。
源站点只负责验证,不负责授权(目标站点负责授权)。

举例说明2:用户经常访问3个应用,由用户名/密码验证方式改成指纹认证方式。
只需要再一个地方改变认证方式即可,其它目标站点无需知道源站点的认证方式的修改,因为底层SAML断言不变。

(2)Web Services Manager, Oracle提供的用于确保服务的安全性、可靠性。
好处:服务开发人员专注于业务逻辑的实现。
安全专家专注于服务的安全设计,保证服务的安全访问。
服务的安全策略集中化管理,而不是分散到每个服务之中。

(3)WS-Policy:对服务的断言,描述了服务提供者要求服务请求者必须提供一些信息。(由W3C制定)
策略断言:传输协议,安全性,事务性,可靠性。
WS-Policy只是一个框架,为特定的域定义一套特定的策略断言则是系统管理员的任务。

(4)WS-Security:(由OASIS制定)
WS-Security规范主要描述了如何将XML Signature和XML Encryption与已有的安全技术(Kerberos,X.509,SAML)结合, 并把它们绑定到SOAP中。
与HTTPS的区别:
a.HTTPS提供的是点对点安全保护,而Web Services应用的一个特点就是消息往往就要经过多个中介才能到达最终的服务提供方,每个中介都有可能对消息做出些处理,也就是说它需要的是端到端的保护。这显然是HTTPS所无法提供的。
b. HTTPS是在传输层提供安全保障的,而不是在消息层,也就是说消息只有在传输过程中才是安全的(加密的),而一旦到达了终点后就不再安全了。恶意攻击者可以从消息队列中将重要的信息窃取出来。
c. HTTPS分配好共享密钥后,传递消息的时候并没有使用数字签名技术,此时传递的消息也就无法获得抗否认性的能力。而这一项功能恰恰是在电子商务中不可豁缺的。
d. 由于HTTPS提供的是传输层的安全,当然也就不可能达到消息安全所需要的灵活性的要求。例如加密消息中的部分元素;使用不同的密钥加密消息的不同部分,从而让不同的消息接收者查看与之对应的信息。

(5)SLA:Service Level Agreements. 服务品质协议。
是服务提供者和使用者之间的一个正式合同,用来保证可计量的网络性能达到所规定的品质。
精确定义:服务提供时间百分比;服务平均响应时间;出现故障时的平均响应时间;无法满足时赔偿;退出条款。

(6)QoS:Quality of Service. 服务质量。
是指网络提供更高优先服务的一种能力,包括专用带宽、抖动控制和延迟(用于实时和交互式流量情形)、
丢包率的改进以及不同WAN、LAN 和 MAN 技术下的指定网络流量等,同时确保为每种流量提供的优先权不会阻碍其它流量的进程。

(7)XML Signature: 保证XML消息的完整性(Integrity),确保消息在传输的过程中没有被修改。
通常会对消息做摘要(Digest),再使用密钥(对称,非对称)加密摘要,从而保证消息的完整性。
可以对任一元素、任一资源(URI所指向的资源:图片,其它XML)签名,也可以对整个文件签名。 标准化处理:XML文件的特殊性,元素的属性位置调换不代表该XML文件完整性被破坏;换行符在不同平台下的字符不同。
签名过程:定位资源作必要转换(二进制转换成Base64编码)做摘要标准化处理用私钥签名标准化后的摘要。

(8)XML Encryption: 保证XML消息的机密性(Confidentiality)
可以对任一元素、任一资源(URI所指向的资源:图片,其它XML)加密,也可以对整个文件加密。
通常使用对称密钥加密消息。
为了保证对称密钥的安全性,消息发送方使用消息接收方的公钥加密对称密钥,消息接收方使用自己的私钥解密出对称密钥。

(9)身份鉴别(Authentication):确保消息发送者的身份与消息中所声称的用户身份一致。
a. UsernameToken:
使用用户名和密码来验证用户的身份是最普通也最常见的方法。
用户在发送请求的时候,在SOAP HEAD中加入自己的用户名以及密码。
消息接收者通过之前与消息发送者建立的共享密码来验证密码的合法性从而实现鉴别用户的功能。
实现原理:消息发送者随机产生了一个对称密钥并用它来加密和签名SOAP Envelop中的元素(如UsernameToken ),然后通过使用消息接收者的公钥来加密该对称密钥,从而达到验证消息完整性,解密数据以及鉴别用户身份的目的。

Q: 在SOAP包中传输密码怎么保证密码的安全性?
A: 使用密钥加密,只有接受方能解密密码。
Q: 怎么从用户名密码中获得签名和加密所需要的密钥?
A: 随机产生密钥,并通过接受方的公钥加密,保证密钥不被别人所知。
Q: 如何避免重放攻击? A: 由于其他人无法获得密钥,所以即便截获消息也无法冒充。
Q: 直接使用密码派生密钥被破解了怎么办? A: 密钥不再从密码派生,而是每次随机产生,即便被破解也不会影响其他的消息和其他的服务。
Q: 用户密码必须以明文形式保存在服务端?
A: 由于密码被加密而不是做摘要所以不需要服务端拥有明文密码。

b. BinaryToken KerberosToken X.509Token

3. 流程编制层:功能 编制服务
BPEL: Business Process Execution Language 业务流程执行语言
作用: 将现有的服务组合起来,生成一个新的服务。BPEL是一种实现服务组合的语言。
有哪些组合:
(1)控制流(条件分支、循环、并行)
(2)异步操作
(3)错误处理、异常处理、补偿处理逻辑
(4)长事务处理

4. 用户界面层:功能 开发用户界面 保证跨浏览器、跨平台的外观一致。
(1)WSRP(Web Services for Remote Portlets),一个定义了如何利用基于 SOAP 的 Web 服务在门户应用程序中生成标记片断的规范。
通过定义一组公共接口,WSRP 允许门户在它们的页面中显示远程运行的 portlet,而不需要门户开发人员进行任何编程。
对于最终用户,这些 porlet 就和运行在他们本地的门户上一样,但是实际上这些 portlet 来自于远程运行的 portlet 容器,并且是通过 SOAP 消息的来交互的。
在面向服务的体系结构中利用 WSRP 将是一个强大的组合,从而使面向呈现的 portlet 应用程序可以被发现并重用而不用任何额外的开发和部署活动。

(2)JSR-168:开发portlet的Java API。

好处:可移植性,容易在门户服务器之间移动。

5. 监控层:监控、分析、并作出一定的响应(不仅仅是监控)
(1)如何实现粗(细)粒度的实时监控?
细粒度:每一个业务流程实例
粗粒度:更高层次的业务活动
监控: KPI
分析:关键的业务环节,当前各个环节有多少个负载,每个环节平均响应时间,确定瓶颈
响应:定制各种仪表面板,警报,是否采取行动(手动/自动)
不同角度视图:销售部门,运营部门,CEO。

(2)JMX Java Management Extensions,Java管理扩展框架
是一个为应用程序、设备、系统等植入管理功能的框架。
可以跨越一系列异构操作系统、系统体系结构和网络传输协议,灵活的开发无缝集成的系统、网络和服务管理应用。

2008年5月12日星期一

SOA_011:如何评估ESB容量 (摘录+整理)

为了评估ESB所需要的容量,需要考虑以下方面:
■ The number of message instances
■ The path through the ESB for each message
■ Throughput of ESB messages, including:
– Peak throughput per hour
– Sustained throughput per hour
■ Load of ESB messages, including:
– Peak load start time and duration
– Sustained load duration
■ Resource sizing
– The number and sizes of documents, or payloads, passed between the ESB
processes and the web services they use
– The average response time for synchronous process during normal load
– Average response time for synchronous process during peak load
■ Fault-tolerance – is High Availability required, or is cold failover acceptable?
In addition to business requirements, the needs of the ESB processes that will be used
need to be considered and estimated. These needs include:
■ Payload size
Select the system resource capacity to accommodate the anticipated payloads plus
reserve capacity. This is particularly an issue for Java-based application server
components. For example, a 50 MB XML document in memory is large and
therefore a challenge to process unless system resources are unusually generous.
For efficiency, the best practice is to break up large payloads into smaller pieces.
■ Data transformations performed
■ End points and integration points
■ Number of Web services used and how often the ESB process invokes them
■ Type of Web service invocations, synchronous or asynchronous
■ Anticipated response times for both synchronous callbacks

SOA_010:ESB 交互模式总结 (摘录+整理)

  1. Simple synchronous request/reply flow

  2. Non-deterministic synchronous request/reply flow
    • Consumer does not explicitly know the service provider
    • Service provider selection based on message content/header



  3. Simple 1-way asynchronous flow
    • The simplest but also the most typical ESB pattern
    • “Fire-and-forget”

  4. Fan-out 1-way asynchronous flow
    • 1 event triggers multiple parallel operations
    • All outbound operations can be grouped in one or more transactions


  5. Response-forwarding

  6. Canonical Data Model

    • All messages on the bus are converted to a common data model
    • Reduces the overall number of maps to generate
    • Respective application owners only need to know about 2 data models: their own one + the canonical one.

SOA_009:BPEL 交互模式总结 (摘录+整理)

1. One-Way Message
左边调用方的BPEL定义中只有Invoke Activity。
右边被调用方的
BPEL定义中只有Receive Activity。
2. Synchronous Interaction
左边调用方的BPEL定义中只有Invoke Activity。
右边被调用方的
 BPEL定义中使用Receive Activity接收请求,使用Reply Activity发送响应。
被调用方的 BPEL定义是一个同步的BPEL,所以只要看到
Receive +  Reply Activity就知道这是一个同步的BPEL。
3. Asynchronous Interaction
左边调用方的BPEL定义中使用Invoke Activity发送请求,使用Receive Activity接收响应。
右边被调用方的 BPEL定义中使用Receive Activity接收请求,使用Invoke Activity发送响应。
被调用方的 BPEL定义是一个异步的BPEL,所以只要看到 Receive +  Invoke Activity就知道这是一个异步的BPEL。
同时,调用方的BPEL定义让我们知道调用一个异步的BPEL所要用到的Activity
4. Asynchronous Interaction with Timeout
如果调用异步的BPEL,但响应迟迟没有回来怎么办?
这时,我们可以使用Pick Activity + 分支onMessage 和onAlarm。
如果在onAlarm规定的时间内响应回来了,则走onMessage分支;
如果在onAlarm规定的时间内响应依然没有回来,则走onAlarm 分支,放弃等待响应。

5. Asynchronous Interaction with a Notification Timer
如果调用异步的BPEL,响应迟迟没有回来,但由于响应很重要,所以必须要继续等,这时有什么好办法通知管理员?
这时,我们可以使用Scope Activity(其中包括Invoke Activity和Receive Activity)+ onAlarm。
如果在onAlarm规定的时间内响应回来了,则Receive Activity 接收响应;
如果在onAlarm规定的时间内响应依然没有回来,则执行onAlarm 分支,然后继续等待响应。
6. One Request, Multiple Responses

7. One Request, One of Two Possible Responses
8. One Request, a Mandatory Response, and an Optional Response


9. Partial Processing


10. Multiple Application Interactions

2008年5月11日星期日

SOA_008:如何提高SOA应用的性能?(摘录+整理)

提高SOA 应用的性能取决于三个关键措施:1. 对修改数据的操作使用异步处理。

2. 对数据获取请求进行缓存。

3. 对批作业进行事务化处理。

参考文献
1. 《SOA 可以产生良好的性能吗?》 作者:
http://www.ibm.com/developerworks/cn/db2/db2mag/dbt13n2/dbt13n2_dataarch/index.html

2008年5月7日星期三

SOA_007:BPEL 如何处理异常?

任何应用都可能出错,BPEL也不例外。那么,BPEL是如何处理异常的呢?

1.
Business faults 和Runtime faults
BPEL 异常通常由异常名称name qualified with a namespace)和异常的信息类型messageType构成。和大多数应用一样,BPEL 把异常分为两种以区别对待:
  • Business faults
  • Runtime faults 或 system faults
2. Business faults Business faults 是与应用自身相关的错误,比如无法在数据库中找到社保账号。Business faults 要么由throw activity 抛出,要么由invoke activity 接收到一个错误响应。Business faults 是可预见的,事先由开发者定义好在BPEL中(messageType定义在WSDL中)。Business faults 由faultHandler捕获并处理。如<catch faultName="ns1:faultName" faultVariable="varName">
3. Runtime faults
Runtime faults 是与BPEL运行时相关的错误,由系统抛出,不可预见,比如变量无法找到、死循环错误、SOAP调用时发生SOAP fault、BPEL Server抛出的Java异常。Runtime faults 分为以下几种:

  • Standard faults
  • remoteFault
  • bindingFault
  • replayFault
除了BPEL的标准错误,其它的错误信息类型messageType都为RuntimeFaultMessage。其定义如下:
<?xml version="1.0" encoding="UTF-8" ?>
<definitions name="RuntimeFault"
targetNamespace="http://schemas.oracle.com/bpel/extension"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns="http://schemas.xmlsoap.org/wsdl/">
<message name="RuntimeFaultMessage">
<part name="code" type="xsd:string" />
<part name="summary" type="xsd:string" />
<part name="detail" type="xsd:string" />
</message>
</definitions>
3.1 Standard faults
Standard faults的特点如下:
  • 无信息类型messageTypes定义
  • 与任何WSDL message 无关
  • 捕捉时不需要指定变量名称:<catch faultName="bpws:selectionFault">
Standard faults细分为以下几种:
(1)selectionFailure
(2)conflictingReceive
(3)conflictingRequest
(4)mismatchedAssignmentFailure
(5)joinFailure
(6)forcedTermination
(7)correlationViolation
(8)uninitializedVariable
(9)repeatedCompensation
(10)invalidReply


3.2 remoteFault
remoteFault 是调用服务的阶段抛出的异常,比如 SOAP调用时抛出SOAP fault。
remoteFault 可以重试。
remoteFault 细分为以下几种错误:
(1)ConnectionRefused Remote server is unavailable
(2)WSDLReadingError Failed to read the WSDL
(3)GenericRemoteFault Generic remote fault

3.3 bindingFault
bindingFault 是在准备调用服务的阶段抛出的异常,比如 WSDL无法装载。bindingFault 不能重试。
出现
bindingFault后,必须要人工干预来修正错误。
bindingFault 细分为以下几种错误:
(1)VersionMismatch The processing party found an invalid namespace for the SOAP envelope element.
(2)MustUnderstand An immediate child element of the SOAP header element that was either not understood or not obeyed by the processing party contained a SOAP MustUnderstand attribute with a value of 1.
(3)Client.GenericError Generic error on the client side
(4)Client.WrongNumberOfInputParts Input message part number mismatch
(5)Client.WrongNumberOfOutputParts Output message part number mismatch
(6)Client.WrongTypeOfInputPart Input message part type error
(7)Client.WrongTypeOfOutputPart Output message part type error
(8)Server.GenericError Generic error on the server side
(9)Server.NoService Server is up, but there is no service
(10)Server.NoHTTPSOAPAction Request is missing the HTTP SOAP action
(11)Server.Unauthenticated Request is not authenticated
(12)Server.Unauthorized Request is not authorized
3.4 replayFault
A replayFault replays the activity inside a scope.
At any point inside a scope, this fault is migrated up to the scope.
Oracle BPEL Server then re-executes the scope from the beginning.

4. 如何返回错误给客户端?
4.1 同步调用
<reply partnerLink="Client" portType="buy:BuyBookPT" operation="BuyBook" variable="FaultDetails" faultName="fault" />

4.2 异步调用
<invoke partnerLink="Client" portType="buy:ClientCallbackPT" operation="ClientCallbackFault" inputVariable="FaultDetails" />

2008年5月6日星期二

SOA_006:何时使用ESB,何时使用BPEL?(摘录+整理)


不可否认,BPELESB 之间存在着一些功能重叠:
1. 二者都可以与适配器一起工作。
2. 二者都可以转换数据。
3. 二者都支持组合服务模式。
我们该如何来选择:BPEL or ESB。让我们首先看一看BPELESB各自的优缺点。
BPEL的优点
1. 能够编排复杂的业务流程。
2. 能够长时间运行业务流程并维持其状态。
小结:BPEL的主要作用是服务编排,需要使用专有的IDE(如 Oracle JDeveloper)进行开发。
ESB的优点
1. 能够快速处理(路由、转换、协议中介)无状态的消息。
2. 能够在转换中处理复杂事务。
小结:ESB相当于一个数据中介(mediate),目的是保证服务的位置透明性以及技术实现无关性。ESB通过配置即可管理服务,如Oracle Service Bus Web Console虽然ESB也可以做一些轻量级的服务编排,但这不是它的强项。

结论:如果需求是以流程为中心的,选择BPEL。如果需求是以数据为中心的,选择ESB

参考文献
1. 《BPEL 或 ESB:应该使用哪一个?》 作者:http://www.ibm.com/developerworks/cn/websphere/library/techarticles/0803_fasbinder2/0803_fasbinder2.html

2008年5月5日星期一

SOA_005:ESB介绍

【ESB】:Enterprise Servcie Bus 企业服务总线。
ESB是SOA应用和EDA应用的基石。
ESB的用途是在不同服务之间传递(同步、异步)数据。

1. ESB的核心特点:
(1)连接:连接各种适配器和服务。
(2)转换:在不同的协议之间转换,在不同的数据格式之间转换。// TODO
(3)路由:基于报头/报文的路由。 // TODO
(4)Virtualize Endpoints:Abstract IT resources as services 。

SOA_004:BPEL介绍

【WS-BPEL】:Web Service Business Process Execution Language
“WS-BPEL (or BPEL for short) is a language for specifying business process behavior based on Web Services.”
“业务流程执行语言是一种基于Web服务的,描述业务流程的语言。”(英文定义摘自http://en.wikipedia.org/wiki/Business_Process_Execution_Language
WS-BPEL的流行版本是1.1,由OASIS在2003年4月标准化,规范详细内容请访问:http://www.ibm.com/developerworks/library/specification/ws-bpel/
WS-BPEL的最新版本是2.0,是OASIS在2007年4月制定的,规范详细内容请访问:http://docs.oasis-open.org/wsbpel/2.0/wsbpel-v2.0.html
BPEL的基本结构如下:
<process name="ncname" targetNamespace="uri" queryLanguage="anyURI" expressionLanguage="anyURI" suppressJoinFailure="yes or no" enableInstanceCompensation="yes or no" abstractProcess="yes or no">
<partnerLinks>...</partnerLinks>
<partners>...</partners>
<variables>...</variables>
<correlationSets>...</correlationSets>
<faultHandlers>...</faultHandlers>
<compensationHandlers>...</compensationHandlers>
<eventHandlers>...</eventHandlers>
activity
</process>

1. BPEL的主要属性介绍:
(1)queryLanguage XML查询语言,缺省值:XPath 1.0。
(2)expressionLanguage XML表达式语言,缺省值:XPath 1.0。
(3)suppressJoinFailure 是否抑制流程中的所有活动的joinFailure故障。缺省值:no。
(4)enableInstanceCompensation 流程实例是否可被作为整体由特定于平台的方式来补偿。缺省值:no。
(5)abstractProcess 流程是抽象的还是可执行的。缺省值:no。

2. BPEL的主要元素介绍:
(1)partnerLinks 合作伙伴链接
<partnerLinks>
<partnerLink name="client" partnerLinkType="client:OrderBooking" myRole="OrderBookingProvider" partnerRole="OrderBookingRequester"/>
<partnerLink name="CreditRatingService" partnerRole="CreditRatingServiceProvider" partnerLinkType="ns1:CreditRatingService"/>
</partnerLinks>
完整内容请参考《用Oracle SOA Suite 10g 开发BPEL》实验2. 同步调用 OrderBooking.wsdl。

说明:
(a)描述本业务流程与不同的合作伙伴之间的“伙伴链”:即有哪些交互服务。
(b)属性 partnerLinkType 定义“伙伴链”的类型:即交互服务的接口。
(c)属性 myRole 指本业务流程所扮演的角色:请求者 or 提供者。 如果合作伙伴(外部服务)是同步服务,myRole为空。
(d)属性 partnerRole 指合作伙伴(外部服务)所扮演的角色:请求者 or 提供者。
(e)partnerLinkType 一般定义在对应的WSDL中,每个role对应一个portType:
<plnk:partnerLinkType name="OrderBooking">
<plnk:role name="OrderBookingProvider">
<plnk:portType name="client:OrderBooking"/>
</plnk:role>
<plnk:role name="OrderBookingRequester">
<plnk:portType name="client:OrderBookingCallback"/>
</plnk:role>
</plnk:partnerLinkType>
完整内容请参考《用Oracle SOA Suite 10g 开发BPEL》实验2. 同步调用 OrderBooking.wsdl。

(2)partners 合作伙伴

(3)variables 变量
<variables>
<variable name="inputVariable" messageType="client:OrderBookingRequestMessage"/>
<variable name="outputVariable" messageType="client:OrderBookingResponseMessage"/>
<variable name="invokeCR_process_InputVariable" messageType="ns1:CreditRatingServiceRequestMessage"/>
<variable name="invokeCR_process_OutputVariable" messageType="ns1:CreditRatingServiceResponseMessage"/>
</variables>
完整内容请参考《用Oracle SOA Suite 10g 开发BPEL 》实验2. 同步调用 OrderBooking.wsdl。

说明:
(a)变量类型messageType由WSDL中message定义:
<message name="OrderBookingRequestMessage">
<part name="payload" element="ns1:PurchaseOrder" />
</message>
<message name="OrderBookingResponseMessage">
<part name="payload" element="ns1:PurchaseOrder" />
</message>
完整内容请参考《用Oracle SOA Suite 10g 开发BPEL》实验2. 同步调用 OrderBooking.wsdl。

(b)与其它编程语言一样,变量也是有作用域的。

(c)使用WS-BPEL内置函数获取变量信息:
getVariableProperty(variableName, propertyName) 获取变量属性。
getVariableData(variableName,partName,locationPath) 获取变量数据。

(4)correlationSets 关联集合
业务流程有时需要与合作伙伴进行多次会话,因此有必要提供一种机制,使消息和会话被绑定到相同的流程实例,这种机制就是关联集合。
比如订票系统,客户可以查询订票状态,也可以取消订票,这就需要确保后续的请求绑定到相同流程实例。
可以用简单变量来表示,如customerID,也可以用复杂类型来表示,如(customerID,orderNumber)。
完整内容请参考《用Oracle SOA Suite 10g 开发BPEL》实验12. 使用correlationSets OrderBooking.wsdl。

(5)faultHandlers 异常处理

(6)compensationHandlers 补偿处理

(7)eventHandlers 事件处理

3. BPEL的基本活动介绍:
(1)<receive> 接收
接收消息,保持阻塞直到消息的到达。通常是流程的初始点,此时要设置createInstance="yes"。
(2)<reply> 回复
(3)<invoke> 请求
(4)<assign> 赋值
(5)<throw> 抛出异常
(6)<terminate> 终止
(7)<wait> 等待
(8)<empty> 空

4. BPEL的结构化活动介绍:
(1)<sequence> 顺序
(2)<switch> 分支
(3)<while> 循环
(4)<pick> 选取
(5)<flow> 流程
(6)<scope> 范围
(7)<compensate> 补偿

名词解释:
1. 【OASIS】:Organization for the Advancement of Structured Information Standards
结构化信息标准促进组织是一个推进电子商务标准的发展、融合与采纳的非盈利性国际化组织。
关于OASIS更多信息请访问:http://www.oasis-open.org/

2008年5月4日星期日

SOA_003:业务流程的重要性及其本质

看过《赢在中国》的人,肯定知道嘉宾经常提问创业者的一个问题:你的企业的核心竞争力是什么?不管你有没有创业的打算,都不妨以一个创业者的角度来思考类似的一个问题:“一个成功的企业应该具备哪些要素?”
我给出我认真思考后的回答:人才 + 流程 + 产品 = 成功
可以用英文概括成4个P: People + Process + Product = Perfect
你完全可以不同意我的结论,因为我既不是什么创业导师,也不是企业老总,我只是想引出我要谈论的主题:流程。没有规矩,不成方圆。这个规矩,就是流程。
你有优秀的人才,优秀的产品,这已经很不错了,但还不足以保证你的企业走向成功。中间必须还要有优秀的流程把二者关联起来。对于某些企业来说:Process和Product合二为一了。比如排名第一的商业连锁超市沃尔玛,它卖的东西没有一件自己的产品,实际上它的产品就是业务流程,它的企业的核心竞争力就是它的及其出色的采购流程、配送流程。由此可见,流程在企业中的地位是多么重要。

让我们再看一下上一篇所提到的三个问题,聪明的你一定会想到它们其实都是有关业务流程的问题。要想解决业务流程的问题,必须深刻理解业务流程的本质。
那么,业务流程的本质是什么?
有句话说得好:唯一不变的就是变化。——我认为此乃业务流程的最重要的本质!概括为灵活性似乎不太准确,但我一时没找到更合适的词汇,姑且先用这个吧。其它的如高可用性、可扩展性、可靠性、可维护性、性能等等问题固然也很重要,但这些特点几乎普适于所有系统,如果全部强调,反而失去重点。

回忆一下以往我们开发系统的过程,大致是这样的:在跟业务人员交流之后,开发人员开始进行分析需求,一般使用“文字+图形”的方式来描述流程,其间不断地与业务人员一遍遍确认需求。等一等,难道就没有一种更好的方式来描述业务流程吗?可不可以让业务人员直接参与业务流程的描述?有没有一种中立的描述业务流程的语言,让大家可以彼此无障碍交流?
答案当然是肯定的:那就是业务流程执行语言Business Process Execution Language ,缩写BPEL(发音为'bipple'或'bee-pell')。

2008年5月2日星期五

SOA_002:什么是SOA?

如今的IT业,面临着以往从来没有过的压力。
风云变化的市场、日益增长的竞争压力、锐意进取的客户需求......等等这些都给IT的灵活性和敏捷性提出了更高的要求。
今天,在全球经济一体化的背景下,每一个大公司都要时刻嗅查市场的风吹草动,先于竞争对手做出决定,快速响应竞争对手的举措;并且最大限度地挖掘企业内部的潜力,充分发挥企业资产的效能。
为了应对这些挑战,一些独具慧眼的公司开始采用 SOA 来整合和开发它们的应用。

那么,什么是SOA?它给我们带来了什么?

SOA 是Service-Oriented Architecture,面向服务的架构。
它提供了一个企业级的架构,用来“连接”企业级的应用。它把企业级的应用开发成为模块化的业务服务, 使得这些业务服务很容易地被集成和重用,从而建立了一个真正实现了灵活性和敏捷性的IT架构。
可以看出,SOA是一种围绕如何使用“服务”来完成业务活动的架构。这些“服务”是SOA的基础。
这些“服务”常用的标准协议有:SOAP、HTTP、JCA、JMS、RMI。
SOA不一定非要使用Web Services技术实现,也可以用其它技术实现:比如EAI、MOM、RMI、ORB。其实,SOA的最初思想的产生早于Web Services,那时的主流技术还是CORBA、OSF、DCE,幸好我不是那个时代,呵呵。只不过在出现了Web Services后,SOA的理念被更好地诠释了。
话说回来,如果想要实现一个安全的、跨平台的、松耦合的Internet系统,Web Services是最自然的实现方式。

2008年5月1日星期四

SOA_001:SOA是个啥东东?

这是我第一次写技术博客,我给自己立了一条规矩:那就是无废话。因为我一直认为:读废话连篇的文章等于谋财害命。
在回答什么是SOA的问题之前,请先看下面的例子:
这是一个网上订书系统,核心的业务流程是这样的:
前台:用户访问网站-->浏览图书-->选择图书-->确认订单。
订单提交后,就进入了后台的处理流程。
后台:订单信息入库-->获取用户信息-->检验客户信用卡额度-->是否需要人工审批-->选择价格最低的供书商-->下单给不同的派送公司-->email通知用户。
我们重点讨论后台系统,可以很明显地看出这是一个包含多个操作步骤和逻辑分支的业务流程,需要和不同的系统打交道。
经验丰富的人一定会想到这里有几个问题需要特别注意,因为它们是项目成败的关键:

问题1.如何实现“是否需要人工审批”?目前的需求是这样的,注意需求可能会随时根据市场变化而发生变化:
订单金额在1000元以下的,不需要人工审批。
金卡客户不需要人工审批。
订单金额在1000元以上的,非金卡的客户需要人工审批。
好像实现起来难度不是很大,几个if else判断就能解决,但是一个月后,为了加快订单处理流程,公司决定放宽要求:
订单金额在2000元以下的,不需要人工审批。
金卡客户不需要人工审批。
订单金额在2000元以上的,非金卡的客户需要人工审批。
三个月以后,为了降低大额交易风险,公司决定修改审批规则如下:
订单金额在2000元以下的,不需要人工审批。
订单金额在2000元以上、10000元以下的,非金卡的客户需要人工审批。
订单金额在2000元以上、10000元以下的,持金卡的客户不需要人工审批。
订单金额在10000元以上的,一律需要人工审批。
.....
还可以有很多变化,不再一一列举,诸位应该明白我的意思了。难道审批规则的每变化一次,都要重新修改,编译、测试、发布?——客户肯定无法接受这个方案。

问题2.如何实现“选择价格最低的供书商”?为了简化问题,我们假设每家供书商都提供查询书价的接口,需求如下:
显然这里有多个供书商可以供你选择,客户的要求是同时向这些供书商发出价格查询,在一定的时间内返回最低价格的供书商获得订单。这里的关键是实现并行查询操作,当然你可以用Thread相关技术来做,至于做的好不好那就很难保证了,你要考虑很多意外情况,某个供书商一直没有返回值怎么办?出现异常怎么办?超过规定时间怎么办?还有,Java多线程编程搞不好就容易发生死锁。

问题3.如何实现“下单给不同的派送公司”?目前的需求是这样的:
四环以内的本来由甲公司负责,四环外的由乙公司负责。
后来由于有些用户抱怨送书时间过长,公司决定与DHL结成战略伙伴关系,规定金卡用户和订单金额在1000元以上的,一律由DHL派送。这里问题的关键是由于派送公司竞争非常激烈,经常会更替不同的派送公司。可以想象,如果跟一个派送公司解除合作关系后,相应的代码改动简直就是一场灾难。
面对以上三个问题,你是否有很好的解决方案,不妨说来听听。
说了半天,还是没说SOA是个啥?别急,今天写累了,留待下回吧。就技术而言,先知道它能干啥,比知道它是啥更重要。等你知道它能干啥后,再反过来看它是啥,印象更深刻。这是我的学习体会,欢迎拍砖。