RE: latest Version

[Stefano POGLIANI <stefano.pogliani@sun.com>]

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. 
> 
> 
>