WS BPEL Use Case Catalogue - OASIS



WS BPEL Use Case Catalogue

Table of contents

1. About 2

2. Business Context 3

Standards 3

Business Flows 3

EAI 3

B2B 3

Entities – add table 3

Services – add table (table with pointers to associated entities in the previous section) 3

3. Technical Context – tables – WSDL points back to the services, WSDL should point to the messages schemas also 3

WSDL 3

Schemas 4

4. Assumptions 4

Design 4

Deployment 4

Operating Environment 4

5. BPEL Use Cases 6

List 6

UC100 6

6. Appendix 10

Template 10

7. HISTORY 11

About

Business Context

Standards

[Describe how higher level standards work relates to these business flows and use cases]

Business Flows

EAI

• Simple integration – SFA and CRM

[Activity diagram forthcoming…]

B2B

• Business Collaboration - The primary concept within the Business Collaboration Framework (BCF) that enables modularity of business transactions. Business collaborations define business entities or objects and their lifecycles and states within the context of the business collaboration. Business collaborations also define business constraints or rules according to the context of the business collaboration.

• Others TBD

Entities – add table

Company A

Sales Department

Customer Support Department

Company B

Services – add table (table with pointers to associated entities in the previous section)

[Services exposed by Entities]

Company A / Customer Support Department exposes:

Service: CustomerInfo

Method: EditCustomerProfile

Method: GetCustomerProfile

Method: RemoveCustomerProfile

Company A / Sales Department exposes:

Service: Notify

Method: DeliverRequestedInformation

Method: ChangeEvent

Technical Context – tables – WSDL points back to the services, WSDL should point to the messages schemas also

WSDL

See files…

Schemas

See files…

Assumptions

Design

There are many assumptions about the design environment, which are applicable to most BPEL use cases. If a particular use case is assuming something different, then it will be noted directly in the use case itself:

1. Message types are defined.

2. Port Types are defined based on the above Message types.

3. Partner Link types and the roles are defined.

4. A BPEL process name and attributes are selected.

5. Variables and scopes for storing WSDL message types are defined.

6. Correlation sets for WSDL message types is defined.

7. Exceptions are defined through fault handlers.

8. Activities describing the sequence of message exchanges are defined.

9. Within the above, parallel execution (flows) is defined.

10. Compensation handlers are defined.

Deployment

There are many assumptions about the deployment of BPEL, which are applicable to most BPEL use cases. If a particular use case is assuming something different, then it will be noted directly in the use case itself:

1. BPEL documents are separate

2. BPEL documents plus documents specifying platform specific deployment descriptors are deployed in an execution environment

3. The deployment mechanism facilitates the connectivity of the various components that make up execution environment

Operating Environment

There are many assumptions about the operating environment, which are applicable to most BPEL use cases. If a particular use case is assuming something different, then it will be noted directly in the use case itself:

1. There is a BPEL execution environment

2. The BPEL execution environment consists of a BPEL execution engine + platform (such as a WSDL framework, SOAP engine, HTTP service and other optional services running on top of a platform specific computing environment)

3. Services exposed as a WSDL service

4. The physical ports for the communication end points are configured and are operational through LAN.

5. At each end point, there is facility for processing and generating SOAP messages.

6. There is a facility for HTTP Communication protocol between the end points.

7. There is no central registry to facilitate discovery.

BPEL Use Cases

List

UC100

|Use case ID |UC 100 |

|Use case name |Multi- party message transformation in application integration (AI) |

|Description |A Sales Force Automation application (SFA) needs to interact with a Customer Relation |

| |Management (CRM) application as part of a business operation of an enterprise. |

| | |

| | |

| | |

| | |

| | |

| | |

| | |

| | |

| | |

| | |

| | |

| | |

| | |

| | |

| | |

|Original Submitter |Sid Askary |

|Champion |Sid Askary |

|Status |New |

|Related Assumptions |* |

|Related Issues |* |

|TC Disposition |* |

|Non-functional requirements and |* |

|assumptions | |

|Related business flow |* |

|Typical preceding flow |

| |

|Run time consists of the interaction between the process instance, the underlying platform that provides the WS binding and the |

|communication channels on endpoint 1,2,3 & 4. The BPEL engine is required to have visibility ONLY into the execution of the |

|constructs defined in WSDL 1.1. documents deployed in the BPEL+PF. Additionally, the mechanism for evaluation of BPEL expressions |

|is XPATH 1.0. The following events take place for a Read Operation of the CRUD described in the design section above: |

| |

| |

| |

| |

| |

| |

| |

| |

| |

| |

| |

| |

| |

| |

| |

| |

| |

