OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-bp message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: [ebBP] 2/16/2004: Business Transaction Patterns WI 22 [RSD]


Discussion: OASIS.ebBP.WI22-Transaction Pattern Support;
Attachment|http://www.oasis-open.org/archives/ebxml-bp/200402/msg00145.html;
Attachment|http://www.oasis-open.org/archives/ebxml-bp/200402/msg00149.html;
Topic|;
Point|RequestingBusinessActivity Attribute Values;

mm1@
||Note: Attachments are to Roberts posting with the .png and .gifs for 
Commercial Transaction and Information Distribution.

Key points to consider:

    * Explicit definition of business transaction patterns
          o This may also provide helpful for implementors (See Work
            Item 19 and 37, one asking about the use of BPSS instances).
          o Provide mechanisms to allow understanding, usage and
            extension of business transaction patterns
          o In later versions, consider accommodating explicitly
            dispatch/reach and offer-acceptance. The current in-work
            proposals do not preclude extensions to investigate these
            additional patterns.
          o In the future, this structure may allow extensibility for
            vertical industry or evolving business transaction patterns.
    * RequestingBusinessActivity attribute settings
          o The RequestingBusinessActivity shown is derived by
            restriction which means that no new attributes would be
            allowed. Martin Roberts has identified two options.
                + Set attribute settings to values as described by the
                  document that explained the patterns (as shown in
                  referenced attachments)
                      # Use of prohibit for attributes that do not apply
                        to the pattern - no override possible.
                + Do a similar definition (as shown in referenced
                  attachments) except use default values to show what
                  should be used but allow for overriding. This would
                  mean that it would be possible to insist on
                  Non-Repudiation with an InformationDistribution. As
                  the link between the BusinessTransactionAcitivity and
                  the BusinessTransaction is a IDREF (GUIDREF) there is
                  no change to the BusinessTransactionActivity for this
                  change.

Our potential requirements as outlined in the draft white paper are:

    * Provide explicit definition for business transaction patterns
    * Consider extensibility options for business transaction patterns
    * Support other role, packaging and multi-party objectives
    * Consider how this relates to or could be impacted by WSDL proposal
      if any (WI 12)


Martin, I support your proposals for business transaction patterns and 
feel the second option above is more palatable and less restrictive, yet 
affords the optionality that may be desired. Perhaps it today's call the 
team can discuss the use of default values. Thanks.

@mm1



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]