BPMN11 — differentiate a business message from a business signal

Comment to BPMN FTF:

• Currently there is no standard way to differentiate a business
  message from a business signal, which have fundamental different
  characteristics.

========
During the ebBP-BPMN discussions last week, 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

1. 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

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).

Additional note: We have seen tools that actually use the properties of messages to delineate a signal (such as a stereotype).

• 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.

Suggested Resolution:
Close, No Change: This issue is out of scope for the RTF and will be addressed by the response to
the BPMN 2.0 RFP.
Revised Text: None
Disposition: Closed, deferred