Hi All,
I too agree that the document doesn't look like an architecture
document from a software point of view. It needs some re-work and
re-organization to be acceptable and to truely reflect all the hard
work put in.
Regards,
Jaideep Roy
--- Krishna Sankar <[email protected]> wrote:
> Hi all,
>
> I agree with Duane in that the Architecture specification *is*
> important
> and is the foundation. So we do need one at Tokyo. We are software
> professionals - we live and die by architecture.
>
> As there are a lot of e-mails and some concerns, I dedicated this
> Sunday to
> analyze this document (to the best I can). Here are some of my
> comments:
>
> 1. Nagwa & Tim are referring to the version 0.8.71. I do not think
> they are
> referring to an old document. Is this the current version ?
>
> 2. I do have to agree with Nagwa and Tim in the sense that this
> document
> does *not* read like an architecture document. But as I read thru the
> document, it has a lot of information. The team has done a lot of
> work and
> it shows. But the document needs reorganization and more
> material/diagrams
> for a lot of sections.
>
> 3. For example, the first detailed section should be the one which
> describes
> the ebXML architecture - what are the components at a high level, how
> do
> they fit in - some are layers like the business processes run on the
> transport and some are orthogonal like the regrep. Some are
> implementations,
> some are concepts like the BP/CC, .... you get the picture.
>
> For e.g.: Line 210: Talks about seven components. We should define
> these
> and give a brief description in 3.0. Something like "the ebXML
> Architecture
> is based on seven components viz. ..."
>
> 4. We need a lot of diagrams explaining the ebXML Architecture - the
> systems
> overview diagram is over used; it is there everywhere. Even though a
> common
> diagram shows consistency, having only the common diagram does not
> explain
> much. The architecture diagram has to elaborate on this common vision
> with
> more text and diagrams.
>
> 5. Many sections do not have a theme or worst some have multiple
> themes.
> Each section should do only one thing and it should do it well. (I
> have
> heard this many times from my books' editors - sometimes in not so
> flattering words !)
>
> 6. The Section 5 road map should be an Appendix. As it stands now, we
> are
> describing a roadmap without even covering what the components are.
>
> 7. Yes, the document has a regrep-centric feel. It is because a lot
> of the
> sections talk only or talk much more about the regrep. We do need to
> take
> some stuff off and add more from other components point of view.
>
> 8. The use cases are good. But we need to add more. Things like the
> discovery, how to bootstrap a communication, etc are missing. I think
> if we
> look at each components and capture the most important use cases we
> should
> have them all.
>
> Detailed and more elaborate use cases do belong to the respective
> specifications. I am not sure about your point in the case of regrep.
>
> 9. The use cases do need a taxonomy/categorization. Now it looks like
> a list
> of use cases without any relationship.
>
> A diagram showing their relationships would help. The diagram can
> also have
> the 7 major components in the Y axis thus showing where each use case
> fits
> in. (I can draw a strawperson diagram)
>
> 10. The sample files section is good. It needs a new name - may be
> sample
> documents is better or something much more generic. Here we run the
> dichotomy problem. This document needs to be revised every time a new
> sub-document comes out else this section will be outdated.
>
> On second thought, the examples would not make sense without the sub
> documents anyway.
>
> 11. We do need a lot of sequence diagrams explaining the various
> concepts,
> interactions et al. Many of them belong in the use case section.
>
> 12. That brings me to the use case section - do we need one ? It is
> good, in
> the sense that it describes what a minimum system should have. But it
> adds
> pages to the document and complexity.
>
> I think if we judiciously select use cases which amplify the ebXML
> architecture and explain the end-to-end process, develop good
> sequence
> diagrams and elaborate the relationships among the use cases, this
> section
> would do justice.
>
> 13. We do need a section for various "shalls" and assumptions.
>
> Now that I am an accessory ;-), I offer any help needed for all of
> us to
> get a good document out by Tokyo. As Duane said, with out an
> Architecture
> document, we cannot have the other documents.
>
> cheers and have a nice weekend
> ----------------------------------------------------------
> | | Krishna Sankar
> :|: :|: Member of technical Staff
> :|||: :|||: Internet Commerce
> ..:|||||||:..:|||||||:.. (Ph) 408-853-8475
> Cisco Systems Inc [email protected]
> ----------------------------------------------------------
> "Failure is certain if we don't,
> but Success is uncertain even when we do.
> So the choice is Ours, always..."
> ----------------------------------------------------------
>
__________________________________________________
Do You Yahoo!?
Send instant messages & get email alerts with Yahoo! Messenger.
http://im.yahoo.com/
