RE: latest Version

["Nieman, Scott" <Scott.Nieman@NorstanConsulting.com>]

>>The RegRep only knows about the things in the XML format.

Where is this coming from?  reg-rep can store ANYTHING as long as it is
classified.  We call them "objects" for that very reason and for lack of a
better term.  An registered object can be classified in a way that actors
will know it is in XML syntax.  the classification scheme ITSELF is a
registered object.

>> I disagree with the use of UML in this context, which seems to be
prescriptive for the use of ebXML.

Is this a Sun position statement?  Or a Stefano position statement?  It is
NOT AT ALL prescriptive for the SME (ONE of the ebXML customers), but it is
simply a GOOD IDEA to keep the business process information in a protocol
and technology neutral viewpoint.  XML is not a neutral viewpoint, but
completely in the FSV.   I feel the architecture document does a good job in
showing how in concept a model can be recast into XML syntax. 

To think a mom and pop shop (small company, say 4-5 people) will spend one
minute describing their business process in ANY TOOL is a joke...they are
more likely to spend time finding one from a LIST that CLOSELY MATCHES their
process and using it.   How it got into that list is likely through software
companies, standards organizations, industry groups and so forth, and this
is where the UML comes into play.  All the SME wants is to see the process
as a simple visual flowchart (e.g.; UML Activity diagram), which to me is
only a matter of rendering.  Put an XML schema in front of them and their
eyes will glaze over.  

>>By reading this, one would understand that ebXML is to continue the
open-EDI effort or, worst, to make it finally succesful >>!  I mean, if
ideas from Open-EDI can be reused, they should be presented "as ebXML ideas"
and, then, a footnote would 
>>reference the literature on open-EDI just as a referenced source.

Worst? My philosophy on technology is that whatever is "new" is actually
"old" (or an adaptation of "old").  Open-edi concepts are over 10 years old,
and are based on ONE main issue:  why is it so hard to implement EDI??
Technologists and the business people ALWAYS have had a disconnect from the
business requirements and actual implementation.  Modeling is viewed as the
way to bridge this gap.  Open-edi was ALWAYS about auto-discovery and
auto-configuration of trading partners, and most importantly ensuring a
future-proof way to represent and understand a business model.  To eliminate
Open-edi as an origin of the architecture is a big mistake.  But to simplify
the text, I am all for it.  

btw, I hope we don't have to ask the same question again 10 years from now;
why is it so hard to implement ebXML??  Just think, ten years from now we'll
all be talking/debating about the "new technology craze" as big as XML is
today. I just hope that we won't be debating these SAME business modeling
issues again.  I hope we can someday get beyond this discussion.

Lots of hope for ebXML,

Scott Nieman
Solutions Director/ e-Business Integration
Norstan Consulting

  



-----Original Message-----
From: Stefano POGLIANI [mailto:stefano.pogliani@sun.com]
Sent: Monday, October 16, 2000 2:58 PM
To: Brian Eisenberg
Cc: ebXML Architecture
Subject: RE: latest Version


Below are my detailed comments on the V0.8.72i version of the TA document.

Apologies if the short time for review did not help me in reading some parts
with more attention. 
----------------------------------------------------------------------------
---

Generally speaking, I think that the document is getting better but there
are some important parts that should, IMHO, be worked out.

One thing that seems missing completely is some reference/idea on the
RunTime architecture, i.e. some general considerations on how an ebXML
runtime solution would work and function in terms of traceability, logging,
transactionality. The role of the Business Service Interface should be
highlighted in a more significant way since it is the real piece of code
that will make a solution an "ebXML solution". 

Best regards

/Stefano

<Line 155>
	I disagree on the explicit mention of OO. This has nothing to do
with ebXML.
	ebXML can enable COBOL legacies to communicate without implying that
people
	know about OO, even if people would use some digested form of OO
through the 
	modelling techniques... 
	ebXML is not about OO and should not imply it. After all, a customer
would 
	not have to use all of ebXML specs to implement an ebXML solution !
<\Line 155>

<Line 158 to 161>
	I disagree with the use of UML in this context, which seems to be
prescriptive 
	for the use of ebXML. Customers can use ebXML solutions without
