Re: Thinking about Web Services Architecture

All,

Daniel has made a valiant attempt at synthesizing the goals
and concerns expressed by you on last week's call. I'd like
to see some discussion on these by others in the WG. Do you agree with
these items as a starting point for a characterization of
our high-level goals/objectives? Any suggestions as to which
might be more/less critical than others? Any suggestions
at wordsmithing to improve clarity?

Do you concur with the approach that he has outlined in issue #4?
Should we adopt this approach? Any suggestions as to refinements
on the approach?

Additional thoughts below.

Cheers,

Chris

Austin, Daniel wrote:

<snip/>
> Issue #2: Key goals/issues of members
> In the last teleconference, each of us described in a few words our main
> concerns that we are hoping that this group will address. [5] I've tried to
> distill these down to a few common goals and list them. Surprisingly (or
> not) all of these align pretty well with the mission statement as described
> above. Some of these are also listed in the charter. These are not listed in
> order of priority:
> * interoperability and reduction of divergence among vendors
> *extensibility and modularity to encompass the future evolution of web
> services
> * platform independence with no assumptions regarding communication among
> architecture components
> * simplicity and ease-of-use that does not impose high barriers to entry for
> users of web services
> * security and reliability of web services systems
> * evangelization of web services to larger community 
> * co-ordination with other similar groups both within and outside of W3C
> * coherence and consistency of the overall architecture
> * alignment with the semantic web and the overall existing web architecture
> Hopefully this is a reasonable summation of the key areas of concern, which
> might be easily turned into a set of goals to guide our requirements
> gathering process.


<snip/>


> Issue #4 Requirements gathering - how to?
> Gathering requirements is never a simple task, and given the large number of
> stakeholders in the web services area (as demonstrated by the number of
> members in the WG) even less so. I would suggest that in order to properly
> gather requirements for our (proposed) reference architecture, we should
> first identify the mission, goals, and critical success factors that will
> determine how we define success for the group. This follows the common
> practice of "Business Needs Modeling" or "Critical Success Factor Analysis"
> originally proposed by John Rockart and taught at the Sloane School at MIT.
> This technique is commonly used to determine a set of architectural
> requirements for large software projects [6]. To do this we need to identify
> the "business" (our stakeholders, presumably the members of the WG) and our
> target audience of users. 
> The technique basically involves identifying a mission, 5-6 top-level goals,
> and a hierarchy of critical success factors for reaching those goals. Along
> the way, a list of problems to be solved and a set of assumptions is
> developed. From the list of critical success factors a set of concrete
> requirements can be (more or less) easily identified.


> Issue #5 Editorial Work
> In the previous WG's in which I've participated, a common set of needs has
> come up regarding the editing of documents that we should probably address
> sooner rather than later. 
> First we should decide on our representation language. UML is commonly used
> for describing architectures and I think we should stick with that. UML
> tools are ubiquitous at this point and the associated knowledge for
> understanding and using UML is pretty widespread.
> For editing the document I would suggest that we use XMLSpec [7] This may
> actually be required by W3C. Several WGs use this for their document
> production.


> In terms of the actual output, I can foresee a Requirements document, a
> Technical Architecture document, a Rationale document, and of course the
> inevitable Errata list and a mechanism for making changes and modifications.
> Have I missed anything?


I think the inevitable Issues list:) (unless that's what you meant by
errata list)


> As I said before, this is all my own thinking on these issues and I take
> responsibility for all errors and omissions. The hoped for end result is to
> promote discussion and comment among the WG members. I know this is a long
> email. Thanks for reading!
> Regards,
> D-
> [1] Web Service Architecture Working Group Charter
> http://www.w3.org/2002/01/ws-arch-charter#arch
> [2] Bass, L., Clements, P., and Kazman, R. Software Architecture in
> Practice. Reading, Mass.: Addison Wesley, 1998.
> [6] Bullen, C. and J. Rockart -- A Primer on Critical Success Factors, MIT
> Sloan School of Management Working Paper 1220-81
> [3] Gallagher, Brian P. "using the Architecture Tradeoff Analysis Method to
> Evaluate a Reference Architecture: A Case Study" CMU/SEI-2000-TN-007 June
> 2000
> http://www.sei.cmu.edu/publications/documents/00.reports/00tn007/00tn007.htm
> l#chap02
> [4] Yin, Kevin "A Refrence Architecture for Smart Web Services" Sun
> Developer Connection, August 2001
> http://dcb.sun.com/practices/devnotebook/webserv_refarch.jsp
> [5] Minutes of WSAG meeting 02/06/2002
> http://www.w3.org/2002/ws/arch/2/02/06-minutes
> [6] Bullen, C. and J. Rockart -- A Primer on Critical Success Factors, MIT
> Sloan School of Management Working Paper 1220-81
> [7] Eve Mahler, "Guide to the W3C XML Specification DTD, V2.1" W3C 1998
> http://www.w3.org/XML/1998/06/xmlspec-report-v21.htm
> 
> 
> ***********************************************************************
> Dr. Daniel Austin, Sr. Technical Architect
> austin.d@ic.grainger.com (847) 793 5044
> Visit: http://www.grainger.com
> 
> "The will is expressed through the hands."
> 
> 
> 
>

Received on Tuesday, 12 February 2002 11:46:23 UTC