| |

| |

| |

| |

| |

| |

| |

| |

| |

| |

| |

| |

| |

|The App1-SFA sends a synchronous soap/HTTP request to the BPEL+PF. |

|This request is received by the BPEL+PF. |

|BPEL+PF consumes the message (with blocking for synchrony) and attempts to decipher the correlation key (using the correlation set |

|and message property aliases). If the correlation is successful [Issue 66], computation precedes, otherwise the BPEL+PF faults. |

|If a process instance does not exist, it creates an instance of the BP. Otherwise, the message is sent to the appropriate BP |

|instance. |

|The BP instance then forwards the transformation operation to the BPEL+PF. |

|The BPEL+PF performs the transformation and validates the correlation (using the message property aliases). |

|The BPEL+PF forwards the request (with blocking for synchrony) via soap/HTTP to App2-CRM application. |

|The App2-CRM sends a synchronous reply via soap/HTTP to the BPEL+PF. |

|BPEL+PF consumes the message (with blocking for synchrony) and attempts to decipher the correlation key (using the correlation set |

|and message property aliases). If the correlation is successful [Issue 66], computation precedes, otherwise the BPEL+PF faults. |

|The BPEL+PF sends the message to the appropriate BP instance. |

|The BP instance then forwards the transformation operation to the BPEL+PF. |

|The BPEL+PF performs the transformation and validates the correlation (using the message property aliases). |

|The BPEL+PF forwards the request (with blocking for synchrony) via soap/HTTP to App1-SFA application |

| |

|Note that for Create, Update and Delete Operations compensation handlers may, additionally, be defined. |

|Typical following flow |* |

|Begins When |* |

|Actors |* |

|Preconditions |* |

| | |

| | |

| | |

| | |

| | |

| | |

| | |

| | |

| | |

| | |

| | |

| | |

| | |

| | |

| | |

| | |

| | |

|Ends when |* |

|Success Postconditions |* |

|Alt-Postcondition-1 |* |

|Alt-Postcondition-2 |* |

|Activity Diagram no standard) | |

| | |

| | |

| | |

| | |

| | |

| | |

| | |

| | |

|Abstract BPEL |See file… |

| | |

|Executable BPEL |See file… |

| | |

UC200

|Use case ID |UC 200 |

|Use case name |Simpl-eb |

|Description |Note: Most of this information came from Uniform Code Council’s Simpl-EB Implementation Guide and is copyright 2003|

| |EAN International and the Uniform Code Council, Inc. |

| | |

| |Simpl-eb is a business led approach to business communication focused on simplifying the underlying communication |

| |of the trading process. It is the smallest electronic component of the business messaging architecture. Simpl-eb |

| |enables users to trade information more efficiently by eliminating unnecessary information in the exchange of |

| |business messages. Simpl-eb is based upon the core commercial business processes used in the trade of products and |

| |services, which enable application to any industry. The data used for Simpl-eb assumes item synchronization or |

| |alignment occurs prior to the commercial collaborative business processes. It is maintained as changes to data take|

| |place in accordance with industry guidelines and rules. Simpl-eb utilizes a Global Data Dictionary to use a common |

| |definition of industry standard attributes provided in a globally-accepted set of common terms. |

| |Simpl-eb is a sequence of messages that can be expanded to account for additional scenarios for various contexts |

| |(e.g., industries, geographic regions, business practises). The seller identifies party data and sends the party |

| |message to the buyer or third party to map the party data and integrate it to complete the initial align data |

| |activities. Alignment of item information follows, permitting subsequent activities such as the purchase order, |

| |despatch advice, and request for payment (invoice). |

| |The sequence of messages for Simpl-eb relies on a set of standard components. EAN.UCC System standards furnish |

| |these components, which, when assembled together, make up messages. Most of these components are, to one degree or |

| |another, reusable and can be assembled in various ways to support specific processes. |

| |This process dictates the overall choreography for Simpl-eb. It uses business processes from every process area to |

| |enforce the principles of Simpl-eb. Performing Simpl-eb imposes the following sequence of business process: |

| |Send Party |

| |Send Item |

| |Place New Order |

| |Provide Despatch Advice |

| |Request Payment |

| |The successful completion of these business processes realizes a Simpl-eb trade process between a buyer and seller.|

| | |

| |The figure below illustrates the sequence of business processes and message flows used by Simpl-eb. |

| | |

| |[pic] |

| | |

|Original Submitters |John Evdemon – based upon work submitted by Rajesh Manglani (UCC). |

|Champion |John Evdemon |

|Status |Draft |

|Related Assumptions |The BPSS implementation of Simpl-eb is derived from the Unified Modeling Methodology (UMM) worksheets (V20030922) |

