BusinessProcessExecutionLanguageforWebServices资源-CSDN文库

4星 · 超过85%的资源需积分: 19 146 浏览量 2008-04-09 19:10:39 上传评论收藏 652KB PDF 举报

### Business Process Execution Language for Web Services (BPEL) #### 概述《Business Process Execution Language for Web Services》（Web服务业务流程执行语言）是用于定义业务流程的一种规范，旨在为Web服务提供一种标准化的方式来表达业务流程和服务之间的交互逻辑。该文档版本为1.0，发布于2002年7月31日。该规范由多家知名公司共同制定，包括IBM、BEA Systems以及Microsoft等，其作者包括Francisco Curbera、Yaron Goland、Johannes Klein、Frank Leymann、Dieter Roller和Sanjiva Weerawarana，编辑为Satish Thatte。 #### 核心概念与技术要点 ##### 1. BPEL的作用 BPEL是一种基于XML的语言，用于描述业务流程中的活动、条件以及这些元素之间的关系。它主要用于协调多个Web服务之间的交互，使得这些服务能够协同工作以完成更复杂的任务或业务流程。 ##### 2. BPEL的关键特性 - **标准化**: BPEL是基于W3C XML Schema标准，确保了其在不同系统间的互操作性。 - **可扩展性**: 支持通过扩展点来添加新的功能，使得开发者可以根据具体需求对其进行扩展。 - **事务管理**: 支持补偿逻辑和错误处理机制，增强了流程的鲁棒性和可靠性。 - **异步通信**: BPEL支持异步消息传递，这有助于提高系统的响应速度和吞吐量。 ##### 3. BPEL的基本元素 - **Process**: 定义了一个完整的业务流程，包括所有参与的Web服务和消息交换模式。 - **Activity**: 是构成流程的基本单元，可以是简单的操作，也可以是复杂的子流程。 - **Message Exchange**: 描述了两个服务之间如何交换数据。 - **Partner Links**: 定义了与其他服务的连接方式，包括消息类型、地址等信息。 - **Fault Handling**: 用于处理异常情况，如失败的消息交换等。 ##### 4. BPEL的工作原理 BPEL允许开发者定义一系列的活动，并指定这些活动之间的顺序、并行性以及条件分支等。这些活动可以通过消息传递进行同步或异步交互。此外，BPEL还支持事务处理机制，以确保数据的一致性和完整性。 ##### 5. 实例应用场景 - **供应链管理**: 通过BPEL编排不同的物流、库存管理等服务，实现自动化且高效的供应链管理。 - **金融服务**: 在银行转账、贷款审批等场景下，BPEL可以协调多个内部服务，以确保交易的安全性和效率。 - **电子商务**: 在复杂的订单处理过程中，BPEL可以帮助整合支付、库存检查等多个环节的服务。 #### 技术限制与注意事项 - **知识产权声明**: 该文档明确指出，提供的内容并不授予任何对BEA、IBM、Microsoft或其他第三方拥有的专利、商标、版权等知识产权的许可。 - **示例的虚构性质**: 文档中提到的所有公司、组织、产品等均为虚构的，不涉及任何现实中的实体。 - **免责条款**: BEA、IBM和Microsoft对该文档及其包含的信息不作任何明示或暗示的保证，包括但不限于适销性、特定用途的适用性等。 #### 结论 Business Process Execution Language for Web Services (BPEL)作为一种强大的工具，为构建复杂、可扩展且可靠的企业级应用提供了基础。通过对业务流程的标准化描述，BPEL不仅提高了不同Web服务之间的交互效率，还简化了流程管理和维护的复杂度。随着技术的发展，虽然有其他更先进的技术和框架出现，但BPEL仍然在许多领域内发挥着重要作用。

资源推荐

资源详情

资源评论

Advanced search

IBM home | Products & services | Support & downloads | My account

IBM developerWorks : Web services : Web services articles

Business Process Execution Language for Web Services, Version

1.0

31 July 2002

This version:

http://www.ibm.com/developerworks/library/ws-bpel/ (available in PDF)

Authors:

Francisco Curbera, IBM <curbera@us.ibm.com>

Yaron Goland, BEA Systems <ygoland@bea.com>

Johannes Klein, Microsoft <joklein@microsoft.com>

Frank Leymann, IBM <LEY1@de.ibm.com>

Dieter Roller, IBM <ROL@de.ibm.com>

Sanjiva Weerawarana, IBM <sanjiva@us.ibm.com>

Editor:

Satish Thatte, Microsoft <satisht@microsoft.com>

The presentation, distribution, or other dissemination of the information contained in this specification is not a license, either expressly or

impliedly, to any intellectual property owned or controlled by BEA or IBM or Microsoft and/or any other third party. BEA, IBM, Microsoft,

