6.pptx

The Choreography of a Business Collaboration describes the ordering and transitions
between Business Transactions or sub collaborations within a Business Collaboration.
Or,
A Choreography is an ordering of Business Activities within a Business Collaboration
Example
 UML tool this could be represented with a UML activity diagram.
 Choreography can be specified visually with notations such as the BPMN.
 Choreography can be specified in ebBP schema using activity diagram.
 activity diagram: start state, completion state, activities, Forks, Joins, decisions,
transitions between activities, and guards on the transitions.
Definitions

Key Semantics of a Choreography
Purpose of a Choreography:
is to specify which BTA, Complex Business Transaction Activity and/or
Collaboration Activity should (are expected to) happen.
The specification of choreography definition and the Business Transaction protocol
defines unambiguously which business message (Document Envelope or Business
Signal) is expected by any of the parties.

The choreography is specified in terms of Business States, and transitions between those
Business States.
 When a transition is validated, it does not mean that the target Business Activity
would start immediately. Instead, it means that the Business Activity is “enabled” and
the initiating party MAY now send the request whenever appropriate,
 provided that, it remains within the TimeToPerform of the Binary (Business)
Collaboration.
 It is merely the execution of the backend systems, which instruct the BSI to send or
receive messages that advance the state of a collaboration.
 There is no execution engine associated to the collaboration itself.

 The Business Collaboration is either in the state of performing a given Business
Activity (or multiple concurrent Business Activities) or waiting to start a Business
Activity, unless it has reached a completion state.
 Once a Business Activity completes a transition from this Business Activity, it
navigates to another Business Activity.
 A business message initiates a Business Collaboration or advances its state.

 There are a number of auxiliary types of States that facilitate the
choreographing of Business Activities.
 These include a Start state, a Completion state (which comes in a Success
and Failure flavor) as well as a series of gateways:
• a Fork gateway, a Join gateway and a Decision gateway.
 There are two types of Fork gateway: OR and XOR

XOR Fork
 An XOR Fork means that only one Business State of the Fork will be
allowed to be reached, although all transitions to Business States are
possible at the start.
 Once one of the outgoing transitions attached to the Fork gateway get
activated, all the other transitions becomes invalid (e.g. a BTA starts).

OR Fork
 An OR value mean that one or more Business Activity pointed to by a transition
coming from the Fork might be initiated.
 Several paths are possible although when and which become active is unknown.
 These Business Activities MAY occur in parallel.
 Note that it is not important to specify the order in which Condition Expression on a
transition coming from a Fork will be evaluated.
 It is merely the order in which the request of the Business Transaction Activities
arrive that determines the order in which the Condition Expression need to be
evaluated.

Decision
 A Decision differs from a Fork in the sense that a Decision selects only one of the
possible transitions, and the other(s) is/are automatically disabled.
 An XOR Fork may be designed to operate like a Decision, but a Decision cannot
be an XOR Fork.

 A Fork has a TimeToPerform element, where the duration MAY be specified.
 At the end of this time interval, the state of the Binary (Business)
Collaboration will automatically be moved to its corresponding Join.
 This feature MAY be used in cases where the Business Activities are
optional.
 (e.g. Cancel Purchase Order and Change Purchase Order BTA) could
be defined as part of a Fork/Join control block.

 If any given BTA within the Fork/Join pair has not reached its
completion state, the BSI will generate a corresponding timeout
exception.
 The TimeToPerform duration of a Fork MUST be greater than (or
equal to) any TimeToPerform duration of its Business Activities.

