Re: Summary of Wednesday conference call

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

Mary Kay,

I whole heartly agree with you. My correction was to clarify the direction of
dependency between the various aspects of the methodologies and how one aspect
builds on the other.

Also to chose UML does infer UMM, however to chose UMM does imply UML.

Happy holidays,
Jim

"Blantz, Mary Kay" wrote:

> Our vision is that companies/industries who wish to standardize their
> implementations would be able to find their business processes in the
> repository.  We will recommend that they develop models and essentially
> 'match' the models.  I don't see how this can be done if they are not
> using the same methodology.
>
> In addition, I thought that UML (and therefore UMM) was chosen.  Seems
> very late in the game to consider alternatives.
>
> Mary Kay
>
> -----Original Message-----
> From: Jim Clark [mailto:jdc-icot@lcc.net]
> Sent: Friday, December 15, 2000 7:20 AM
> To: Bob Haugen
> Cc: 'ebxml-ccbp-analysis@lists.ebxml.org'
> Subject: Re: Summary of Wednesday conference call
>
> Correction to Item 12.
> The UMM is supported by, has incorporated the metamodel. Not the other way
> around.
> The way to think about it is as follows.
> 1) The metamodel precisely defines the syntax and semantics of a business
> domain.
>
> 2) The patterns constrains the use of the semantics into well structured
> artifacts of common use.
> 3) The UMM prescriptively defines a set of steps to follow to assure that
> processes defined using the patterns are complete and well formed.
>
> The UMM is based on or uses a set of patterns that are based on or defined
> by a
> set of semantics (metamodel).  The metamodel does not require the use of a
> certain methodology, however the UMM has been developed to efficiently
> answer the
> questions and define the requirements that occur in eComm domain.
>
> Hope this helps.
> Jim
>
> Bob Haugen wrote:
>
> > As those of you who attended know, I was deputized by the
> > Boston metamodel face-to-face meeting to get feedback from
> > the Common Business Process work group on the "specification
> > schema" developed in Boston.
> >
> > If you attended the call, please send additions and corrections
> > in reply to this message.  If you did not attend, and have comments
> > on the Boston results (posted to the main BP list), please send
> > them directly to the BP list.
> >
> > I will post a revised version of this message to the BP list tomorrow.
> >
> > Attending the conference call were:
> > Bob Haugen
> > Brian Hayes
> > David Welsh
> > Jim Clark
> > Jenny Xu
> > (please tell me if I missed anybody)
> >
> > I will not attribute most comments to particular individuals,
> > but as a consensus list of issues and comments.  Again,
> > please tell me if you think there was no consensus on a particular topic.
> >
> > 1. Comments on the diagrams in the file ebXmlSpecificationModel08.pdf
> > included in the zip archive in the message:
> > http://lists.ebxml.org/archives/ebxml-bp/200012/msg00029.html
> >
> > In the diagram on page 1, the classes Package and Package Content
> > do not appear in the metamodel nor in any of the other submissions
> > from the Boston meeting, nor do they make sense in terms of a
> > business collaboration.
> >
> > Likewise, the diagram on page 2 appears to be a deviation from the
> > metamodel and the other diagrams from Boston.
> >
> > 2. In general, names should be the same from the metamodel to
> > the specification schema to the DTD (where the names refer to
> > the same concept).
> >
> > 3. Can the same document type be used for both success and failure?
> >     There was a long discussion here which repeated those in Boston
> >     about the different termination states of a business transaction -
> >     Success, Control Failure and Business Failure - and the various
> >     causes of each.  One answer to the above question was that
> >     if (for example) a Purchase Order Reponse document type was
> >     returned in response to a Purchase Order Request, and the
> >     Response document said it rejected the Purchase Order Request,
> >     the business transaction could still end in success, and the
> >     fact that the order was rejected would need to be handled in
> >     higher-level collaboration software.  (I do not think this is an
> >     adequate summary of a long discussion, but it would take
> >     a whole document about business transaction and collaboration
> >     design considerations to do much better.  Suggestions
> >     would be welcome here...)
> >
> > 4. The name Document Transition Vehicle was disliked; the group liked
> >     the original Document Envelope better.  There was a long discussion
> >     over whether double-wrapping of documents was necessary (business
> >     Document Envelope in addition to transport packaging).  At the end,
> >     double-wrapping seemed to be justified for process-to-process
> >     security and multiple documents in one Envelope.
> >
> > 5. A related question: is Document Envelope required?
> >     Answer: yes for Requesting Activities and substantive responses,
> >     no for business signals like acknowledgments.
> >
> > 6. Does RosettaNet use Document Envelopes?  Jim Clark says
> >     there is a similar structure with a different name.  He will research
> >     what the exact name is and if there are any significant differences.
> >
> > 7. An unanswered question:  will transferring from one e-commerce
> >     framework to another be trouble?  For example, X12 or BizTalk
> >     or Commerce One or RosettaNet to ebXML.  Jim Clark says
> >     that RosettaNet to ebXML will be no trouble; the others will
> >     require translators (at least).
> >
> > 8. All views of the metamodel should be able to be registered
> >     and retrieved from registries, not just the elements in the
> >     specification schema.  The BRV and BOM views will be useful
> >     for process documentation, analysis and queries.  Tracking and
> monitoring
> >     software may be developed using higher-level views of collaborations,
> >     if nothing else.
> >
> > 9. Being able to monitor the current state of a transaction or
> collaboration
> >     will be critical to successful electronic business.
> >
> > 10. The infrastructure release with a limited specification schema
> >       should not be regarded as the end of the road for ebXML; there
> >       is a lot more to do - in particular, higher levels of collaboration
> >       such as order, fulfillment and payment.
> >       How is the infrastructure release going to be different from
> >       traditional EDI?  What the added business value?
> >       There was general concern that the infrastructure release
> >       was no more capable than RosettaNet.  A quote from
> >       David Welsh:  "ebXML is about doing business, it's not
> >       about transport."
> >
> > 11. Can other methodologies be accomodated besides UMM -
> >       in particular, IDEF?  The consensus was that IDEF diagrams
> >       could be derived from UMM models, but not round trips.
> >       The metamodel was too dependent on UML semantics
> >       to be completely specified in IDEF.
> >
> > 12. A related question:  has UMM been adopted by ebXML or not?
> >      (The significance here is that the Common Business Process
> >      and Methodology subgroups have adopted UMM as their
> >      methodology.)  Jim Clark said that the BP metamodel uses
> >      UMM, and that UMM has embraced the BP metamodel, but
> >      the answer to the above question is not clear.
> >
> > Please send feedback.
> > Respectfully,
> > Bob Haugen
begin:vcard 
n:Clark;James
tel;cell:936.524.4424
tel;work:936.264.3366
x-mozilla-html:FALSE
adr:;;;;;;
version:2.1
email;internet:jdc-icot@lcc.net
fn:James Clark
end:vcard