Re: TA report for our con call tomorrow

[nagwa <nagwa.abdelghfour@sun.com>]

Duane,

Thanks for the feed back about the report, but I just want to let you know
that this report was targeting our QR group discussion only.
My main reason I think we should suggest to disapprove this document is,  it
does not satisfy the requirements for any Technical Architecture Design
Document, which some of the projects leads point them out during the long
meeting we had in San Jose, this document more as a requirement document than
a TA Design document

Thanks,
Nagwa

duane wrote:

> Nagwa:
>
> I apologize in advance for this long email.  Thank you for the
> comments.
>
> In general:  I feel that the TA doc does contain some shortcomings
> however, for most of these,  I think we should send it to the plenary
> for a wider cross section of comments.  This isn't the final version
> going out for a final vote.  It is a first draft for the first comment
> period.  Accordingly, we feel it is necessary to solicit comments from
> the plenary.
>
> Some rebuttal to your comments (in line):
>
> > Part 1.
> > =======
> > Why we shouldn't approve this document for public review:
> > - lacks a complete Architecture where each of the parts are clearly
> >   defined and put in context
>
> Each part contains an overview and a section labelled "Functional
> Requirements".  In each of those we have attempted to define what the
> components must facilitate without going too deep and stepping on the
> toes of the Project team repsonsible for that area. Can you please
> provide specific examples of where you se it not meeting your teams'
> definition of "clearly defined" and "put in context"
>
> > - lacks HIGH-LEVEL Use Cases for the operability of ebXML compliant
> >   applications.
>
> We were told that we should not be defining what an ebXML compliant
> application should do.  If this is wrong,  can you please clarify this
> with the STC.  I am happy to begin work on "Building an ebXML compliant
> application" however,  we viewed this as something best done after all
> the specs have been approved due to dependancies on those specs.
>
> > - Lacks "scoping" the vertical efforts: what the BP should define and
> >   why? How the TPA interacts with the BP and the TRP ? Etc.
> We gave an example of a BP document and described its' functionality.
> Again,  please give us specific feedback on what you forsee as a
> shortcoming.
>
> > - It over-steps its bounds by attempting to define conformance testing
> >   which is not part of Architecture.
> This was discussed by the STC.  I think we need to define it here. If
> not here - where?  I am not attached to the outcome of that
> conversation.   If it is decided that someone else whould do this - so
> be it.  THis may be an issue better left to the plenary and the STC.
>
> > - Incomplete and contains several "... to be discussed later ...", "...
> >   TBD ...", "... see section zzzz ..."
> THe TRP and Reg Rep spec also contained these.   We want to solicit
> comments from the plenary.  Some are also typos but hardly warrant the
> spec from not being circulated.
>
> > - It is too focused on RegRep at the expense of other issues. Even with
> >   RegRep, is describes one solution instead of prescribing interfaces.
> Don't the use cases describe the functionality neede from the
> interfaces.  Our goal was not to do the interface work of all the
> components,  jsut describe what must be facilitated by those specs.  If
> our scope is going to be changed to address this,  so be it.  PLease let
> us know your decision.
>
> a
> > - internal inconsistencies
> >         - 3.1 "seven major component specifications"
> >         - 5.0 "six major component specifications"
> Noted - thanks ;-)
>
> > - conformance testing is not part of Architecture
> >         - 5.0(1) "a set of conformance tests"
> >         - 6.1 "series of Conformant tests"
> >         - "12.0 ebXML Conformance and Testing"
> Refer to comment above.
>
> > - diagrams hard to understand
> >         - Figure 1.0
> I will personally take respnsibility for this.  We do intend to clean up
> the existing diagrams and add more where appropriate.
>
> > - don't mention vendors
> >         - 6.3 "Biztalk"
> Point well taken.   Will address.
>
> > - document not complete
> >         - 6.3 "Note: SME scenarios to be discussed later."
> >         - 10.8.2 "SME's may not be using this model. SME integration
> >           will be discussed later."
> >         - 11.2 "The concrete realization of this abstract interface
> >           are yet TBD"
> >         - 11.2 "see section zzz for TPA"
> >         - 11.5(d) "d)defined in sections X.Y ? of this document"
>
> We wish to solicit input from the plenary.  Again - if this was the
> final spec - yes it should be with held pending the finishing of those
> sections.  We have lots of work to do but feel it is better done in the
> eyes of the plenary than by us behind closed doors.
>
> >
> > It is also too long. should be a shorter doc with a few simple
> > figures.  We should be showing high level architecture.
>
> This comment seems to be in constrast to your first two comments.
> Please provide specific examples where you see this as too detailed |
> too short.
>
>  >   a.. repeats the obvious (restates the charters of each group,
> >       instead than asserting a mission for each of them)
>
> The first section does this to provide context to readers of the
> document.  We state that the audience includes "ebXML Project Teams".
> We wanted to rpovide a high level requirement for each of those before
> stating the "Functional Requirements" for each team.
>
> >   b.. too much focused on RegRep and, in addition, this focus tends
> >       to describe a solution instead than prescribing interfaces
> >        /usage-scenarios.
>
> Noted.
>
> >   c.. lacks a complete architecture where each of the parts (Registry,
> >       Repository, BP, TPP, TPA, CC etc) are clearly DEFINED and put in
> >        context
>
> The first diagram provides this but the level of detail was kept very
> abstract.  We can work on this for the next revision.
>
> >   d.. lacks HIGH-LEVEL Use Cases for the operability of ebXML compliant
> >       applications.
> We have included vvery detailed use case scenarios in appendix "A".
> They are very specific.  We had more abstract use cases in the previous
> version however, we received a lot of comments that they were not
> specific enough.  YOu may be out on your own in this opinion.  THis may
> be best left to the plenary to decide.
>
> >   e.. lacks the "User Point of View", i.e. lacks presenting the
> >       Architecture in a way that a User can find its own business case
> We haven;t defined user interfaces but can do if this is percieved as a
> shortcoming.  We purposely decided to refrain from describing an "ebXML
> application".  If you and others feel we should do this,  we will do it
> but there are dependancies on the other specs for this.
>
> Can I suggest that the architecture team, after finishing the TA spec,
> maybe can focus its' energy on a "Building an ebXML compliant
> Application" white paper?  That may be a better route to go than trying
> to define a concrete User Interface when there is so much other work to
> be done (expecially within BPM - modeling issues).
>
> >   f.. Lacks the "vendors Point of View", i.e. lacks presenting the
> >       Architecture in a way that a Vendor can find the possibility to
> >       define its own tool implementation
> See comment above.
>
> >   g.. Lacks a "Roadmap", i.e. lacks presenting a path from how a Company
> >       defines a basic interaction to how the same Company can
> >       participate/establish a broader interaction (supply chain,
> >       market place, etc)
> "Defining a basic Interaction" is the work of BPM.  We have defined what
> they must facilitate in their work but we are leaving the work to that
> group and feel they have made some great progress lately.
>
> >   h.. Lacks "scoping" the vertical efforts: what the BP should define
> > and
> >       why?
> Please clarify - I don't understand this comment.
>
>  How the TPA interacts with the BP and the TRP ? etc.
>
> I can place some stuff from the PPT from San Jose into the TA spec but
> it will make it longer.
>
> >   i.. Lacks a "global vision" of "how this is used in real life" !
> THis is more of an implementation issue.  Please be more specific.
>
> >   I mean, in real life things like accountability of a business process
> > are
> > fundamental, no one who seriously engage in something without this.
>
> I totally agree but is it our teams' job to define this or BPM.
> Whatever is decided, we are open to it and will comply.
>
>  > this is not in someway "architected", it will be implemented by the
> tool
> >
> > vendors in inconsistent ways...
> WE have stated that the architecture consists of the seven ( I may be
> wrong here) specification in unison.  This comment is also one of my
> greatest concerns.  If we give the specs to ten different vendors,  they
> should build ten version of the same product,  not ten different
> products.  I don't know if TA can define an architecture for an ebXML
> application at this point.  We really need to consider the "Building an
> ebXML compliant Application" white paper approach.  THis may be
> necessary.  UDDI made the "Programmers' API specification" which is a
> very good idea. One of our goals is that we come up with an
> implementable solution.  The question should be "Is the TA spec the
> place to define this"?
>
> >  It is too focused on
> > RegRep at the expense of other issues. Even with RegRep, is describes
> > one solution instead of prescribing interfaces.
> I would like to get comments from the REg Rep team to validate your
> opinion.  If they feel we have overstepped our boundaries,  then we will
> scale it back.  IMHO - everything that is in the spec was absolutely
> necessary in respect to Reg Rep.  We pared it down quite a bit from
> previous versions.   Let's get it to the plenary for a wider cross
> section of comments.
> >
> > The TA document is incomplete and contains several "... to be
> > discussed later ...", "... TBD ...", "... see section zzzz ..."  It
> > lacks a complete Architecture where each of the parts are clearly
> > defined and put in context.  It is also too long. It should be a
> > shorter document with a few simple figures.  It should be showing high
> > level architecture.  It should focus on just showing the components,
> > how they fit together and what they expose at their edges.
>
> I don't understand this comment.  It seems in complete contradiction to
> your earlier comment that it doesn't of into enough details.
>
> THose are two mutually exlcusive comments.  Can you please be more
> specific.
>
> Thank you for the comments.
>
> Duane Nickull