UMM/X  - Business Dialog

The Business Dialog technology is based on UMM and its goal is to be a Business Collaboration Protocol and not a protocol that may be used for business purposes. This goal has lead to a number of design choices not normally found in protocols such as BPSS.

The B.Dialog is based on the notion of an agreement between two or more parties. It captures details of exchanges of data messages between parties and includes observable conduct as well as internal conduct. B.Dialog realizes that its is a protocol for communicative conduct, send and receive and not an agreement for business performances. However the two aspects are closelly integrated since a data message exchange with commercial information cannot be done without a business purpose. In this aspect other UN/CEFACT metodologies are planned to be supported.

The B:Dialog could be used as a drop-in replacement for BPSS and as a foundation for a Web-Services Business Profile, possibly ontop of WS-CDL and BPEL

Design considerations:

  • Trading Partner Agreement: A number of key formal and legal principles are supported directly (proactive law principles). Examples are:
    • Dispatch and Reach: The criterias for D/R are oftern hidden in specifications and must be, ex post, extracted.
    • Acknowledgement of Receipt and Business Acknowledgement
      (through Common Business Acknowledgement)
    • Contract formations performatives: Propose, Accept, Reject, Revoke, Withdrawal, Notice, Dispute, CounterOffer, etc.
    • Establishment of Governing terms and conditions such as confidentiality clauses
    • Dispute resolution and break-out dialog (sidebar)
  • Variability: An important requirement has been the support for variations of business processes. A number of mechanisms are available:
    • Reuse and compositability
    • Templates
    • Restriction
    • Extension
  • Technology neutral definitions, context specifics: The B.Dialog support Core Components directly by adopting the core principles of separation between technologt independency and context derived protocols. This makes B.Dialog Core Component compliant, but it is still possible to only reference to information by type or schema.
     
  • Trust and establishment of a business relationship: The B.Dialog supports multiple ways of initiating a collaboration, relationships
    • Implicit - A collaboration is established implicitly by sending the first data message
    • Explicit - An initial data message is sent, inviting a party to participate with important parameters and credentials. If the invitation is accepted then the collaboration may proceed within agreed parameters.
  • Time To Perform: What does TTP entail? Is TTP only defined by a fixed time or is the timeline for  data messages determined by informations such as due date, delivery time etc? B.Dialog support multiple types of definitions
     
  • Structured Information vs Document-Attachment: Business information are organized around UMM:StructuredInformation and InformationEnvelope since it promises to better capture relevant business semantics. The document with attachments that does not affect processing, approach is not being used since it is semantically not as rich and may lead to situations where the division between document and attachment poses more questions than answers. An example is: what happens when an Invoice captured XML is sent as document and a picture of the same invoice is sent as attachment and the picture contains more information such as a diagrams of company logo and signature?
     
  • Business Rules: In order to be able to achieve shared and common understanding between trading partners it is important that business rules are fully integrated with data message exchange definitions. If not then these rules are still captured on paper the old way and has to be interpreted leading possibly to different result.
     
  • Third party perspective: In many protocols that assume a thrid party perspective, i.e. looks at the common behavior the actions taken by individual parties are embedded in higher level constructs such as business transactions etc. The B:Dialog assumes a third party perspective by approaching data message exchanges from an agreement point of view. However individual conduct expected by each partner is directly visible in the b.dialog specification. After all in an contractual environment each partner has to be responsible for its own actions.
     
  • Outcomes: In some protocols the outcomes of a data message exchange are defined in business terminology such as business success or failure. A business success could be vieved as a valuation statement by a partner and does two trading partners really want to express their business expectations in  a specification of data message exchanges? Is it really a business success that a complaints report has been successfully transmitted between parties? B.Dialog support named outcomes in order to be able to specify desirable paths of communications such as “happy path”.
     
  • More design consideration later:
  • ...

    • Contact  Webmaster  with questions regarding this site.
    Copyright 2007 by Toolsmiths AB. All rights reserved.

    UMM/X Business Dialog