and/or any other third party may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering

subject matter in this document. The furnishing of this document does not give you any license to BEA's or IBM's or Microsoft's or any other

third party's patents, trademarks, copyrights, or other intellectual property. The example companies, organizations, products, domain names,

e-mail addresses, logos, people, places, and events depicted herein are fictitious. No association with any real company, organization,

product, domain name, e-mail address, logo, person, place, or event is intended or should be inferred. This specification and the information

contained herein is provided on an "AS IS" basis and to the maximum extent permitted by applicable law, BEA, IBM and Microsoft provides

the document AS IS AND WITH ALL FAULTS, and hereby disclaim all other warranties and conditions, either express, implied, or statutory,

including, but not limited to, any (if any) implied warranties, duties, or conditions of merchantability, of fitness for a particular purpose, of

accuracy or completeness of responses, of results, of workmanlike effort, of lack of viruses, and of lack of negligence, all with regard to the

document. ALSO, THERE IS NO WARRANTY OR CONDITION OF TITLE, QUIET ENJOYMENT, QUIET POSSESSION,

CORRESPONDENCE TO DESCRIPTION OR NON-INFRINGEMENT OF ANY INTELLECTUAL PROPERTY RIGHTS WITH REGARD TO

THE DOCUMENT. IN NO EVENT WILL BEA or IBM OR MICROSOFT BE LIABLE TO ANY OTHER PARTY FOR THE COST OF

PROCURING SUBSTITUTE GOODS OR SERVICES, LOST PROFITS, LOSS OF USE, LOSS OF DATA, OR ANY INCIDENTAL,

CONSEQUENTIAL, DIRECT, INDIRECT, OR SPECIAL DAMAGES WHETHER UNDER CONTRACT, TORT, WARRANTY, OR

OTHERWISE, ARISING IN ANY WAY OUT OF THIS OR ANY OTHER AGREEMENT RELATING TO THIS DOCUMENT, WHETHER OR

NOT SUCH PARTY HAD ADVANCE NOTICE OF THE POSSIBILITY OF SUCH DAMAGES.

Abstract

This document defines a notation for specifying business process behavior based on Web Services. This notation is

called Business Process Execution Language for Web Services (abbreviated to BPEL4WS in the rest of this document).

Processes in BPEL4WS export and import functionality by using Web Service interfaces exclusively.

Business processes can be described in two ways. Executable business processes model actual behavior of a

participant in a business interaction. Business protocols, in contrast, use process descriptions that specify the mutually

visible message exchange behavior of each of the parties involved in the protocol, without revealing their internal

behavior. The process descriptions for business protocols are called abstract processes. BPEL4WS is meant to be used

to model the behavior of both executable and abstract processes.

All of dW

BPEL4WS provides a language for the formal specification of business processes and business interaction protocols.

By doing so, it extends the Web services interaction model and enables it to support business transactions. BPEL4WS

defines an interoperable integration model that should facilitate the expansion of automated process integration in both

the intracorporate and the business-to-business spaces.

Status of this Document

This is an initial public draft release of the BPEL4WS specification. We anticipate a number of extensions to the feature

set of BPEL4WS that are discussed briefly at the end of the document. BPEL4WS represents a convergence of the

ideas in the XLANG and WSFL specifications. Both XLANG and WSFL are superseded by the BPEL4WS specification.

BPEL4WS and related specifications are provided as-is and for review and evaluation only. BEA, IBM and Microsoft

hope to solicit your contributions and suggestions in the near future. BEA, IBM and Microsoft make no warrantees or

representations regarding the specifications in any manner whatsoever.

Table of Contents

1. Introduction

2. Notational Conventions

3. Relationship with WSDL

4. Defining a Business Process

4.1. Initial Example

4.2. The structure of a business process

4.3. Language Extensibility

4.4. The Lifecycle of a Business Process

5. Service Linking, Partners, and Service References

5.1. Service Linking

5.2. Partners

5.3. Service References

6. Message Properties

6.1. Motivation

6.2. Defining Properties

7. Correlation

7.1. Message Correlation

7.2. Defining and Using Correlation Sets

8. Data Handling

8.1. Expressions

8.1.1. Boolean Expressions

8.1.2. Deadline-Valued Expressions

8.1.3. Duration-Valued Expressions

8.1.4. General Expressions

8.2. Containers

8.3. Assignment

8.3.1. Atomicity of Assignment

8.3.2. Assignment Example

8.4. Summary of Differences Between Abstract and Executable Processes

9. Basic Activities

9.1. Standard Attributes for Each Activity

9.2. Standard Elements for Each Activity

9.3. Invoking Web Service Operations

9.4. Providing Web Service Operations

