RE: Thinking about Web Services Architecture

The items you mention in the priority list are part of the requirements of
the architecture.  I can think of some other requirements also such as
transactions.  My point is , should we not try to gather the requirements
for the architecture formally?

Thanks,

 
_______________________________________________
Waqar Sadiq
 
EDS EIT EASI - Enterprise Consultant
MS: H3-4C-22
5400 Legacy Drive
Plano, Texas 75024
 
phone: +01-972-797-8408 (8-837)
e-mail: waqar.sadiq@eds.com
fax: +01-972-605-4071
_______________________________________________
 
 

-----Original Message-----
From: David Orchard [mailto:david.orchard@bea.com] 
Sent: Thursday, February 14, 2002 12:41 PM
To: www-ws-arch@w3.org
Subject: RE: Thinking about Web Services Architecture

I believe the primary goal of the wsawg should be providing a simple
reference architecture and constraints such that the W3C can charter other
working groups in the wsactivity to DO the actual specification work.

I am very concerned that the WSAWG will take a great deal of time to
evaluate a whole bunch of external architectures before any more WGs can be
formed.  It is expressly in the charter of the wsawg that other wgs do the
work, and that a full architecture is NOT a pre-requisite for those wgs to
be formed.  I lobbied for and believe this is the right charter approach.

I agree that we need to define core functionality.  But we also need
ordering of the work.  As an example, our rough priorities are:

1. Asynchronous, Conversational, Reliable messaging
2. Secure messaging (Given that XMLE as a presumably pre-requesite
technology is not yet at CR)
3. Simple discovery
4. Orchestration

I believe that time to market of creating new specifications is a key
priority that has been largely overlooked in the start of this group.

Let us focus on a few key areas first, start a small number of WGs, and then
work as a group to flesh out the issues that will arise as well as
elaborating on the areas that hadn't been focused on.  Remember that even if
we spun off an asynch/conv/reliable messaging working group today, it would
take many months before they would produce a working draft.

There are many groups outside the W3C that are working on these areas.
Should we take too long, this group may be an academic exercise only.

Another view on this matter.  All of us work for software companies.  The
"perfect" model says that we architect new features completely, then hand
the architecture to the developers.  But the waterfall approach has been
proven to be DEAD for many years.  We now generally sketch out an
architecture, developers start working on it, and the developers/architects
iterate together.  This solves the problem of "analysis paralysis" which
often occurs in top-down projects, and also solves the problem of
unco-ordinated development in bottom-up projects.  My personal term for this
style of development is "middle-out" instead of top-down or bottom-up.

We have a new working group here, that is unproven with many new members.
We should bite of a small to medium sized chunk of work so that we can learn
how we work together, processes for issue resolution, how to co-ordinate,
etc.  The TAG decided to adopt this approach.  Further, the TAG decided NOT
to create a top-down web architecture document for these reasons among
others (6 months was the time some of us came up with).  The job of writing
a complete web architecture document is massively easier than writing a
complete web services architecture because the web is already up and
running!  If the tag ever want to figure something out, it could just look
at the software and document it.  Instead the TAG will develop a web
architecture document iteratively and through the use of findings.

Let us exercise similar prudence and focus on some medium sized chunks of
work, spin off wgs in a timely manner, then elaborate on the architecture
with experience.

Cheers,
Dave



> -----Original Message-----
> From: www-ws-arch-request@w3.org [mailto:www-ws-arch-request@w3.org]On
> Behalf Of Eric Newcomer
> Sent: Thursday, February 14, 2002 9:50 AM
> To: Christopher Ferris; 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
>
>
> 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/00tn0
07/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 14:20:41 UTC