[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: bpmn 2/13/2006: BPMN FTF Comment (Description of a Business Signal)
During the ebBP-BPMN discussion last Tuesday, I was asked to summarize
what business signals are and how they function. There has been some
initial discussion on the bpmn@omg.org list re: signals in general. I'd
like to make a necessary distinction about the similarities and differences.
* What is a business signal? [1]
o "Business signals have a specific business purpose and are
separate from lower protocol and transport signals. One or
more Business Signals can be exchanged as part of a Business
Transaction to ensure state alignment between both parties.
Evaluation of business signals enable the state of a
Business Collaboration to be explicitly calculated at run
time. The ebBP technical specification provides both the
structure and choreography of Business Signals, including
allowing for user defined signals....
A Business Signal is computable. This provides the
collaborating parties with a mutual understanding of the
business activity. This function allows the parties to know
if their expectations in a Business Transaction are
realized. This is state alignment, and is important in order
for the ebBP specification to have commercial viability. The
ebBP specification provides the ability to conduct intended
transactions if that is the intent of the collaborating
parties."
* Where does the business signal fit in eBusiness and business
messaging? [2]
o State alignment: (almost quoting from our specification for
specifics) The process of exchanging signals and state
changes of a Business Transaction enables state alignment
between the parties involved. If the standard signals are
used, the structures of ebXML Business Signals are
‘universal’ and do not vary from transaction to transaction.
Business signal schema can be found at:
http://www.oasis-open.org/committees/document.php?document_id=16460&wg_abbrev=ebxml-bp
(detailed schema documentation also exists on this public
page). The ebBP technical specification provides both the
structure and choreography of Business Signals. The ebXML
Message Service Specification (and other evolving
technologies) provides a reliable messaging infrastructure.
This is the basis upon which the ebBP technical
specification builds its protocol for business state
alignment using Business Signals. The Business Signal
payload structures are optional and normative and are
intended to provide business semantics to the Business Signals.
o Part of process definition: Defined in the BT pattern and
bounded by partner expectations. Map back to business
transaction activity. Map back to service and action context
for agreement (such as CPP/A).
o Transition and determination of several types of successes
and failures: Condition guards exist on transition in
process steps and activities. Business signals are integral
here. In ebBP and in business collaboration, there is
protocol and business success whereby one supports the
other. Reference:
http://www.oasis-open.org/committees/document.php?document_id=16457&wg_abbrev=ebxml-bp
(See Section 3.6.3)
* What happens if you don't model these signals?
o In configuration: Business and messaging signals are
explicitly modeled in configuration.
o In understanding the partner agreement: The partners may
mutually expect these be used and therefore set criteria
associated with the progress and outcomes of the business
process (and its activities).
o In managing state transitions: See previous comment.
o In seeking to generate computable artifacts: Without the
definition of such signals, the artifacts either have to be
defined out of band or in a potentially proprietary way. We
allow user-defined signals, although they are still related,
included and part of the business process.
* Links to the business process [3]
o Standard signals: Defined structure and semantics related to
the pattern, activity and transitions
o User defined signals: Allowed pointers to user-defined structure
o BT patterns
+ Template: See patterns matrices in the specification
(sections 3.4.9 and 3.4.9.1) that specify how these
signals infer content validation, succesful syntactic
validation and also allow the business process to
proceed (or not).
+ Profile: Partners identify their expectations using
the patterns and the selectable criteria to support
not only the business messages received but the
business signals that support them.
o Relevance to model
+ Business Transactions and the Business Service View
[4. See Chapter 9].
+ Business significance
# Involves timing parameters, implication to
business partner expectations, etc. Several
important criteria are defined around the use of
the business signals. [4. See Chapter 8. State
notations and their relevance to partner
expectations are found in Chapter 9.]
You can see how signals are used in the process definitions found on our
public web site at: (ePV, Netherlands example)
http://www.oasis-open.org/committees/document.php?document_id=16436&wg_abbrev=ebxml-bp
Comment to BPMN FTF:
* Currently there is no standard way to differentiate a business
message from a business signal, which have fundamental different
characteristics.
Facts
* Properties such as line width or color could be used but can't be
seen if printed on black and white.
* Properties such as message and (add) signal could be used. The
latter would have to be added. There would also possibly need to
be a way to differentiate whether or not business signals were
used as the implementation and runtime results may differ given
that assumption (different semantics).
* In order to maintain the focus of generation of software
artifacts, business signals should be considered for modeling in a
standard way (preferred to a tool specific option).
* Business signals differ from underlying messaging infrastructure
acknowledgements. Several communities including UK Bristol
government and ePV have indicated the value of the use of business
signals. Supports monitoring framework as well.
Business example
Two partners agree to engage in a Commercial Transaction pattern and use
the BT from the pattern. A BTA is developed in a Business Collaboration
to support these expectations. The partners will use reliable messaging
and they use the business signals. An intelligibility (syntactic) check
is made on the business message before the Receipt Acknowledgement
business signal is sent, and successful business processing is required
on the business document before an Acceptance Acknowledgement business
signal is generated. Both carry timing expectations with them (in
support of the BTA). For example, an Order Management system would
validate a business document meets the partner expectations before
initiating a sales order and sending a Response from a Purchase Order
Request. Prior to the Response being sent these signals are used. They
also allow the partners to optimize where required. The Buyer
(Requesting Role) can understand that the Request was received and then
whether or not it was successfully business processed (i.e. alleviating
the potential need to query another Seller). Let's assume the Purchase
Order doesn't muster in validation processing, then a Negative
Acceptance Acknowledgement is sent. The Buyer (Requesting Role) may have
an early indication and then can send a Cancel Transaction. Both parties
are able to react more quickly to current conditions. In addition the
business signals give clear indication of state alignment (the parties
have a shared understanding of their condition and state of the business
expectations).
Example business signals found at:
http://www.oasis-open.org/committees/download.php/16652/ebxmlbp-v2.0.2-cd-ExampleSignals.txt
[1] From our FAQ found at:
http://www.oasis-open.org/apps/org/workgroup/ebxml-bp/download.php/16540/ebBPv2.FAQ.html
[2] Not transport level or HTTP acknowledgements.
[3] Business signals defined in Section 3.4.9.3 at:
http://www.oasis-open.org/apps/org/workgroup/ebxml-bp/ (in technical
specification)
[4] This reference was provided on the public bpmn@omg list late last
week - N090 UNCEFACT Modeling Methodolgy R10 [1]. The business signals
occur in the Business Service View (which is different than a transport
level component), see: http://www.ifs.univie.ac.at/untmg/
(UMM_N090R10_2001-11_01.zip) - See chapters 8-9.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]