9.5. Updating Container Contents

9.6. Signaling Faults

9.7. Terminating the Service Instance

9.8. Waiting

17.4.2. Service Link Type Schema

17.4.3. Service References Schema

17.4.4. Message Properties Schema

1. Introduction

The goal of the Web Services effort is to achieve universal interoperability between applications by using Web

standards. Web Services use a loosely coupled integration model to allow flexible integration of heterogeneous systems

in a variety of domains including business-to-consumer, business-to-business and enterprise application integration.

The following basic specifications originally defined the Web Services space: SOAP, Web Services Description

Language (WSDL), and Universal Description, Discovery, and Integration (UDDI). SOAP defines an XML messaging

protocol for basic service interoperability. WSDL introduces a common grammar for describing services. UDDI provides

the infrastructure required to publish and discover services in a systematic way. Together, these specifications allow

applications to find each other and interact following a loosely coupled, platform-independent model.

Systems integration requires more than the ability to conduct simple interactions by using standard protocols. The full

potential of Web Services as an integration platform will be achieved only when applications and business processes

are able to integrate their complex interactions by using a standard process integration model. The interaction model

that is directly supported by WSDL is essentially a stateless model of synchronous or uncorrelated asynchronous

interactions. Models for business interactions typically assume sequences of peer-to-peer message exchanges, both

synchronous and asynchronous, within stateful, long-running interactions involving two or more parties. To define such

business interactions, a formal description of the message exchange protocols used by business processes in their

interactions is needed. The definition of such business protocols involves precisely specifying the mutually visible

message exchange behavior of each of the parties involved in the protocol, without revealing their internal

implementation. There are two good reasons to separate the public aspects of business process behavior from internal

or private aspects. One is that businesses obviously do not want to reveal all their internal decision making and data

management to their business partners. The other is that, even where this is not the case, separating public from private

process provides the freedom to change private aspects of the process implementation without affecting the public

business protocol.

Business protocols must clearly be described in a platform-independent manner and must capture all behavioral aspects

that have cross-enterprise business significance. Each participant can then understand and plan for conformance to the

business protocol without engaging in the process of human agreement that adds so much to the difficulty of

establishing cross-enterprise automated business processes today.

What are the concepts required to describe business protocols? And what is the relationship of these concepts to those

required to describe executable processes? To answer these questions, consider the following:

● Business protocols invariably include data-dependent behavior. For example, a supply-chain protocol depends on

data such as the number of line items in an order, the total value of an order, or a deliver-by deadline. Defining

business intent in these cases requires the use of conditional and time-out constructs.

● The ability to specify exceptional conditions and their consequences, including recovery sequences, is at least as

important for business protocols as the ability to define the behavior in the "all goes well" case.

● Long-running interactions include multiple, often nested units of work, each with its own data requirements.

Business protocols frequently require cross-partner coordination of the outcome (success or failure) of units of

work at various levels of granularity.

If we wish to provide precise predictable descriptions of service behavior for cross-enterprise business protocols, we

need a rich process description notation with many features reminiscent of an executable language. The key distinction

between public message exchange protocols and executable internal processes is that internal processes handle data

in rich private ways that need not be described in public protocols.

In thinking about the data handling aspects of business protocols it is instructive to consider the analogy with network

communication protocols. Network protocols define the shape and content of the protocol envelopes that flow on the

wire, and the protocol behavior they describe is driven solely by the data in these envelopes. In other words, there is a

clear physical separation between protocol-relevant data and "payload" data. The separation is far less clear cut in

business protocols because the protocol-relevant data tends to be embedded in other application data.

BPEL4WS uses a notion of message properties to identify protocol-relevant data embedded in messages. Properties

can be viewed as "transparent" data relevant to public aspects as opposed to the "opaque" data that internal/private

functions use. Transparent data affects the public business protocol in a direct way, whereas opaque data is significant

primarily to back-end systems and affects the business protocol only by creating nondeterminism because the way it

affects decisions is opaque. We take it as a principle that any data that is used to affect the behavior of a business

protocol must be transparent and hence viewed as a property.

The implicit effect of opaque data manifests itself through nondeterminism in the behavior of services involved in

business protocols. Consider the example of a purchasing protocol. The seller has a service that receives a purchase

order and responds with either acceptance or rejection based on a number of criteria, including availability of the goods

and the credit of the buyer. Obviously, the decision processes are opaque, but the fact of the decision must be reflected

as behavior alternatives in the external business protocol. In other words, the protocol requires something like a switch

activity in the behavior of the seller's service but the selection of the branch taken is nondeterministic. Such

nondeterminism can be modeled by allowing the assignment of a nondeterministic or opaque value to a message

property, typically from an enumerated set of possibilities. The property can then be used in defining conditional

