Re: [RTF] Rewording D-AG002 & D-AC007

Hi all,
First....
I thought we agreed that 007 was a team goal as it applied to the
architecture and not to an implementation - a stable and reliable
architecture.
So... this one is not our jurisdiction and should be part of AG006.  I also
think that most of this new AC007 is already covered by AC005 and AC012.

I thought we agreed that we can't dictate that people create stable or
reliable web services (although we hope they do), but that the architecture
should enable the creation of stable and reliable web services. So, lets
focus on this one and what it means and get rid of the architecture related
ones.

See my comments below....

AR007.2.1-AR007.2.3 are good architecture team goals, but not specifically
stated anywhere and should perhaps be added to AC005.


Heather Kreger
Web Services Lead Architect
STSM, SWG Emerging Technology
kreger@us.ibm.com
919-543-3211 (t/l 441)  cell:919-496-9572

Sent by:    www-ws-arch-request@w3.org

To:   "'Hao He'" <Hao.He@thomson.com.au>
cc:   Heather Kreger/Raleigh/IBM@IBMUS, "''Dilber, Ayse, ALASO' '"
<adilber@att.com>, "''ECKERT,ZULAH (HP-Cupertino,ex1)' '" <zulah_eckert@hp.
com>, "''Christopher Ferris' '" <chris.ferris@sun.com>, "Wsa-public (E-
mail)" <www-ws-arch@w3.org>
Subject:    [RTF] Rewording D-AG002 & D-AC007




Hi Hao,

Thanks for your input below.
I have created a new version for D-AG002 as well as D-AC007 (I have
included the essence of your statements, many of which I agree).
I also went over the comments during the ballot [1b] for this exercise for
inspiration,
as well as [3].
Basically, reliability deals with a "snapshot" of the arch., whereas
stability
deals with changes to the snapshot. Evolution is possibly covered in
extensibility,
and is not addressed.
I also propose that we merge 19.1 & 2 (both were accepted during ballot)
with AC007
(I have not included it here, but I can, after we discuss it)

Also look for specific inline comments in your mail.
Let us discuss this in the meeting.

Regards,

-Suresh
Sterling Commerce
[1a] http://www.w3.org/TR/2002/WD-wsa-reqs-20020429
[1b] http://lists.w3.org/Archives/Member/w3c-ws-arch/2002May/0127.html
[3] http://lists.w3.org/Archives/Public/www-ws-arch/2002Apr/0016.html
-----------------------------------------------------
D-AG002
The Web Service Architecture must enable creation and execution of
reliable,
stable, and measurable web services.
<HK> Measurable or Manageable?</HK>


D-AC007.1 The Web Service Architecture must enable creation and execution
of
reliable web services.

D-AR007.1.1 The Web Service Architecture identifies and defines all of
its components precisely and unambiguously.

            <HK>AC005 covers this </HK>


D-AR007.1.1.1. There is a unique identification scheme for
identifying each
component, and all components are identified using this
identification scheme.
<HK>AC011.2.1 covers this already</HK>

D-AR007.1.1.2 The terms and language used to describe the Web
Services

            Architecture and its components are unambiguously defined.
            <HK>AR012.1 and AC005.1 covers this </HK>


D-AR007.1.2 The definition and use of the components is consistent
within the WSA.
      <HK>How is this different from ar007.1.2? I think its covered
by AR012.1 and AC008. </HK>

D-AR007.1.3 The static and dynamic relationship between components is
clearly identified and defined.
      <HK> AC005.9-11 covers this </HK>

D-AR007.1.4 The WSA should provide clear non-normative guidelines for
the use of the architecture and its components wherever applicable.
      <HK> I think this is out of scope, beyond our skill and what
we have time for and what we are obligated to do. </HK>

D-AR007.1.5 The reference architecture must be validated against WSA
use cases.
      <HK> AC012 covers this </HK>

D-AC007.2 The WSA must enable creation and execution of stable web
services.
<HK> This does not relate to the next two ARs... they are focused
on architecture, the above statement is on an instance of a service </HK>

D-AR007.2.1 When a component within the WSA changes, the
change is precisely identified, and the changed WSA is reliable.
D-AR007.2.2 The WSA has a clearly defined versioning policy
for the architecture and its components.
D-AR007.2.3 The assumptions behind a change in the component,
and its scope must be clearly stated.


-------------------------------------------------------------------------



-----Original Message-----
From: Hao He [mailto:Hao.He@thomson.com.au]
Sent: Monday, June 17, 2002 4:07 PM
To: Damodaran, Suresh; ''Christopher Ferris' '
Cc: ''Heather Kreger' '; ''Dilber, Ayse, ALASO' '; ''ECKERT,ZULAH
(HP-Cupertino,ex1)' '
Subject: Rewording about D-AC007


hi, All,

Since I promise to reword 007, here are my thoughts:

If we just consider the top-level characteristics of an architecture. We
want
it to be:

1. Simple but not simpler so developers can implement it easily.
2. Reliable (it means the following aspects:
2.1 Correct and consistent so there are no fundamental flaws in the
architecture.

   2.2 Precisely defined so there is no ambiguity.
   2.3 Can be validated against use cases. )

3. Stable and evolutionary. This means developers can build on previous
implementation without starting from scratch when each new version is
released.
Part of the solution is to allow a good framework of extensibility. This is
already outlined in other goals.  There is another aspect of this issue:
the
architecture must have correctly identified all the fundamental problem and
uses
an iterative approach.  This also requires a standard policy on versioning.
4. Scalable. This has already be dealt with by other goals.


D-AC007 mainly deals with 2 and 3. I therefore propose the following
re-wording to
AC-007:


<D-AC007>
is reliable, and stable, and evolutionary.

7.1 The reference architecture is reliable:
7.1.1 The reference architecture is correct and consistent.
<sd> "correct" with respect to what? Doesn't 7.1.3 cover this (unless you
intended something different) </sd>
7.1.2 The reference architecture is precisely defined without ambiguity,
7.1.2.1 using standard definition languages whenever applicable and
available,
7.1.2.2 using standard terms, and clearly defined new terms.
7.1.3 The reference architecture must be validated against use cases.

7.2 The reference architecture is stable and evolutionary.
<sd> removed "evolutionary" </sd>
7.2.1 The reference architecture has stable fundamentals including
assumptions and scope.
7.2.2 The reference architecture has a well defined versioning policy.
7.2.3 Newer versions must be compatible with older versions.
<sd> sometimes new versions may not be compatible - isn't it sufficient to
be
precise on the change> </sd>


I propose to remove 7.2.4 and all of 7.3
Reasons:
7.2.4 references to other standards have already been considered by other
goals
7.3.1 This can be solved by extensibility.
7.3.2 This can be solved by extensibility.
<sd> I am not sure this is covered by extensibility yet - I have inserted
it
in reliability.
I agree on 7.2.4 and 7.3.1 </sd>

</D-AC007>


Hao He