Thinking about Web Services Architecture

Greetings,

     I've spent some time since our last teleconference thinking about this
group's mission and goals. Section 1 of our charter [1] describes our
purposes at a very high level, but is (purposely I think) lacking in
specifics. In this email I'd like to set forth some of the issues that I've
identified. Clearly this is my own thinking on the subject rather than that
of the group; its purpose is to begin the discussion among ourselves on the
WSAG mailing list.

Issue #1: Overall mission and goals
The charter [1] describes in section 1.1 the scope and nature of the
"architecture document" that we are tasked with producing. Despite the
rather loose description here, it seems to me that what we are tasked with
is producing is a standard reference architecture for web services. A
reference architecture (and architecture itself within the computer
industry) has no universally accepted definition. 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."
On this basis, a reference architecture definition might be [3]: 
"A reference architecture is the generalized architecture of several end
systems that share one or more common domains. The reference architecture
defines the infrastructure common to the end systems and the interfaces of
components that will be included in the end systems. The reference
architecture is then instantiated to create a software architecture of a
specific system. The definition of the reference architecture facilitates
deriving and extending new software architectures for classes of systems. A
reference architecture, therefore, plays a dual role with regard to specific
target software architectures. First, it generalizes and extracts common
functions and configurations. Second, it provides a base for instantiating
target systems that use that common base more reliably and cost
effectively."
Based on the charter I think that this is pretty much what we are tasked
with doing, the charter simply frames the task in terms of the actual
deliverable(s), that is, the documents that describe the reference
architecture itself. This clarifies our overall mission a great deal; we can
now see what it is that we want to create and possibly begin to see how to
go about it. I'd like to propose that this group's mission statement might
be something like: "To create a standard reference architecture for web
services". 
Issue 1a - an example reference architecture for web services
Kevin Yin of Sun Microsystems has described a reference architecture for web
services already. I have some misgivings and misdoubts about this
presentation, but it does provide an example of some prior art that concerns
our group [4].
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.
Issue #3 Is the processing model in-scope?
This is an issue that occurred to me in my own pondering on the subject.
Recently a group of W3C members led by Sun Microsystems has proposed a set
of processing model guidelines and a straw man language for XML document
processing called 'Pipeline". Unfortunately I can't find a reference to this
on the W3C site, as I believe it is still under consideration by the staff.
Do we feel that this is in scope for us? It certainly will affect our work,
but it's not clear if it should be under the "web services umbrella" or not.
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?
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 Monday, 11 February 2002 13:57:47 UTC