knowing
	anything of UML (same as for OO before)!
	As well, I suggest to avoid the last sentence of the paragraph. The
idea is not
	to substitue EDI with "Objects over BPs", but to facilitate the
electronic
	exchanges with XML. Customers would not care that there is a flow of
Objects
	instead than a flow of data...
	What matters for customers is that their business trx flows in a
better way 
	and in a more economical way. Why ebXML accomplishes this is the
goal of this
	section.
<\Line 158 to 161>

<Line 163 to 170>
	I would remove. This looks like methodology to me, not Architecture.
<\Line 163 to 170>

<Line 170 to 172>
	We should explain to SMEs why they should consider ebXML and how
ebXML fits 
	this picture. Just re-stating the main objective of what the specs
(and the
	architecture in particular) should do, is not necessary.
<\Line 170 to 172>

<Line 188>
	I never saw "Dynamic" discovery as a requirement for ebXML. In any
case, given
	the new announcements in the market (see UDDI) I would avoid the
term "dynamic"
	or, if used, I would clearly explain:
		- what is meant by
		- how the specs address it
<\Line 188>

<Line 208 to 252>
	I would remove all explanations of the picture since the picture is
clear 
	enough! The explanations are too long and too detailed and they
distract,
	IMHO, the reader.
<\Line 208 to 252>

<Line 269 to 270>
	The TPA (or CPA as is now called) is mainly derived by the BP.
	It may also "substitute" the BP in very specific situations and for
very simple
	exchanges.
	I would explicitely state this concept, since it is in the direction
of 
	showing that ebXML could also be used in small pieces.
<\Line 269 to 270>

<Line 277 to 286>
	I would express the scenarios in a more generic way. This bulleted
list would 
	be useful if you are going to reference each bullet in the
surrounding text. 
<\Line 277 to 286>

<Line 288 to 343>
	I would remove the whole. It does not add anything to the
	picture. By reading this, one would understand that ebXML is to
continue the
	open-EDI effort or, worst, to make it finally succesful !
	The goal is not to understand what "Open-EDI" is. I mean, if ideas
from 
	Open-EDI can be reused, they should be presented "as ebXML ideas"
and, then, 
	a footnote would reference the literature on open-EDI just as a
referenced 
	source.
<\Line 288 to 343>

<Line 382>
	What is the Lexicon ? Never saw it before in any specs.
<\Line 382>

<Line 422 - Figure 4>
	What are the "Business Document"s ? And why are they related to the
Roles?
<\Line 422 - Figure 4>

<Line 433 to 435>
	The RegRep only knows about the things in the XML format. The fact
that some 
	of them may be derived (or are conceptually derived) from an UML 
	representation should be better explained (i.e. saying that UML
grants that 
	the things are cleaner...).
	Otherwise one does not understand why some concepts are thought in
UML and/or
	why they should be translated in XML.
<\Line 433 to 435>

<Line 437 to 464>
	This is design, IMHO, and is something pertinent to the RegRep
specs, not to 
	the Architecture. Here what should be said, IMHO, is that there
should be
	a way to identify some basic information in an unique way and that
this will
	be formalized in the RegRep specs. The discussion on UID is
distracting the
	reader from the main concept that is developed.
<\Line 437 to 464>

<Line 472 to 475>
	Well, the Single Point of failure issue is much more sensitive in
the RunTime
	that in the RegRep. Of course the RegRep should be up and running
"always"
	(as any piece of code, after all!). 
	But if it is not up for 2 hours, it would have a different effect
than the
	Runtime failing !
	So, I would remove this reference!
<\Line 472 to 475>

<Line 477 to 482>
	I do not understand the point. The Runtime Software will not be
built using 
	the BP NOR (even) the Information Model. The driver of the Runtime
is the 
	TPA !
	I do not know if, in addition, the "dynamic" configurability of the
runtime is
	something that would be really stated here since it adds
expectations that
	may not be implemented.
<\Line 477 to 482>

<Line 484 to 487>
	This step preceeds the previous one, in the sense that two partners
have first
	to agree on a given BP, have to exchange their own TPPs and, from
those, 
	build a TPA. The TPA will, then, drive the implementation of the
runtime
	software.
<\Line 484 to 487>

