Tr: ebXML metamodel write-up

["agrangard@nycall.com" <anders.grangard@edifrance.org>]

----- Original Message -----
From: Bob Haugen <linkage@interaccess.com>
To: 'agrangard@nycall.com' <anders.grangard@edifrance.org>
Sent: Tuesday, July 25, 2000 4:39 PM
Subject: FW: ebXML metamodel write-up


> Anders,
>
> I can't post to the architecture list right now, so as you are
> distributing Karsten's excellent message, please also forward
> my additions and corrections below.  Karsten agreed with my
> comments and they will added to the next version of his document.
> I don't want the "missing links" to keep being missed.
>
> Thanks,
> Bob Haugen
>
> -----Original Message-----
> From: Bob Haugen [SMTP:linkage@interaccess.com]
> Sent: Monday, July 24, 2000 7:03 AM
> To: ebxml-bp@lists.ebxml.org
> Subject: RE: ebXML metamodel write-up
>
> Karsten et al,
>
> >I have written all of the above up in the attached document, and
> >would like to request that this document become part of our next release
of
> >the BP specification and/or part of the architecture specification.
>
> I like your document very much, but some details need work.
> The Resources and Contracts package is not linked or used
> in the places it should be used, and one important use (templates
> or patterns) is not listed or explained.
>
> _Links:_
> 1. Resources and Contracts are the stereotypes or abstractions
> classifying BusinessInformation and Core Components.  So there
> should be a described link between R&C & BI packages.
> Scott Nieman recently discussed this usage in a comment
> to Paul Levine following TMWG:
> "Anything can be placed in a repository, however, there MUST be a
> classification scheme to properly register "it", or you will never be able
> to find it."
> The Resources & Contracts package should contain classifications
> of the larger core components; Markets & Parties some more.
> One classification that we may need to add is Location; another
> might be something like Quantification.  What's needed will
> depend on the incoming core components, so new classifications
> may be required as repositories evolve.
>
> 2. Also, Markets and Parties offer EconomicResourceTypes, so there
> should be a described link between M&P and R&C.
>
> _Templates or Patterns_ (I use Template, Jim Clark uses Patterns):
> Re-usable configurations of classified objects can be provided
> for many common situations that will greatly speed the design
> of business process models.  For example, Jim Clark provided
> a set of patterns for commercial transactions that were
> incorporated into the TMWG document.  The retail industry
> GCI project had spent many days creating a model that would
> have taken minutes had Jim's patterns been available to them.
> Likewise, Bill McCarthy and I are working on templates for
> both simple and contractual commercial exchanges.
> Templates or patterns must be based on higher-level abstractions,
> e.g. metamodels, and then instantiated with members of
> concrete classes.
> The exchange templates will use stereotypes or abstract
> superclasses from the Resources and Contracts package.
>
> Your "Use...Evolution" section should describe the use of
> templates or patterns (and yes, we should decide on a
> common term) to define their B2B processes more
> efficiently and correctly.  It is very common, and I saw
> yet another demonstration last week, for experienced
> business models to take days to model even simple
> processes.  Templates or patterns can reduce this
> time and confusion significantly.
>
> Design patterns have proven their value in the programming
> arena; XML patterns are starting to take shape; commerce
> patterns are next, and they are already starting to emerge
> from the TMWG and ebXML efforts.
>
> Respectfully,
> Bob Haugen
>