Re: BPSS Strategic issue: one and only one metamodel

[Jim Clark <jdc-icot@lcc.net>]

Karsten Riemer wrote:

> Bob,
>
> 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.

I wish this woulod be true, however the issues that Bob Raises is correct. The BP
Spec does not comply with the referenced documents and if we do not bring it in
alignment, those who use the BP Spec in the future will find problems when using
them in open trade markets.
I have reviewed this with one of my trade lawyers associated with E2open and Bob's
understanding is currect. As the BPSpec stands now I will not be able to use it in
E2open because of the nature of our business.

>

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

This flag MUST go away.

>
>
> 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
> versions.
>
> 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.
>
> Thanks,
> -karsten
>
> >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
> >these
> >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
> >is
> >perceivable that these documents could result in development of UMM Metamodel
> >compliant
> >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
> >same
> >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
> >implementers
> >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
> >message.)
> >
> >Respectfully,
> >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
>
> ------------------------------------------------------------------
> To unsubscribe from this elist send a message with the single word
> "unsubscribe" in the body to: ebxml-bp-request@lists.ebxml.org

begin:vcard 
n:Clark;James
tel;cell:936.524.4424
tel;work:936.264.3366
x-mozilla-html:FALSE
org:I.C.O.T.
adr:;;10987 Quinlan N Lake;Conroe;TX;77303;
version:2.1
email;internet:jdc-icot@lcc.net
title:Principal Consultant
fn:James Clark
end:vcard