<Line 519 to 521>
	"(stored in its TPP)" : I do not understand who "its" refers to.
	The Trading PArtner does not submit ITS OWN BP information. What is 
	"its own BP information" ? I do not understand this.
<\Line 519 to 521>

<Line 531 to 537>
	I do not understand. If a Partner has already implemented the
Business Service
	Interface, it has already implemented a "role" in a TPA. Why should
it, 
	AT THIS POINT, ask somebody else's TPP ? To do what? It may ask to
know which 	other sites implement the "other roles" in the current TPA
in order to start
	working with them...
	And why should CoreComponents (or Business Objects) be modified at
this stage? 
	Wouldn't it be like modifying a DB schema AFTER you have compiled
the program 
	which uses it ?
<\Line 531 to 537>

<Line 542 to 544>
	I do not agree that the RunTime is the least complex part. 
	In addition I interpret the sentence as if its small complexity
depends
	on the fact that it does not use the RegRep...
<\Line 542 to 544>

<Chapter 20>
	I did not look at it in details. It seems out of proportion on
respect to the
	rest of the book. The RegRep is a part of the overall solution, but
is actually
	an helper part which is there to help people properly build the
runtime.
<\Chapter 20>

<Line 1070 in Figure 17>
	TPA enforcement IS NOT in the Messaging Layer but in the Business
Service 
	Interface.
<\Line 1070 in Figure 17>



> -----Original Message-----

> From: Brian Eisenberg [mailto:BrianE@DataChannel.com]
> Sent: Saturday, October 14, 2000 8:07 AM
> To: 'ebxml-architecture@lists.ebxml.org '
> Cc: 'Klaus-Dieter Naujok '; 'Bruce Peat '; 'Jeff Suttor '; 'Duane
> Nickull '; 'David Webber '
> Subject: RE: latest Version
> 
> 
> 
> To all ebXML TA folks:
> 
> After a long week of nearly around the clock work, we have completely
> revised the Technical Architecture specification. We worked through all of
> the comments from the Quality Review team and have completely reworked the
> ENTIRE TA spec. Aside from the Messaging Services section, this version
> (0.8.72i) is essentially a new architecture document. That said, given the
> extent of change from the previous version, no change log is included. 
> 
> Here is the plan of action: 
> 
> 1. Please review the specification (TA team only) over the weekend. Please
> post all comments to the TA discussion list. Please focus on the 
> content of
> the document, not the grammar and formatting.
> 
> 2. Barring any show-stopping issues, our plan is to do a final revision on
> Monday before submitting it to the Quality Review team (by end of day
> Monday). 
> 
> 3. If approved by the Quality Review team (5 days after 
> submitting we should
> hear back from them), we will post to the entire ebXML community for a
> comment and review period. 
> 
> 4. After collecting comments from the review period leading up to 
> Tokyo, we
> (the TA team) will devote most of the Tokyo meeting incorporating 
> comments,
> and also having our liaisons work with each of the project teams to get
> feedback on each of the respective major sections in the TA spec. 
> 
> 5. Drink lots of sake :-)
> 
> Before reviewing the specification, please keep the following in mind:
> 
> 1. The glossary needs to be harmonized with this latest spec. This means
> that the "bold italic" convention for glossary terms has NOT yet been
> applied to this version of the TA spec. This task will be completed before
> submission to the Quality Review team. 
> 
> 2. If your name is not on the list of participants, please email me at:
> briane@datachannel.com with your name and company info. We did our best to
> include everyone, but may have inadvertently overlooked a few TA team
> participants. Please accept our apologies if we did so. 
> 
> The specification is attached as a zipped Word doc named:
> ebXML_TA_v0.8.72i.zip (620 K). If anyone has problems opening the .ZIP
> archive, please send email to briane@datachannel.com and I will directly
> email you a copy of the word file (1.9 MB). 
> 
> I'd like to personally thank the following people for their hard 
> work during
> the past week: Klaus-Dieter Naujok, David RR Webber, Duane Nickull, Jeff
> Sutor, Chris Ferris, Karsten Riemer, and Bruce Peat.
> 
> Best Regards, 
> 
> --Brian
> 
> Brian Eisenberg
> Standards & Technology Liaison
> DataChannel, Inc. 
> 
> 
>