W3C home > Mailing lists > Public > www-ws-arch@w3.org > February 2002

RE: Thinking about Web Services Architecture

From: Munter, Joel D <joel.d.munter@intel.com>
Date: Wed, 13 Feb 2002 12:08:19 -0800
Message-ID: <ABEEEAB5C59AD51186D900508BB268B90904E86E@fmsmsx102.fm.intel.com>
To: "Austin, Daniel" <Austin.D@ic.grainger.com>
Cc: www-ws-arch@w3.org, "Carroll, Tom" <Carroll.T@ic.grainger.com>, "'mchugh.m@grainger.com'" <mchugh.m@grainger.com>, "'davoren.m@grainger.com'" <davoren.m@grainger.com>

Thanks Daniel.  Some comments are inline tagged as <jdm/>

-----Original Message-----
From: Austin, Daniel [mailto:Austin.D@ic.grainger.com]
Sent: Monday, February 11, 2002 11:56 AM
To: 'w3c-ws-arch@w3.org'
Cc: www-ws-arch@w3.org; Carroll, Tom; 'mchugh.m@grainger.com';
Subject: Thinking about Web Services Architecture


Issue #1: Overall mission and goals

For our purposes I propose
we use the following definition for 'architecture' given in [2]:

"The software architecture of a program or computing system is the structure
or structures of the system, which comprise software components, the
externally visible properties of those components, and the relationships
among them."

<jdm>I agree with this.  In my formative youth I studied Architecture.  The
external visualization (properties, interfaces) might at first appeal to
many but the way the whole thing was put together (i.e., relationships)
completed the picture.<jdm/>


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. 

<jdm>I strongly agree.  I would like to add the following: so that we can
deliver in a timely manner, we must define a reasonable but enforced period
of time in which to capture these mission statements, goals, success
factors, etc.<jdm/>

Issue #5 Editorial Work

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?

<jdm>If we are to produce a Technical Architecture Document, what is the
expected output of the W3C Technical Architecture Working Group?  What is
our working group's relationship to the TAG?</jdm>

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!

<jdm>Thanks for your insights</jdm>

[1] Web Service Architecture Working Group Charter
[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
[4] Yin, Kevin "A Refrence Architecture for Smart Web Services" Sun
Developer Connection, August 2001
[5] Minutes of WSAG meeting 02/06/2002
[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

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 Wednesday, 13 February 2002 15:08:32 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:40:53 UTC