Re: TA issues - was: [Revised Messaging Services Section for TA spec]

[Christopher Ferris <chris.ferris@east.sun.com>]

Nikola/All,

Please see below.

Cheers,

Chris

Nikola Stojanovic wrote:
> 
> <Brian>
> We still need to discuss how to rework the Intro (section 3.0) and System
> Overview (section 4.3) sections. This is the most important part of the
> document and really needs to clearly articulate the ebXML architecture at
> the highest degree of abstraction. I think we need to revisit the
> architectural diagram and possibly revise it to better reflect the ebXML
> landscape.
> </Brian>
> 
> I think that "The View" that we have as figure 1.0 is appropriate and serves
> the right purpose. As any high-level abstraction it only conveys some
> aspects of the whole system. I would certainly leave it as it is and try to
> put some other "System Views" in addition to this one.

I think that it needs to be reworked on a number of levels. Firstly, it is
(IMHO) quite distracting. I would prefer that it be toned down a bit.
I don't think that the working groups need to be represented in the figure.
I think that it should focus on the components which they are defining
and their interface points/interactions.

Secondly, it is incomplete and inaccurate (again, IMHO). 
	- the ebXML BP metamodel does NOT define the XML transform rules.
	Certainly, the transform rules would be applied *to* a model
	described in terms of the metamodel. The metamodel is used to
	*describe* a business process. 
	- the BP provides *context* for the purpose of composing
	a "Business Object" from the library of CC (I would prefer the 
	term Message). BP doesn't *use* the BO library.
	- TP seems to have been simply added on without careful thought
	(IMHO). I believe that TP provides the *glue* which binds the
	various components together. Certainly, not all of the TP relationships
	have been incorporated into the figure.

As far as I'm concerned, figure 1.0 is NOT an architecture diagram by any
stretch of one's imagination.

Bottom line, I fully concur with Brian that section 3.0 and the
diagram in figure 1.0 need some serious attention!

> 
> <Brian>
> 10. Discuss whether or not we want to include high-level use case scenarios
> in the spec.
> </Brian>
> 
> I hope we can agree that we need more high-level "Examples of System
> Usages". Speaking of which, have we lost one of those? See: <Anders>The
> first is an attempt to describe the ebXML vision as simple as
> possible</Anders>? and attachment in
> http://lists.ebxml.org/archives/ebxml-architecture/200003/msg00022.html
> 
> If we did (I cannot find it in the current doc), I'd suggest that we put it
> back.
> 
> Also, to add to the list of issues for our next con call, I suggest that we
> follow-up on:
> 
> 1) Glossary
> 2) "Architecture Issues list" that we've discussed last time:
> http://lists.ebxml.org/archives/ebxml-architecture/200009/doc00004.doc
> 
> Regards,
> Nikola

-- 
    _/_/_/_/ _/    _/ _/    _/ Christopher Ferris - Enterprise Architect
   _/       _/    _/ _/_/  _/  Phone: 781-442-3063 or x23063
  _/_/_/_/ _/    _/ _/ _/ _/   Email: chris.ferris@East.Sun.COM
       _/ _/    _/ _/  _/_/    Sun Microsystems,  Mailstop: UBUR03-313
_/_/_/_/  _/_/_/  _/    _/     1 Network Drive Burlington, MA 01803-0903