BPMN 1.1 MAILINGLIST Avatar
  1. OMG Issue

BPMN11 — differentiate a business message from a business signal

  • Key: BPMN11-14
  • Legacy Issue Number: 9364
  • Status: closed  
  • Source: Anonymous
  • Summary:

    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.

  • Reported: BPMN 1.0b1 — Tue, 14 Feb 2006 05:00 GMT
  • Disposition: Resolved — BPMN 1.1
  • Disposition Summary:

    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

  • Updated: Fri, 6 Mar 2015 20:57 GMT