Re: ebXML metamodel write-up

["Paul R. Levine" <plevine@telcordia.com>]

Duane,

We didn't intend to expand the scope of the ebXML architecture.  I go along with
Karsten's suggestion of keeping marketplace in the metamodel, if only to help in
deriving the context at this point.

Paul
---------------------- Forwarded by Paul R. Levine/Telcordia on 07/26/2000 05:46
PM ---------------------------


Duane Nickull <duane@xmlglobal.com> on 07/26/2000 12:31:04 AM

To:   "Paul R. Levine" <plevine@telcordia.com>
cc:   ebxml-BP@lists.ebxml.org (bcc: Paul R. Levine/Telcordia)
Subject:  Re: ebXML metamodel write-up




Paul:

I read those words too but I think the confusion lies with the need for a
discovery
mechanism to find businesses in the first place.  Think of a sort of "Yellow
Pages"
to look up businesses.  I don't think we have the person power in Tech Arch to
address this at this stage.  We will not architect anything that would
specifically
disallow this type of mechanism from being added on at a later date.

The process of discovering a company's interfaces (assuming you have already
found
the company), is certainly a necessity.

Duane Nickull

"Paul R. Levine" wrote:

> Karsten,
>
> The following is extracted from the requirements specification.  It sounds to
me
> like the requirements call for "the need for discovery of products and
services
> within a market place."  If these words are used, I don't think we're off
track.
>
> Paul
>
>   ------------------------------------------------------------------------
>
> 

¨    Provide a BPDS that enables an organization to express its business
> processes to such an extent that other organizations can discover -
> ?    the kind of organization the process belongs to
> ?    the business processes belonging to an organization
> ?    the interaction points in the organization?s business process in order to
> determine whether and how to engage in business
> ?    the kinds of information exchanges required to conduct a particular
> interaction in the business process
> ?    company interactions and services and categorize them
> ---------------------- Forwarded by Paul R. Levine/Telcordia on 07/25/2000
06:43
> PM ---------------------------
>
> Karsten Riemer - Sun IR Development <Karsten.Riemer@East.Sun.COM> on
07/25/2000
> 05:42:10 PM
>
> Please respond to Karsten Riemer - Sun IR Development
>       <Karsten.Riemer@East.Sun.COM>
>
> To:   ebxml-BP@lists.ebxml.org
> cc:   duane@xmlglobal.com (bcc: Paul R. Levine/Telcordia)
> Subject:  Re: ebXML metamodel write-up
>
>   ------------------------------------------------------------------------
>
> FYI,
> my metamodel write-up has circulated on the architecture list and
> has drawn the comments included below.
> Does anyone on the BP team have a reference in the requirements
> doc to the need for discovery of products and services within a
> market place? If not, maybe Duane is right, we should drop it.
> That would not preclude the discovery of particular kinds of processes.
> I think what Duane is suggesting is that we keep the process category
> kind of discovery, but drop the marketplace kind of discovery.
> Marketplace would still remain in the model as one of the ways to
> derive context.
>
> -karsten
>
> ------------- Begin Forwarded Message -------------
>
> Date: Tue, 25 Jul 2000 12:41:47 -0700
> From: Duane Nickull <duane@xmlglobal.com>
> MIME-Version: 1.0
> To: Karsten Riemer - Sun IR Development <Karsten.Riemer@east.sun.com>
> CC: ebXML-Architecture List <ebxml-architecture@lists.ebxml.org>
> Subject: Re: ebXML metamodel write-up
> Content-Transfer-Encoding: 7bit
>
> Thanks Karsten:
>
> Here are some comments:
>
> Your meta model states:
>
> >>>Steps of electronic business
> In order for enterprises to "do business with each other" they must
> first:
> 1.   Find out about each other's existence and what products and services
> they can offer each other<<<
>
> IMHO - this is explicitly out of scope of ebXML.  The discovery phase
> has not been adressed in the TA Spec nor have they been included in any
> discussions.  I did not recall it being included in the Requirements
> Document which mandated our Technical Architecture Specification.  If
> this is wrong, someone please correct us now.
>
> On Page 2, it states:
> >>>>>The ebXML metamodel consists of distinct but interrelated sub-metamodels
> each corresponding to one of the 6 steps of doing electronic business as
> described above.
> 1.   Markets and Parties: For describing and discovering the markets, the
> market players and their product and service offerings<<<
>
> I totally agree with the subsequent discovery of process uses for ebXML
> however, I did not recall the actual marketplace for discovery as being
> within the scope fo ebXML and our group, Technical Architecture, has not
> completed any work in this realm.  We anticipated that existing
> electronic marketplaces would facilitate this goal and ebXML will
> concern itself with the remaining 5 items on your list.
>
> Please - again someone correct us if we are wrong here.  We specifically
> are mandated by the Requirements document which does not describe any
> such functionality (to my knowledge).
>
> On page 3 you wrote:
>
> >>>Independence of ebXML sub-metamodels
>
> Although clearly interrelated, the ebXML sub-metamodels are not tightly
> dependent on each other, and implementations of one can be very
> beneficial even in the absence of implementations of one or more of the
> others. <<<
>
> This is totally not true in the case of business process and business
> information.  The business process is dependent on being able to specify
> which core components (data Elements) are necessary for each party to a
> transaction to meet their respective legal and business requirements.
> One cannot exist effectively without the other.  I can't just say "send
> some information to me" to place a Purchase Order.  It has to be
> specified "Please send me the thing I call address, the thing I call
> name, the thing I call telephone number etc.  Each of those objects has
> to also have the ability to be referenced via a repository so the sender
> also knows what they are.  The semantic reference from a repository
> dictates that the RegRep access process be integrally bound to
> potentially all transactions (at least in an abstract way - we are
> suggesting the use of a cache in the application to ease congestion to
> the repository query daemon).
>
> Also - A core component cannot be used effectively without a contextual
> guide to allow it to be instantiated correctly depending on the business
> process it is part of.  I can't just say Item <a> is equivalent to Item
> <b> if there are ten places in each document where there are instances
> of those elements.  I need to know the context in which thety are being
> used.
>
> TRP as a stand alone - yes - excellent work being done there.
>
> I look forward to seeing more on the subject of using the UML -> XML
> process for data elements and business processes.  This is an area we
> are concerned about.
>
> Duane Nickull
>
> ------------- End Forwarded Message -------------
>
> ---------------------------------------------------
> Karsten Riemer,
> Director, Information Architecture,
> Enterprise Management Architecture Group
> Sun Microsystems Inc.,
> MailStop UBUR03-313
> 1 Network Drive,
> Burlington, MA 01803-0903
>
> ph. 781-442-2679
> fax 781-442-1599
> e-mail karsten.riemer@sun.com