Via the AND-Join (by default, the Join is an AND-Join), the
waitForAll attribute (waitForAll='true’) of the Join MUST indicate
that all transitions coming into the Join MUST be executed for
the collaboration to reach the Join state that reflects the state
movement.

 When the waitForAll parameter is set to false, it is an OR-Join.
 If one or more Business Activities complete, the OR-Join
(waitForAll='false') completes.
 For an OR-Join (where waitForAll='false'), the BSI will generate a
timeout exception if an OR-Join is reached while a Business
Activity has not reached its completion state.

 The semantics of Fork and Join are such that for instance a Fork
MAY be defined without a corresponding Join. In this case, the
TimeToPerform element MUST NOT be used.
 It MUST only be used in the case where all outgoing transitions
from the Fork have incoming transitions to the Join.

 For XOR or OR Fork, this does not rule out different joins pertaining to states
emerging from a Fork or Forks.
 This allows a split in processing between a group all of which must be done and one
where at least one (or more) is sufficient for the transition.
 As bounded by Fork semantics, multiple joins may be allowed for a fork (multiple
dependencies exist)

The behavior of Forks
over Joins may be
handled by monitoring
capabilities (for example,
detection via static
analysis).
TimeToPerform Table

Forks and joins are useful particularly when activities between parties may be
optional.
e.g. in retail or manufacturing/production cases,
 order status may or may not occur.
 However, when it does occur, the order response and status are important
to the involved parties.
 In another case between a Producer and a subcontractor, the order status, a
disposition change and response, and other integration changes may or may
not occur.
 In both cases, these optional business transactions may be modeled as forks
between the related business transactions.

 Transitions can originate from Business Transaction Activities, Complex
Transaction Activities or Collaboration Activities within a Business
Collaboration.
 Guards MAY gate transitions.

 Guards refer to the status of the Activity from which the transition originates.
 The guard values include:
ProtocolSuccess,
AnyProtocolFailure,
RequestReceiptFailure,
RequestAcceptanceFailure,
ResponseReceiptFailure,
ResponseAcceptanceFailure,
SignalTimeOut,
ResponseTimeOut,
Failure,
BusinessSuccess,
BusinessFailure and Success.

Variables and Condition Expressions

Use of Variables and Condition Expressions
 Transitions MAY also have a Condition Expression element.
 Condition expression MAY depend on variables.
 Variables are named information elements that are available to
bind concepts across Business Transaction.
 Variables serve to make the semantics clear in a condition
expression.
 There are two types of variables:
- Simple: BTA and a Business Document
- Complex:

Simple Variable Complex Variable
 cannot reference another variable
 is implemented with the XPath language
and extract values from a given Business
Document.
 BTA is executed multiple times.
 contains complex expressions, which can
reference other variables.
 is specified with XSLT to enables the
passing of variables as an input to the
XSLT execution

 Variables MAY provide the capability to redefine timing expectations
during the product lifecycle.
 Variables allow abstract elements used in conditional statements as
well as external specifications (e.g. business agreements) to link to
Business Document contents.
e.g. variables may be used to apply context to a particular business transaction and
the roles involved.
 The capability to bind semantic information raises visibility to what
drives the execution of the Business Collaboration.
Variables

 Each Variable represents an abstract information element, and is defined by
XPath executed on a Business Document instance.
 Once defined a variable MAY be used in any conditional statement as a node-list
in the condition XPath.
 e.g if two variables are defined:
Variables
<Variable name="PO Accepted" nameID="H7YIUSOP“
businessTransactionActivityRef="ID122A39C23“ businessDocumentRef="ID1012">
<ConditionExpression expressionLanguage="XPath1" expression="//POAck[@status=’Reject’]"/>
</Variable>

 The implementation of the collaboration engine MAY compute
these variables whenever a document they are defined on is
processed.
 Each occurrence of the variable would be maintained, and the
entire list of occurrences of each passed as a node list to any
component evaluating a condition statement.
Variables

These variables could be made externally available for use,
such as for a business agreement.
Control of multiple instances will be handled in implementation.
Variables

 A ConditionExpression element MAY be associated to a variable, which can be
either Boolean or Decimal. When the variable is of decimal type, it is casted as
“true” when it is greater than zero and to “false” otherwise.
 ConditionExpression has an optional language attribute, which specifies in which
language the predicate is written.
 One such expression language is a DocumentEnvelope (expressionLanguage
of ExpressionLanguageType), which allows specifying the exchange of a
particular response document type, by the Business Transaction Activity from
which the transition initiates
Condition Expressions

ExpressionLanguageType
 is simply defined as the nameID of a DocumentEnvelope.
 was known in preceding ebXML BPSS versions as the
DocumentEnvelopeNotation.
 An XPath expression MAY involve the content of any
DocumentEnvelope received prior to the transition within the scope
of the current Binary (Business) Collaboration instance

 XPath expression MAY involve the content of any DocumentEnvelope received prior to
the transition within the scope of the current Binary (Business) Collaboration instance.
 XPath may operate on the result of rendering EDI into XML per ISO/DIS20625. When the
DocumentEnvelope of ExpressionLanguageType is used for an expression, the nameID of
the DocumentEnvelope SHOULD be used.
 XPath SHOULD be and XSLT (Extensible Stylesheet Language Transformation) MAY be
used, particularly when multiple condition expressions and variables are used.
 Currently or in the future, other technologies may also support the use of condition
expressions and variables include XQuery (W3C), OASIS CAM or others.

The Success and Failure elements represent
completion states

 The FromLink element ensures that a transition to a completion state MAY
be guarded by a conditionGuard.
 The Success or Failure of the collaboration does not affect the Success or
Failure of the individual BTAs, which comprise the Business Collaboration.
 The nature of the commitments is not changed when the collaboration ends
in a specific state.
 The Success or Failure of a collaboration is rather an indication, which MAY
be reported on, or acted upon to initiate other collaborations.
The Success and Failure elements represent completion states

 If several completion states are specified within a collaboration definition, the
Business Collaboration run-time instance state is “complete” as soon as one of the
completion state is reached.
 It is the responsibility of the designer to ensure that all completion states are
mutually exclusive and that once one of them is reached there are no further open
Activities.
 The BSI MUST reject all further messages associated to a collaboration instance
as soon as a completion state is reached.
The Success and Failure elements represent completion states

Here is the same Binary (Business) Collaboration as used before, with choreography.
There is a transition between the two, a start and two possible outcomes of this
collaboration, Success and Failure:
<BusinessCollaboration name="Firm Order" nameID="ID122A38D93">
<Role name="buyer" nameID="ID122A38DA3"/>
<Role name="seller" nameID="ID122A38DA5"/>
<Role name="creditauthority" nameID="ID122A38DA7"/>
<TimeToPerform duration="P1D"/>
<Start name="ID876F38OP5" nameID="ID876F38OP5">
<ToLink toBusinessStateRef="ID122A39C23"/>
</Start>
Sample syntax

<BusinessTransactionActivity name="Place Order" nameID="ID122A39C23"
businessTransactionRef="ID110" hasLegalIntent="true">
<TimeToPerform duration="PT4H"/>
<Performs currentRoleRef="ID122A38DA3" performsRoleRef="ID122A3E833"/>
<Performs currentRoleRef="ID122A38DA5" performsRoleRef="ID122A3E863"/>
</BusinessTransactionActivity>
<BusinessTransactionActivity name="Check Credit" nameID="ID122A39D24"
businessTransactionRef=" ID122A3DD33" hasLegalIntent="true">
<TimeToPerform duration="PT4H"/>
<Performs currentRoleRef="ID122A38DA5" performsRoleRef="CCinitiator1"/>
<Performs currentRoleRef="ID122A38DA7" performsRoleRef="CCresponder1"/>
</BusinessTransactionActivity>
Sample syntax

<Success name="Success" nameID="D2JSK99AK"/>
<Failure name="Failure" nameID="DK9726AJ"/>
<Decision>
<FromLink fromBusinessStateRef="ID122A39C23"/>
<ToLink toBusinessStateRef="ID122A39D24">
<ConditionExpression expressionLanguage="ConditionGuardValue" expression="Success"/>
</ToLink>
<ToLink toBusinessStateRef="DK9726AJ">
<ConditionExpression expressionLanguage="ConditionGuardValue" expression="Failure"/>
</ToLink>
</Decision>
Sample syntax

<Decision>
<FromLink fromBusinessStateRef="ID122A39D24"/>
<ToLink toBusinessStateRef="D2JSK99AK">
<ConditionExpression expressionLanguage="ConditionGuardValue"
expression="Success"/>
</ToLink>
<ToLink toBusinessStateRef="DK9726AJ">
<ConditionExpression expressionLanguage="ConditionGuardValue"
expression="Failure"/>
</ToLink>
</Decision>
</BusinessCollaboration>
Sample syntax

The completion states of this Business Collaboration definition are mutually exclusive.
Optionally the transition with the ConditionExpression could be expressed using variables
based on an XPath predicate:
Sample syntax
<Variable name="PO Accepted" nameID="H7YIUSOP" businessTransactionActivityRef="ID122A39C23"
businessDocumentRef="ID1012">
<ConditionExpression expressionLanguage="XPath1" expression="//POAck[@status=’Reject’]"/>
</Variable>
…
<Decision name="Decision10" nameID="IDDecision10">
<FromLink fromBusinessStateRef="ID122A39C23"/>
<ToLink toBusinessStateRef="ID122A39D24" >
<ConditionExpression expressionLanguage="XPath1” expression="PO Accepted" />
</ToLink>
<ToLink toBusinessStateRef="DK9726AJ" >
<ConditionExpression expressionLanguage="ConditionGuardValue" expression="Failure"/>
</ToLink>
</Decision>

Core Business Transaction Semantics
 ebXML concept of a Business Transaction and the semantics behind it are
central to predictable, enforceable commerce.
 ebXML is expected that any BSI will be capable of managing a transaction
according to these semantics.
 ebXML Business Transaction semantics, i.e. the rules and configuration
parameters required for BSI software components to predictably and
deterministically implement
 ebXML Business Transactions, allows you to specify electronic commerce
transactions that provide

Core Business Transaction Semantics
Interaction
Predictability
clear roles, precise transaction scope, understood time bounds, succinct
business information semantics, and unambiguous determination of Success
or Failure. Each party can compute without ambiguity, transaction status is
independently.
Ability to shared
(expectations
between parties)
ability to specify that Business Transactions MAY be agreed to show intent of
the parties.
Non-repudiation MAY specify the keeping of artifacts to aid in legal enforceability.
Authorization
Security
MAY be specified to require authorization of parties performing roles.
Document Security
MAY be specified to be authorized, authenticated, confidential, tamper
detectable.
Reliability ability to specify reliable delivery of Business Documents and signals.

 The condition expression and variable functions allow assignment
of the TimeToPerform value through the process lifecycle to enable
late binding.
 The TimeToPerform element MAY specify a duration and a type
(for example, the value MAY be specified at design time).
 More requirements will be gathered to further understand the
definition, use and other scenarios where variables may apply.
Summary

6.pptx

More Related Content

Similar to 6.pptx (20)

More from ssuser0d0f881 (20)

Recently uploaded (20)

6.pptx