| |created for the Simpl-eb business process models. These worksheets are included below. |

|Related Issues |This scenario is not designed to target any specific aspect of the BPEL4WS specification. The purpose of this |

| |scenario is to ensure and illustrate BPEL’s compatibility with simple e-business standards. |

|TC Disposition |Under review until 11/11. Please forward comments and concerns to the BPEL Use Case mailing list |

| |(wsbpel-uc@lists.oasis-). If you are not a member of the BPEL Use Case subgroup, please forward your |

| |comments to John Evdemon (jevdemon@). |

|Non-functional |This scenario utilizes standardized XML schemas from EAN.UCC. The schemas listed in the table below are |

|requirements and |downloadable from the EAN.UCC System XML standards suite. Additional schemas (from BPEL4WS and WSDL) will also be |

|assumptions |utilized. These schemas are available from the WSBPEL CVS Use Case/Simpl-eb module. |

|Related business flow |B2B, Business Collaboration |

|Typical preceding flow |Data alignment (Party, Item). See activity diagrams. |

|Typical following flow |N/A |

|Begins When |Buyer and Seller agree to utilize Simpl-EB |

|Actors |Buyer, Seller |

|Preconditions |Buyer and Seller successfully complete the Data Alignment process. |

|Ends when |Successful completion of Request Payment |

|Success Postconditions |N/A |

|Alt-Postcondition-1 |N/A |

|Alt-Postcondition-2 |N/A |

|Activity Diagram no |Send Party (Data Alignment) |

|standard) |[pic] |

| | |

| |Send Item (Data Alignment)) |

| |[pic] |

| | |

| |Place New Order |

| |[pic] |

| |Provide Despatch Advice |

| |[pic] |

| |Request Payment |

| |[pic] |

|Abstract BPEL |See file… |

| | |

|Executable BPEL |See file… |

|References |BCF Worksheets (TBD) |

Appendix

Template

|Use case ID |Example: A-001 (‘A’ for ‘abstract’) |

|Use case name |Named by Use Case subgroup for consistency |

|Description |At a minimum, business requirements |

|Original Submitter |Obvious |

|Champion |Person who facilitates the process of bringing the use case to the attention of the Committee |

|Status |New, |

| |open, |

| |deferred, |

| |complete |

|Related Issues |Identify the issue or aspect of the spec, use case scenario is intended to demonstrate. If this|

| |use case generates an official BPEL issue, provide cross ref. |

|TC Disposition |Accept |

| |Reject (note why) |

| |Hold, future consideration |

| |Need for a specific resource to further evaluate |

|Non-functional requirements and |List all relevant strengths, weaknesses, opportunities, threats from any participants point of |

|assumptions |view. Also technical requirements, and how frequent? Performance goal., traceability goal |

|Related business flow |Business flow ID that this BPEL will in part, serve to implement |

|Typical preceding flow |Business flow ID from business context above, that usually precedes it, and that it is |

| |correlated to. |

|Typical following flow |Business flow ID from business context above, that usually follows it, and that it is |

| |correlated to. |

|Begins When |Identifies the message(s) that can instantiate this business process |

|Actors |Actor ID from business context above |

|Preconditions |Boolean expressions defining the conditions that must be true for the business process to |

| |continue to run after instantiation |

|Ends when | |

|Success Postconditions |Boolean expressions defining the conditions that must be true when the business process |

| |terminates in the success path |

|Alt-Postcondition-1 |Boolean expressions defining the conditions that must be true when the business process |

| |terminates in the n=1 alt path |

|Alt-Postcondition-2 |Boolean expressions defining the conditions that must be true when the business process |

| |terminates in the n=2 alt path |

|Activity Diagram (no standard) |[pic] |

|Abstract BPEL | |

| |… |

| | |

|Executable BPEL | |

| |… |

| | |

HISTORY

1. (9/2703 – Sid): Added a step in design time for defining message properties.

2. (9/2703 – Sid): Added 2 additional correlation steps (one each for input and output) to the message flow diagram and to the execution steps.

3. (11/4/03 – John) Added the remaining activity diagrams and descriptions for Simpl-EB

-----------------------

Fig. 1 message exchanges

BPEL+PF

APP2-CRM

BP Instance

BPEL+PF

APP 1- SFA

Correlate

Fig. 2 Normal message exchanges

Request

Receive Data

Correlate

Find/Create

Instance

Transform

Correlate

Find/Create

Instance

Transform

Send Data

Reply

Correlate

3

2

4

App 2

CRM

App 1

SFA

BPEL

ENGINE

1

................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download