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] | [Elist Home]

Subject: Re: BPSS Strategic issue: one and only one metamodel


I agree fully that ebXML must support the three cited sources of rules
for legally binding electronic commerce.

I disagree, however, with the implication that SpecSchema v0.99 does not
support these rules.

To your five lettered issues:

A) Lines 420-421
This issue is as far as I can see about the text of the document only. 
The SpecSchema model itself does support the full transaction model. 
If you feel that is not the case, please point out where the model itself
falls short.

B) Lines 1672, 2385
The "isSuccess" flag is not the only way of determining transaction success.
The full transaction semantics are supported, all signals, flow of control,
and associated success and failure. The "isSuccess" flag is merely a
convenient way of quickly looking at a DocumentFlow and knowing whether to
interpret it as a successful response or not. Again, if you see shortcomings
with the model  itself, please point out where the model itself falls short.

C) Lines 527-528 (figure 5)
I am open to discussion of re-introduction of Document Envelope. However, its
absense does not in any way prevent implementation of multi-hop or brokered
solutions. The document flow models the information 'bundle' that goes from
the requestor to the responder (and vice versa). If that bundle does not
change during a multi-hop or brokered model, then you do not need to model it.
If it does change, then you do not have a simple multi-hop, you have a
multi-party, and need to model it as such.

D) Line 586, 1046-1047, 1215, 2529, 2553
These parameters were left at BusinessAction level by agreement with Jim
Clark. Having them there allows for a more flexible model, but does not
prevent practitioners from sticking with current UMM constraints.

E) Lines 1601, 2527, 2551
Same comment as D) above.

Now a couple of questions/concerns with the statements about process focus.

1. UMM allows you to model the requesting and responding activities, but has
no  semantics about what each activity actually does or what it results in.
Therefore I do not understand how a model that names a requesting and
responding activity explicitly is richer than one that only implies them
through roles. I understand that REA is a way that we could express results of
a transaction, but we all agreed under your guidance to table that for future

2. UMM specifies a transaction as two activities in an activity diagram, with
object flows from requesting to responding and optionally back to requesting.
Does that not create an eternal loop activity diagram? I don't know if it
actually violates UML rules, but it certainly is an unorthodox use of an
activity diagram.


>This is the discussion of one of the three strategic issues
>with the ebXML Business Process Specification Schema V0.99
>that I believe are highest priority for ebXML BP right now.
>1. One and only one metamodel.
>    The firm agreement I seek is that the BPSS must be
>    a strict subset of the UMM Metamodel, so that 
>    BPSS-compliant XML runtime business process specifications 
>    may be derived from UML models that conform to the UMM 
>    Metamodel.  In other words, we need one and only one
>    metamodel. This is an issue of conceptual integrity so
>    everything fits together smoothly.
><Tim McGrath>
>the Quality Review team are concerned about the weak alignment of some of
>documents with the ebXML Specification Schema.  In many cases they either
>fail to
>differentiate or clearly specify the relationship between the UMM Metamodel
>and the
>Business Process Specification Schema.
>We are concerned that the confusion these current documents may spawn within
>the wider
>community will be damaging to the overall ebXML initiative.  For example, it
>perceivable that these documents could result in development of UMM Metamodel
>business process models, but not ebXML compliant models.
></Tim McGrath>
>Why does the QR team have this perception, when the following
>statement should settle the confusion:
><Specification Schema 0.99>
>Lines 314-319:
>The UML Specification Schema is a semantic subset of the metamodel behind
>UMM as specified in UN/CEFACT TMWG's N90, expressed as a standalone 
>UML profile. The UML Specification Schema will through the application of 
>production rules produce an XML Specification Document is analytically, 
>semantically and functionally equivalent to one arrived at by modeling the
>subset through the use of UMM and its associated production rules. 
></Specification Schema 0.99>
>Is it because there actually are easily-detectable differences, such that
>the Business Process Editor developers are asking me off-line how
>to resolve them?
>Why is this important?
>1. UMM is mandatory for modeling in ebXML.
>From the approved ebXML Technical Architecture Specification v1.0.4:
>Lines 315-328: 
>"ebXML Recommended Modeling Methodology
>"Business Process and Information Modeling is not mandatory. However, if
>and users select to model Business Processes and Information, then they SHALL
>use the
>UN/CEFACT Modeling Methodology (UMM) that utilizes UML."
>Given its mandatory status, for the BPSS to diverge from the UMM
>Metamodel opens a hole in the body of ebXML specs.
>2. ebXML does not work in a vacuum.  It must be integrated
>with business collaboration processes beyond the 1.0 specs
>and also integrated with internal business apps.  Many people
>will want to do this in UML.  Many organizations that will want
>to use ebXML have already adopted UMM. Besides being
>mandatory, UMM is a actually a good methodology for 
>developing business systems in which ebXML
>will be one of the collaboration technologies.  
>3. For some people, UML is overkill.  For them, the BP group 
>as a whole has agreed with the concept of a simpler 
>Business Process Editor which can generate both
>UMM Metamodel compliant UML models (represented in
>XMI or RDF) as well as Spec Schema-compliant XML
>for use with CPAs at runtime.  We also had an agreement
>on a simpler subset of UMM that the BPE could edit and
>derive all of the artifacts for the whole Metamodel as well
>as the runtime XML.  However, this agreement was predicated
>on "one and only one metamodel".  If the BPSS and UMM
>are out of sync (which appears now to be the case), then
>the BPE developers are faced with the choice of which
>to support, Metamodel or BPSS, when the two of those
>should be semantically the same.
>I am not going to get into the differences between BPSS and
>UMM Metamodel in this message, only to highlight the
>issue and state my opinion which is that apparent differences 
>should be considered to be guilty until proven innocent.
>(Some of the most important divergences are highlighted 
>with line numbers in the related Transaction Integrity detail 
>Bob Haugen
>To unsubscribe from this elist send a message with the single word
>"unsubscribe" in the body to: ebxml-bp-request@lists.ebxml.org

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

Search: Match: Sort by:
Words: | Help

Powered by eList eXpress LLC