Subject: Re: Comments on TA version 0.9
Melanie's comments are rights on. UML is very important and the only
official
modeling discipline of ebXML. The main challenge here in the BP team is to
define the XML layer (XMLBP). It needs to be semantically compatible with
the BPMM
yet simple enough to allow inputs to that layer other than UML (Scott N,
that essentially
means ebXML production rules). No small task,
but the essence of what Cory C. is working on and needs to come to middle
ground
with the BPMM.
This was explicitly agreed upon in the TP F2F and the information was sent
in
by myself for TA doc describing this but was mostly cut by the so called TA
crash-team,
which I believe was a mistake.
On Scott N's point about not seeing technology for a SME, that was a design
point
of the IBM POC implementation this week in Tokyo, where no technology was
shown
from IBM.
Scott Hinkelman, Senior Software Engineer
XML Industry Enablement
IBM e-business Standards Strategy
512-823-8097 (TL 793-8097) (Cell: 512-940-0519)
srh@us.ibm.com, Fax: 512-838-1074
melanie.mccarthy@gm.com on 11/08/2000 07:06:19 PM
To: ebxml-architecture@lists.ebxml.org
cc:
Subject: Re: Comments on TA version 0.9
Mike
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
UML.
- 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,
completely.
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 ' '"
<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.
Thanks,
Mike
"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
http://www.metronet.com/~rawlins/
Powered by
eList eXpress LLC