behavior that captures behavioral alternatives without revealing actual decision processes. BPEL4WS explicitly allows

the use of nondeterministic data values to make it possible to capture the essence of public behavior while hiding private

aspects.

Defining business protocols and defining executable business processes require very similar concepts. The concepts

required for defining business protocols and those required for defining executable business processes form a

continuum, and BPEL4WS is designed to cover this continuum. BPEL4WS defines a model and a grammar for

describing the behavior of a business process based on interactions between the process and its partners. The

interaction with each partner occurs through Web Service interfaces, and the structure of the relationship at the interface

level is encapsulated in what we call a service link. The BPEL4WS process defines how multiple service interactions

with these partners are coordinated to achieve a business goal, as well as the state and the logic necessary for this

coordination. BPEL4WS also introduces systematic mechanisms for dealing with business exceptions and processing

faults. Finally, BPEL4WS introduces a mechanism to define how individual or composite activities within a process are

to be compensated in cases where exceptions occur or a partner requests reversal.

The basic concepts of BPEL4WS can be applied in one of two ways. A BPEL4WS process can define a business

protocol role, using the notion of abstract process. For example, in a supply-chain protocol, the buyer and the seller are

two distinct roles, each with its own abstract process. Their relationship is typically modeled as a service link. Abstract

processes use all the concepts of BPEL4WS but approach data handling in a way that reflects the level of abstraction

required to describe public aspects of the business protocol. Specifically, abstract processes handle only protocol-

relevant data. BPEL4WS provides a way to identify protocol-relevant data as message properties. In addition, abstract

processes use nondeterministic data values to hide private aspects of behavior.

It is also possible to use BPEL4WS to define an executable business process. The logic and state of the process

determine the nature and sequence of the Web Service interactions conducted at each business partner, and thus the

interaction protocols. While a BPEL4WS process definition is not required to be complete from a private implementation

point of view, the language effectively defines a portable execution format for business processes that rely exclusively

on Web Service resources and XML data. Moreover, such processes execute and interact with their partners in a

consistent way regardless of the supporting platform or programming model used by the implementation of the hosting

environment.

Even where private implementation aspects use platform-dependent functionality, which is likely in many if not most

realistic cases, the continuity of the basic conceptual model between abstract and executable processes in BPEL4WS

makes it possible to export and import the public aspects embodied in business protocols as process or role templates

while maintaining the intent and structure of the protocols. This is arguably the most attractive prospect for the use of

BPEL4WS from the viewpoint of unlocking the potential of Web Services because it allows the development of tools and

other technologies that greatly increase the level of automation and thereby lower the cost in establishing cross-

enterprise automated business processes.

BPEL4WS is layered on top of several XML specifications: WSDL 1.1, XML Schema 1.0, and XPath1.0. WSDL

messages and XML Schema type definitions provide the data model used by BPEL4WS processes. XPath provides

support for data manipulation. All external resources and partners are represented as WSDL services. BPEL4WS

provides extensibility to accommodate future versions of these standards, specifically the XPath and related standards

used in XML computation.

剩余95页未读，继续阅读

评论收藏

内容反馈

卯时喝凉水

2013-02-25

还好啦。如果是免费的就好了
rageyu

2015-11-12

还行，比较基础

xmh517

粉丝: 286
资源: 13

Business Process Execution Language for Web Services

Business Process Execution Language for Web Services 2nd Edition

Web Services Description Language

Web Services Execution Environment-开源

Preview of Web Services Reliable Messaging in SAP Netweaver Process Integration 7.1.pdf

S-BPM说明：关于业务流程建模和执行的故事书S-BPM Illustrated: A Storybook about Business Process Modeling and Execution

BPEL教程（business process execution language for web service第二版英文）

web service business process execution language

BPEL_for-web-services-bpel-and-bpel4ws-2nd

BPEL.rar_BPEL_BPEL4ws_execution_web服务

BPEL与XPDL的定位区别

Web Services Description Language (WSDL) Version 2.0

Web Service 官方文档 Web Services Federation Language(WS-Federation)

OWL Web Ontology Language for Services

《The New Language of Business SOA and Web 2.0》02

《The New Language of Business SOA and Web 2.0》01

A Role-Based Approach To Business Process Management

基于web+service的学校OA系统的设计与实现.pdf

我收集的XPDL

WSC/ADL:Web Services组合系统体系结构描述语言

网路服务(Web.ppt

基于分类cache的web服务组合模板检索算法.pdf

bpel规范[参照].pdf

论文研究-Web服务动态组合的研究.pdf

BPEL 2.0 规范 中文版

电子政务自适应信息服务平台结构研究.docx

业务流程建模语言BPEL

最新资源

BPEL 2.0 规范中文版