RE: Thinking about Web Services Architecture

I think the main goal needs to be the specification of a reference
architecture for the purpose of evaluating candidate technologies to be
added to the Web services core technology specifications, and how.  I
suppose that also implies agreement on the core specification set, or at any
rate on the core functionality.  The relationship among the technologies --
how well they fit with and complement each other, is as important as the
technologies themselves.

The objective of a Web services architecture needs agreement, yes,
absolutely.

The core standards have been proposed as enabling additional technologies,
and XML Protocols SOAP V1.2 work includes such a concept.  A starting point
could be to look at other architectures, including ebXML, RosettaNet, and
CORBA.  Also the Open Group has a reference architecture based on one from
DISA (U.S. defense department) that may be helpful as input or precedent.

Eric

-----Original Message-----
From: www-ws-arch-request@w3.org [mailto:www-ws-arch-request@w3.org]On
Behalf Of Christopher Ferris
Sent: Tuesday, February 12, 2002 8:46 AM
To: www-ws-arch@w3.org
Cc: www-ws-arch@w3.org; Carroll, Tom; 'mchugh.m@grainger.com';
'davoren.m@grainger.com'
Subject: 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 Thursday, 14 February 2002 12:56:40 UTC