posted for stefano.pogliani@france.sun.com.: response to TA doc

[Jeff Suttor <Jeff.Suttor@eng.sun.com>]

posted for stefano.pogliani@france.sun.com.

---

• From: "Stefano POGLIANI" <stefano.pogliani@france.sun.com>
• To: "Suttor Jeff" <Jeff.Suttor@eng.sun.com>
• Date: Wed, 4 Oct 2000 10:19:57 +0200

Jeff,

	I received back this post to the TA list saying I am NOT Authorized.
Today I am travlling and tomorrow morning in a meeting. Would you mind, pls,
 to help me :

	1.	Ensure I am registered to the list.
		I do not understand. I receive the TA mails but I am not authorized
		to answer....

	2.	in the meantime, could you please forwad the attached mail as my
		answer to the public mail from Brian ?

Thanks a lot indeed. Ciao
/Stefano

> -----Original Message-----
> From: ebxml-architecture-help@lists.ebxml.org
> [mailto:ebxml-architecture-help@lists.ebxml.org] 
> Sent: Wednesday, October 04, 2000 10:35 AM
> To: stefano.pogliani@france.sun.com
> Subject: Not authorized to submit to elist: ebxml-architecture
> 
> 
> Your message to the elist is being returned to you because you are not
> authorized to submit messages to the elist.  There are only two possible
> reasons for this.
> 
> 1. The elist is restricted and very few people are permitted to submit
>    messages.  If you think you are one of those very few people replying
>    to this message will put you in touch with a person with whom you may
>    discuss the issue.
> 
> 2. The elist only permits subscribers to submit messages to it.  The
>    test of whether or not you are a subscriber is a comparison of your
>    envelope from header with the email addresses of the list of
>    subscribers.  The envelope from header is the value specified by your
>    email system as the origin of the message.  This is different than
>    the message from header which is specified by your email client and
>    what you see whenever you display an email message.
> 
>    If you believe you are subscribed to this elist and should be able to
>    submit messages to it, replying to this message will put you in touch
>    with a person with whom you may discuss the issue.
> 
> 

---

• From: "Stefano POGLIANI" <stefano.pogliani@france.sun.com>
• To: "Brian Eisenberg" <BrianE@DataChannel.com>,<ebxml-architecture@lists.ebxml.org>
• Date: Wed, 4 Oct 2000 10:08:41 +0200

Brian,
	I read the Word document you forwarded and, as a general feedback, I think it is clear and it summarises the "behaviour" of the TRP. But I would like to add the following comments:

1.	I think that the "positioning" of the messaging layer within the TA is still
	missing. In some way I would expect in the architecture document a picture
	where the TRP is highlighted (i.e. the same picture for each "summary" and, 
	in each summary's chapter, the relevant topic is highlihghted)

2.	It is STILL a "technical summary". One of the things I would like to work for
	the TA document is trying to link the Architecture to "Real Life" patterns.
	Our "customers" (both final adopters of ebXML-compliant products and ISVs
	implementing ebXML-compliant solutions) will be interested in mapping their
	needs to the Architecture, something like "market-place", "supply-chain",
	"procurement", "extended integration"... When dealing with the Architecture,
	they would "less care" of technical details (IMO) and would point to things
	like "how do I map my supply-chain into that?"
	For this reason, I would see some reference in your paper to the popular patterns
	(i.e. "async communication, granted by ebXML TRP, can be used in situations like
	....)

3.	I personally do not agree too much with the picture 11.2
	According to my interpretation of the picture, the middle vertical blue box (Messaging
	Service) is responsible for too many things that, actually, I do not think are 
	in the TRP specs. Specifically, the TPA. This is the domain of the BSI (Business Service
	Interface) which stands between the legacy application and the ebXML-world.
	Something like this stack 

			Legacy Application

			Business Service Interface

			Messaging Service Interface

			low-level protocols (HTTP, FTP etc)

	The run-time "intelligence" is in the BSI which happens to be on a per-legacy/per-TPA
	mode, instead than inside the Messaging Service).

So, all in all, I think that the document as it is now, is a good starting point but there would need
some further refinement.

As a general comment to the following list of open points, I think that the TA document should:
	1.	explain WHAT the system (i.e. and ebXML-compliant solution) will do
	2.	explain the major startegical decisions in terms of technology and functionalities
	3.	define the perimeter inside which the system will work
In this sense I think that HIGH LEVEL Scenarios taken from the real-life will be welcome. I think that the users of ebXML complaint solutions will be happy to see how they could implement a supply-chain using ebXML (of course, if supply-chain is something inside the perimeter...) or a market-place or...As well, ISVs will need to understand the perimeter that they are allowed to move inside.

I think it will be important to explain, in the TA, things like:
	- which is the starting point? Is the BP, is the TP, is the TRP ...
	- which is the relationship between BP, TP and TRP ? Are they all "always" important ?
	- How do I use the RegRep and CC to build my Message Definition ?
	- How do I "manage" a RegRep ?
	- How do I administer an ebXML solution ?
	- How do I enable my legacy to the ebXML-world ?

Best regards

/Stefano
> 
> 1. Introduction and System Overview sections (what needs to change, who to do it)
> 
> 2. Section 4.4 Specifications Roadmap - do we really need this section???
> 
> 3. Section 6 - Architecture Overview - what can we get rid of, what needs to
> change, who to do it.
> 
> 4. Section 7 - Trading Partners - need to extract requirements and 
> implementation details, get feedback from TP team on what to include in this
> section. 
> 
> 5. Section 8 - Business Process - need to extract requirements and
> implementation details(what else needs to change, who to do it) - need
> liaison to help coordinate w/ BP/CC sub-teams to get alignment
> 
> 6. Section 9 - Core Component - need to extract requirements and
> implementation details (what else needs to change, who to do it) - need
> liaison to help coordinate w/ BP/CC sub-teams to get alignment
> 
> 7. Section 10 - RegReg - Jeff to deliver revised RegRep section - (what else
> needs to change, who to do it) - need to get Duane/Jeff working with RegRep
> team to get alignment.
> 
> 8. Section 11 - Messaging Services - review attached doc, get feedback from
> TRP team, revise as needed. 
> 
> 9. Section 12 - Conformance and Testing - discuss comments from QR and
> others regarding scope issues - are we expected to discuss conformance in
> TA???
> 
> 10. Discuss whether or not we want to include high-level use case scenarios
> in the spec. For low-level use case scenarios that already exist, hand them
> over to respective project teams.
> 

---

---