ebxml-architecture message

OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]

Subject: Re: Comments on TA version 0.9

I took away from the discussion a slightly different interpetation of the QR
review.   Following are the notes that I took during that discussion:

v    What is the role of modeling/ Choice of UML
v    Resolution:  If you choose to formally model within ebXML -  you must use
             -  BUT the Technical Architecture MUST BE ABLE TO SUPPORT OTHER
              MODELING METHODOLOGIES exchanged with external sources
             - This will allow for gradual adoption, with loosely coupled
             compliant components
             - The presentation of the TA document obscures the ability to
             support gradual adoption of ebXML.

   Therefore, the BP documents should prescribe a single modeling approach, but
   the technical architecture has to support multiple modeling languages, as it
   has a requirement able to accommodate a gradual adoption of ebXML.

Mark participated in the meeting and I must say represented the requirements
 document well,  insuring that we embrased this agreed upon specification,

regards, Melanie

Mike Rawlins <rawlins@metronet.com> on 11/07/2000 11:19:38 AM

Please respond to rawlins@metronet.com

To:   "''ebxml-architecture@lists.ebxml.org ' '"
cc:    (bcc: Melanie McCarthy/US/GM/GMC)
Subject:  Re: Comments on TA version 0.9

Thanks for the quick note, Scott, but your response raises more questions than
answers for the majority of us on this list who are not in Tokyo.   I would
appreciate getting an answer when you have time.  Specifically, please elaborate
on not meeting the requirements to pick "a single modeling technique and
methodology, and adopting existing specifications".

I appreciate the need to come to a consensus regarding the TA spec - and that
will probably require several folks resigning themselves to agreeing to
disagree.   However, I was not trying to debate issues when I raised my
questions.  If you look at the questions again, I am only asking to understand
the basis of your vision and assertions.  Please respond when convenient.



"Nieman, Scott" wrote:

> sorry Mike, but I don't plan to respond to this today.  I was informed that
> in the TA/QRT meeting there was no consensus, except that continuing this
> debate would risk delivering the "basic" infrastructure of ebXML.  This will
> have to be continued in phase 2.
> The requirements to pick "a single modeling technique and methodology, and
> adopting existing specifications" will not be met for this phase.
> Scott
> -----Original Message-----
> From: Mike Rawlins
> To: 'ebxml-architecture@lists.ebxml.org '
> Sent: 11/6/00 9:39 AM
> Subject: Re: Comments on TA version 0.9
> Comments and questions below:
> "Nieman, Scott" wrote:
> > I find it terrifying to hear that some people do not know the real
> > problems....especially at this stage of this initiative.
> >
> > Have you ever heard of a "plug-in" or maybe an "adapter"?  Have you
> ever
> > been prompted by your browser that you need to install one of these
> "things"
> > to view the most updated version of Shockwave?
> >
> > PERHAPS this is the architecture?
> >
> > Why?  because of the REAL problems!!
> >
> > 1) the REAL SME does not give a hoot about technology and it should be
> > ABSOLUTELY transparent to them.  Looking at XML versus looking at CODE
> is
> > still LOOKING at technology...make it invisible to them or we fail.
> > 2) there WILL BE YAP (yet another protocol) in a few more years...5,
> 10,
> > 15...whatever...it WILL happen.  (or should I say YAHP (yet another
> "hype"
> > protocol...EDI -->ASN.1--->XML????)
> I may be mistaken, but I think most of us feel that this is a fairly
> obvious,
> non-controversersial point.
> >
> >
> > SOOOOOO....the solution scenario...for those who don't get it...
> >
> > trading partner A uses QuickBooks and wants to buy something...looks
> into a
> > registry and finds trading partner B has a suitable product.  trading
> > partner A and trading partner B have the ebXML messaging service
> installed.
> > however, based on trading partner A's profile and trading partner B's
> > profile, trading partner A is prompted with a dialog box(message)
> because
> > the tpp / tpa process states that for the specific collaborative
> business
> > process trading partner A needs to install an adapter to talk to
> trading
> > partner B.  download the adapter from a ebxml reg-rep with software
> > components in it and wa-la!  trading partner b gets a PO.
> Scott, thanks for spelling out how you think this is going to work.  Now
> my
> questions:
> Even if we can normalize the data requirements through better modeling
> than we
> have with traditional EDI, there may still be *many* variations due to
> real
> differences in business processes.  Do you agree with this assessment?
> What is your order of magnitude estimate of the number of different
> business
> process variations, and hence, the number of different plug-ins that
> might be
> needed for QuickBooks?
> Who is going to provide these adapters that A needs to make QuickBooks
> talk to
> B?    Do you expect Intuit to supply them?   Or, do you expect someone
> else to?
> --
> Michael C. Rawlins, Rawlins EC Consulting
> http://www.metronet.com/~rawlins/

Michael C. Rawlins, Rawlins EC Consulting

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
Search: Match: Sort by:
Words: | Help

Powered by eList eXpress LLC