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

Minutes of the 8-10 April 2002 face-to-face meeting

From: Hugo Haas <hugo@w3.org>
Date: Wed, 24 Apr 2002 12:53:53 -0400
To: www-ws-arch@w3.org
Message-ID: <20020424165353.GB22899@jibboom.w3.org>
... are available at:


The text version follows.




                    Web Services Architecture Working Group
                 8-10 April 2002 face-to-face meeting minutes

              [1]Working Group home page  [2]Meeting records


   See also: [3]original agenda, [4]logistics.

                           Monday, April 8                         
   Morning Session I, 8.30a - 10.15a
     * Introductions
     * Local arrangements
     * Assign scribes
     * Review agenda; AOB?
     * Approve minutes from [5]04 April telcon
     * Review action items
     * Our goal is to publish the first WD of our [6]Requirements
       document by the end of April. The primary focus of this F2F will
       be to work through the outstanding goals (if any) and and develop,
       prioritize and agree on the use cases, critical success factors
       and requirements that will be published in the first WD document.
     * Review of CSFA process (Daniel Austin)

   Break, 10.15a - 10.45a                                          
   Morning Session II, 10.45a - 12.30p
     * Prioritization excersize
     * Establish break-out teams
     * Break-out sessions: Requirements, Use Cases and CSFs

   Lunch, 12.30p - 1.30p                                           
   Afternoon Session I, 1.30p - 3.00p
     * TAG Briefing (David Orchard)
     * Break-out sessions: Requirements, Use Cases and CSFs, continued
     * Regroup, share findings

   Break, 3.00p - 3.30p                                            
   Afternoon Session II, 3.30p - 5.00p
     * Break-out sessions: Requirements, Use Cases and CSFs, continued.
     * Regroup - share findings

                           Tuesday, April 9                        
   Morning Session I, 8.30a - 10.15a
     * Eric Prud'hommeaux <eric@w3.org> - SW overview & requirements for
       WS Architecture
     * Break-out sessions: Requirements, Use Cases and CSFs, continued.

   Break, 10.15a - 10.45a                                          
   Morning Session II, 10.45a - 12.30p
     * Review Requirements, Use Cases and CSFs developed in break-out

   Lunch, 12.30p - 1.30p                                           
   Afternoon Session I, 1.30p - 3.00p
     * Review Requirements, Use Cases and CSFs developed in break-out

   Break, 3.00p - 3.30p                                            
   Afternoon Session II, 3.30p - 5.00p
     * Review Requirements, Use Cases and CSFs developed in break-out

   Group Dinner, 6.00p - ?                                         
                         Wednesday, April 10                       
   Morning Session I, 8.30a - 10.15a
     * Requirements, Use Cases and CSFs, wrap-up

   Break, 10.15a - 10.45a                                          
   Morning Session II, 10.45a - 12.00p
     * Next steps
     * Wrap-up, including next f2f

   Lunch, 12.00p - 1.00p (with Web Services Description WG members)

Detailed minutes

  Monday 8 April - morning session

   Scribe: David Booth <dbooth@w3.org>
     * [7]Scribe List
     * [8]Approval of last meeting's minutes
     * [9]Approval of March 28 Minutes
     * [10]Review of Action Items
     * [11]Understanding Critical Succes Factor Analysis, Daniel Austin
     * [12]Requirements Prioritization Exercise

    Scribe List

   Chris: I have created a randomized list of WG members, and scribes
   will be assigned in sequence from this list.
   If you cannot scribe when it is your turn, then you stay at the top of
   the list for the next time.
   ... David Booth has volunteered to scribe for this morning's session.
   ... Abbie will scribe this afternoon.

    Approval of last meeting's minutes


    Approval of March 28 Minutes


    Review of Action Items

   Chris: I reviewed them this morning, and there was no progress.

    Understanding Critical Succes Factor Analysis, Daniel Austin


   Daniel: I'll be describing CSF , which was developed at MIT's Sloan
   ... It is a top-down methodology that is suitable for designing
   systems as opposed to applications.
   ... What is a Critical Success Factor (CSF)?
   ... It is a key area where performance is required to meet goals.
   ... It starts with a vision: a mission statement.
   ... and proceeds hierarchically, typically with 3-4 levels of
   ... They are cross referenced with usage scenarios.
   ... The result of the analysis includes a mission statement, hierarchy
   of goals, requirements.
   ... You also get two matrices: Problems vs Requirements, and Usage
   Scenarios vs Requirements.
   ... The use cases are part of the analysis.
   ... Example: A goal of "Put a man on the moon in 10 years"

   Q: Is there a way to represent alternate ways of solving the problem?

   Daniel: Yes, you compare them side by side, and the dominant one wins

   Dave Hollander: Risk factor analysis is usually done later.

   Suresh: This looks like requirements, but "Bring the man back alive"
   should be a requirement also.

   Chris: This seems like a design process, but really we want things
   like "Find a means of conveying someone from here to the moon".
   ... We want to try to avoid designing the system in the process --
   just identify the requirements.

   Henrik: Yes, we shold lay out the framework.
   ... Two things are important to me: (1) We come to a sense of
   functionality. The arch is open ended. We shouldn'T have to come back
   and add more later.
   ... (2) It needs to be done in a distributed manner that is
   ... So things like "object oriented" design should be out the window.

   Daniel: Conclusion: CSF analysis produces results that express the
   needs clearly.
   ... Allows us to measure success and prioritize goals.

   Dave Hollander: Where does scoping happen?

   Daniel: Each goal determines the scope of the next level below in the

   Glen Daniels: This seems identical to other requirements analysis that
   i've done in the past. Specifically, the hierarchical nature.

   Daniel: Right. It is not radically different, it is just a way of
   formalizing and clarifying.
   ... Things to think about: Record everything. Refactor and rearrange.
   Leave no stone unturned. Every idea is good. Different levels of
   abstraction require careful navigation.

   Henrik: The hierarchy is for gathering your thoughts, but the
   resulting requirements may not be hierarchical, right?

   Daniel: Right.

   Suresh: Who do you ask for critical success factors? Customers?
   Designers? Implementors?

   Daniel: The people who build and maintain it. Then cross reference
   with the users.

   Ayse: Has this methodology been used in other WGs?

   Daniel: Yes, at least one other WG.
   ... This is not a new methodology, just an articulation of the

    Requirements Prioritization Exercise

   Chris: This is a version of a brainstorming exercise.

   (Group discussion of break-out exercise)

   Glen Daniels: Perhaps we should make use cases for the output of this

   Mark Jones: What does it mean for us to create a reference

   David Orchard: We need make groupings of requirements to define what
   further work at W3C should be.

   Daniel Austin: It may be useful if we distinguish between consumer use
   cases and the developers who use the WS architecture. We address the
   developers. If we divide our requirements up, I think it will be more
   ... Our job is to address the developers.

   Henrik: The outputs of this WGs should be two types: (1) Design
   criteria. What does it mean to be composable? modular? etc.
   ... Often it is useful to have criteria of things to think about.
   ... (2) We are using a lot of terms like security, reliability, etc.
   We need to define a set of terms.

   Suresh: This issue comes up in any working group. You have a certain
   product. How do you use it?
   ... There is a set of use cases for how to use the spec.
   ... But for us it is much more critical to focus on use cases that
   pertain to how we use Web Services.

   Sinisa: What are our goals, and how should we define them? Perhaps we
   should try to define our 5-6 top level goals.
   ... ANd we should distinguish between tech companies and
   business-oriented companies.
   ... This is very different from other standards groups.

   David Orchard: We haven'T clearly defined our top level goals.

   Daniel Austin: Yes, we should take a first approximation at it, though
   we may change details later.

   Doug: is our goal for the next exercise finding definitions?

   Chris: Our initial goal has been to create some groupings.

   zakim, who is here?

   Chris: We have the following categories, and this afternoon we will
   break out into three groups to discuss them:

Reliability, Availability, Scalability, Management

Web Friendly






Security (22)
Interoperability (27)
Aggregation (6)
Scalability (7) (decentralized)
Reliability (12)
Orchestration (5)
Privacy (4)
Managability (4)
Messaging (4)
QOS (4)
Simplicity (2)
Modularity/Extensibility (33)
Team Goals      (6)
Web Friendly (9)
High-level Business Architecture (5)
Deployment (2)
Standardized metadata (3)
Time to Market (3)
Interaction diversity (3)

   (Lunch break. Reconvening at 1:30 PST)

  Monday 8 April - afternoon session

   Scribe: Abbie Barbir <abbieb@nortelnetworks.com>

   Breakout Groups re-visited the design goals and here is the summary of
   the requirements as it was re-addressed by them.

    1. Breakout Group 1: Reliability

   Topics that were assigned include: Reliability, goals 7,18 (Qos).

   Started with Reliability, Availability, Servability (RAS)

   Concluded that using loaded term as RAS, was not good enough.

   Recommend goal 7 fits better with the team goals

   Did not QoS requirements

   Had thought of providing a standard/optional way of CIN and
   provisioning and measurement of web services.

   Discuss the idea of a new working for QoS

    2. Breakout Group 2: Web-friendly

   Notes from Hugo:

Here is the list our sub-group came up with:

1. Identifiable by URI.
2. Leverage existing and emerging Web standards.
3. Complies with Web architecture principles and design of existing
and emerging Web.
4. User can use browser to interact.
5. Program developer can use well-defined description of interface for
Web service.
6. Decentralized discovery (UDDI, WSIL, etc).
7. XML description.
8. Uses XML.
9. RDF models for technologies produced.

Note that there wasn't consensus on all of them nor on their wording.

   Spent a lot of time discussing what is web friendly

   Had a look at the goals (9-11)

   Disagreed on that the semantic web. Because it may be restrictive to
   what we do

   Needed to address requirements due to lack of time.


   Use of URI

   Leverage existing web standards now and future

   Comply with web arch principle and design (new and old)

   User should be able to use browser to interact with web services

   Developer can use well defined web interfaces to application

   Decentralized discovery

   XML description

   RDF description

    3. Breakout Group 3: Interoperability

   Notes from Zulah:

Breakout: Interoperability and Platform Independence

16 Identify arch and tech gaps
1 conformance and interoperability
4 platform independence,
- application environment independence
- implementation independence
- infoset datamodel? Can you set datamodel due to legacy stuff
8 consistent and coherent

Assumptions: URI, (Infoset? Data model, state)-these are issues but we won't
fix them.
1) must be a way for both sides to understand contract between them (what
passes between them)
2) common communication language when they communicate (mutual
3) substitutability (pluggability) of components
4) interoperate with a minimalistic implementation and spectrum of
implementations but not interoperate across implementation levels.
5) technological components do not tie themselves to a particular
6) no tight coupling between components
7) do not dissallow interoperability that is not defined
8) minimum level of common functionality

Issues: who is the audience?

Agreement: web services is associated with URI

New sub goals - CSFs under Interoperability and Platform Independence goal:
1) mutual comprehension
        - compreshsensible messaging
        - identify interaction and messaging protocols in a standardized way
2) partial understanding
3) technical components do not tie themselves to a particular implementation
4) substitutability of components
5) no tight coupling of components
6) minimum level of common functionality
7) do not dissallow interoperability beyond what is defined
8) definition of conformance
        - any additional spec must be conformant

Break out - Modularity

** Architecture is guidance in spec-writing and decomposition of

(there are edits to the existing document)
0) modularity, extensibility, evolovability - is the main goal
1) Business goals is vague - remove it and leave modulatiry statement
2) provides modularity of web services specifications. -> component =
3) #21 - developer = spec writer
4) #211 - reduce complexity of the architecture by decomposition of
5) #212 - the specification should support...
6) #2121 - Remove
7) #213 - The architecture should allow...
8) #22 - Minimize cross-specifcation dependencies by supporting design
prinicples that encourage ecapsulation and information hiding.
9) #221 - modularity/"modular sections of specifications"
10) #222 - Remove (** ACTION Item: what level of optionality improves the
modularity of the  specification. for Henrik and Dave H. to define)
11) #23 - Specifications should be ... components/specification also create
specifications that support this.
12) #231 - Ditto for ACTION Item above - Henrik and Dave Hollander
13) #24 - specifications are sufficiently granular
14) #241 - simple enough to implement??
15) ACTION: compose a set of guidelines for modularity for specification
16) #003 - Strike business goals, remove future, add requirements, add
17) #31 #32 - generalize of: Modules that are orthogonal may evolove
indepently of each other and must still work with the architecture (see goal
#002). This needs re-wording.
18) #005 ACTION: Daniel - role this under modularity ("as simple as possible
and no simpler", "keep simple things simple")
19) #33 - Remove
20) #34 - okay
21) #35 - this becomes an issue for QoS
22) #017 - ACTION: Daniel and Dave Hollander - Roll into #12 - use cases
need to support business functionality and roll to #03 as modularity to
support common business functions.

Question: These things are necessary... are they suffficient?
Light on extensibility - Dave Hollander
Iteration is required - Henrik
ACTION: New CSF - Goal: specs that are created that are conforment with the
architecture do not have to go through a formal process to be considered
conformant (decentralize architectural conformance process).

   Discussed interoperability, what does it not mean?

   We were also assigned goals 1,4 16

   Decided that goal 16 child of goal 1.

   Dealing with 4 and 1, we come with the idea of mutual comprehension
   between web services:

   How to get to do mutual comprehension

   What is the difference between the message and the protocol?

   Decided that the message is the protocol

   We also decided that the architecture should be loosely coupled. This
   include the idea of

   Exchangeable components.

   There should be a minimum level of common functionality (minimum level
   of mutual comprehension).

   The architecture should not preclude additional interoperability over
   time. Make sure to define what conformance was and how to measure it.

   Distinguish between kinds of users of web (consumers and spec
   implementer and spec writers, each has different requirements).

   In the future that future specification have to be conformant.


   Sharad: did you include device independence?

   Daniel: We addressed application level independence that should
   include device independence

   Sharad: We need to be specific on device independence.

   Chris: did we come up with draft requirements?

   Daniel: too little time to do that within the hour that was permitted.

   Group Break starting at 3:00 PM.

    TAG presentation by David Orchard


  Tuesday 9 April - morning session

   Scribe: Sharad Garg <sharad.garg@intel.com>

    Semantic Web presentation


   Eric Prud'hommeaux presented a talk: Aligning with the Semantic web

    Modularity sub-group

   Daniel Austin presented results from the discussion of goal 2, 3,5 and
   17; Group Discussed about merging modular and extensible goals;
   however, decided to keep them separate.

   The group decided to take out the last bullet of goal 3, and
   distribute it to QoS and security goal.

    Team sub-group

   Notes from Anne Thomas Manes:

TEAM Requirements

Grouping includes:
13 - Coordinate with other groups
15 - Time-to-market
 7 - Reliable architecture
 8 - Consistent and coherent
16 - Identify gaps

Requirements apply to:

Work Products
- architecture document
- resolutions/recommendations for issues
- recommendations for new WGs

Attributes / Properties of Work Products
- timeliness
- consistency
- reliability

- issue resolution
- issue escalation
- gap analysis and resolution
  - RFP
  - analysis of existing efforts/technologies
  - coordination with other groups
  - proposal for new group
- launching a new WG

VERSIONING: Are we defining a generic architecture (which could be
implemented using a variety of technologies) or an architecture that
specifies particular specifications and specific versions of those specs?

CONFORMANCE: Will we establish conformance rules/tests?

- Architecture must not be self-contradictory
- Identity target audience for work products
- Comprehensive description (we may need a primer)
- Periodic update of architecture to refer to new standards that fill gaps

D-AG008 (consistency) CSFs
- Consistent terms, use cases, and scenarios across WS Activity WGs and TAG
- The use cases and scenarios are identifiable (URI)
- Consistent use of notations, appropriate use of diagrams to explain
- We reach our target audience, and we don't need "WSA for Dummies"
- Other standards groups (internal and external to W3C) reference our
- AC initiates new WGs per our recommendations

D-AG007 (reliability) CSFs
unresolved (see VERSIONING ISSUE)

   Chris Ferris: Team goals: 13 and 14 merged.

   Goal 7: The group felt that this might not be area that the group
   should be in.

    Security sub-group

   Joe Hui: Summary on security: Will refine CSF # 3.

   WSAGenReq011: it is discussed if the word MUST be changed to SHOULD,
   however no decision yet. Need more deliberations.

   Discussion about merging security and privacy goals into one. However,
   the group felt that they should be separate.

   Henrick raised concerns about WSAGenReq011.

   Action Item for editors: RFC 2828 should be referred for security

   Hugo: summary on privacy:

   Is policy a part of QoS?

   Suresh: How to address the issue if the Service that is not publicly

   Does this group need to address social policies?

    Generic Web services stack presentation


   Dave Orchard: presented generic web service stack.

   Discussion about how to define use cases, however, no conclusion.

   Several people suggested that the use cases should address the web
   service as a whole rather than coming up with use cases for each
   functional block such as security, messaging etc.

   Chris F suggested addressing use cases across the horizontal 6 areas,
   and coming out with more requirements.

  Tuesday 9 April - afternoon session

   Scribe: Steve Vinoski <steve.vinoski@iona.com>

   Chris reiterated the lack of consensus around Dave Orchard's proposal
   to work on functional areas from the morning session. Chris asked for
   a show of hands, turned out to be roughly a 50/50 split, one for
   top-down approach and one for functional approach.

   Daniel suggested three groups: one top-down, one doing functional, one
   looking at what we already have and doing a gap analysis.

   Daniel: we talked about having a use case repository, maybe this is a
   way to get it started.

   Mark Hapner: to start the top-down approach we might want to think
   about program-enabling an existing web site.

   Chris directed that we break into the three sub-groups discussed

   Sandeep: use cases will fall into either top-down or into functional
   view, why have a separate third group?

   Chris: the third group is to look at the cases we have and to help
   with the gap analysis.

   Katia: is group 3 an ideological group that digs down into the
   documents we have?

   Daniel: we have use cases harvested from other groups, we need to
   build on that and create a use case repository. This ties to both the
   document and to Dave's presentation. (Dave H. also commented here, I
   missed it.)

   Dave Orchard leads the functional-approach group, Mark Jones leads the
   top-down group, Daniel leads group 3.

   Chris asked that notes taken in the sub-group meetings get sent to the
   working group mailing list (not the public list). Chris also asked
   that we think about requirements that shake out of the use cases, so
   we could spend Wednesday morning looking at those requirements.

   Group broke up for sub-group discussions.

   Notes from Steve Vinoski:

Functional-approach sub-group

Dave suggested we should take a look at categorizing use cases in
functional areas, and at elaborating the requirements under those use
cases. Success would be looking at requirements for routing, etc.

Heather asked are we going to define terms such as routing along the
way?  Group consensus was yes.

Dave suggested starting with message-oriented scenarios.

Mike brought up the 20 usage scenarios from XMLP.

Group then went through these usage scenarios to get a high-level
understanding of them and the distinctions between them. (I did not
write this down because these usage scenarios are already written

The user scenarios listed near the bottom of our current Architecture
Requirements doc seem to have been taken partially from the WSDL
scenarios, with some added. The missing ones were: caching,
incremental processing, multiple targets for messaging, routing,
tracking, caching with expiry, QoS, application intermediaries,
conversational messaging.

Dave suggested that we take the XMLP scenarios that are not in our
document and work on adding them to our document. Jeff asked why we
have 3 groups all maintaining 3 separate scenario documents. Mike and
Dave pointed out that one of the things this group should do is to
consolidate these documents. Jeff said XMLP has done a lot of work on
these scenarios, and said that we should get agreement with other
groups to work on a single copy. Dave said we should work on the
single copy with liaisons from the other groups, but for today we
should work on addressing the XMLP scenarios not in our document and
worry about inter-group process issues later.

Mike pointed out that when there are near-duplicates among these docs
that we should try to consolidate them.

Anne asked if solicit-response was listed anywhere. Didn't seem to be
listed, so the group thought we should add it.

Dave said we should ensure that WSAWG has the most extensive list of
scenarios. How detailed should our use cases be? Should we show SOAP
interactions and WSDL syntax fragments? Or should that be separate?
Anne said that an architecture doc shouldn't have syntax. Scott
pointed out that a single document means that we should have syntax,
so it covers all groups. Dave said that the other docs use message
exchange patterns (MEPs) and details of SOAP messages to make them
easy to understand, but should ours do the same? Scott suggested
numbering the scenarios and letting the other groups do the
details. Dave said that doing that means you have to go to multiple
documents to get all the details. Alan said he would prefer to forego
the syntax level for our document. Dave asked if we took the details
out, how would a group like WSDL make use of what we produced? Jeff
said that of course the WSDL group is going to show how WSDL is going
to work for the scenarios, and that XMLP would show SOAP details for
the scenarios. Alan pointed out that this is the web, so we could
arrange it all through hyperlinks, and that WSDL and other groups
would base their details on our document. Heather pointed out that
links could go both ways, both from our doc to other groups' documents
and from those groups to ours. Consensus was that we should have
scenarios and use cases in our document without details, and that
other groups should bidirectionally link to our document to provide
those details.

Scott proposed that we have lots of use cases for the left side of
Dave's diagram proposed in the morning, and that we have very little
for the middle and nothing for the right. Maybe we should work on
generating use cases for the middle and the right?

Dave pointed out that for the left-side box, we actually have nothing
for transactions and what we mean by that, little for security (such
as digital signatures). Dave suggested 10 minutes for each
box. Patrick suggested that we instead using the time to break the
boxes like transactions down further.

The following scenarios don't seem to be listed in any of the

simple atomic
complex atomic (multiple services)
simple extended activity
complex extended activity

digital signing
partial digital signing
partial encryptions

=Reliable Messaging=
at least once
at most once
guaranteed delivery
best effort
once and only once

time to live
access to invalidation services
(looks like XMLP caching scenarios are already pretty complete)

XMLP scenarios need to be less ebXML-specific
stateful conversational sessions

XMLP scenarios are probably already pretty complete

dynamic reply-to

=Management Messages=
estimated response time
spawning more instances

Patrick asked where deployment fits. Heather says that deployment
descriptors in WSDL is wrong because it exposes deployment issues to
clients. Multiple conversations about platform dependencies. Dave says
maybe we're really talking about service characteristics
piece. Heather asked whether there are platform-independent things
that we ought to try to cover. Mike asked whether deployment issues
really deal with interoperability. Jeff said that "good citizen" web
services should have common administrative and management port
types. Dave said this seems like an inspection issue, such as messages
sent to a "container." Heather asked about handlers and
intermediaries, and deployment messages needed to ensure that proper
handlers and intermediaries are put in place to meet expectations.

Group agreed that more thought was needed for deployment and packaging

two-party choreography
multi-party choreography
ordering of messages to a single service
ordering of messages to multiple services

Heather asked how aggregation, composition, relate to the above. Is it
covered by the above, or is it a separate category?

Mike asked about adaptation, presentation, user interactions. Anne
pointed out that transformations might fit in here too. Dave raised
the problem of the processing model, where transforming intermediaries
enter the picture. Dave suggested a new box on the diagram for a
description of the distributed processing model. Dave pointed out that
not every box will turn into a spec, that maybe this processing model
is one that becomes implicit. Whether it's explicit or not, there is
an ordering of things that falls under a processing model that we may
need to describe.

Should transformation be called out explicitly as a use case? Some
feel it should be called out, others don't because not all use cases
need to be standardized. We agreed to leave it in for now.

=Service characteristics=
guaranteed response time
cost of usage
security policies
service-level agreements

inspection (discovery at a single service)
registry (looking through a collection of service descriptions)

Dave mentioned two layers of inspection: one level to get information
about the service itself (direct), or another level to go to a
registry (indirect). Discussion of differences between registries and
inspection, where the 3rd party nature of registries allows for query,
search, classification, categorization, and rating.

Heather points out you could also have query by content, involving
digging through service descriptions coming directly from the

Dave pointed out that we don't want to try to duplicate all the work
done on registries such as UDDI, ebXML, etc.

   Notes from Tom Carroll:

Top down use case Breakout meeting 04/09/2002  1:45PM

The goals of Top down use cases are:
   -Validate the architecture
   -Identify gaps in the Architecture
   -Identify needed Extensions to the architecture

Web services use case Categorization:
   -Create a distributed component application
   -Thicker clients (stock ticker,smarter browser)
   -Device communities
   -enterprise integration of applications
   -cross fire wall integration of applications B2B

Possible Usage Scenarios:
   -Composition of services Portal
   -Distribution computing
   -Extended conversation (bidding)
   -Resource sharing
   -Intelligent agents
   -Hub and spoke use cases
   -EDI use cases
   -Find the Best price
   -Provide standardized Service (Standardized interface)
   -Intermediary Certifying authority (Bank)

         + PAYMENT
         + Ship
         + Tracking

Straw Man Usage Scenario:

   +UsersAgent BuysBook PREC: We know the book   POSTC:
          <<includes>>UsersAgent findsBookSeller
          <<includes>>UsersAgent Authenticates
          <<includes>>UsersAgent PurchasesTheBook
          <<includes>>UsersAgent PaysForBook
             <<includes>>Business AuthorizesPayment
                <<includes>>CA AuthorizesPayment
          <<includes>>Business ShipsBook
          <<includes>>UsersAgent TracksBook
   +UsersAgent CancelsPurchase

Open Questions:
  -What about the developer wanting to deploy a web service from a desktop?
  -What is the web service trying to do?
  -What are the non-B2B use cases and where can they can found?

   Notes from David Booth:

F2F Subgroup Break-Out Meeting: Use Cases

Present:  David Booth, Hugo, Himagiri, Sharad, Henrik, Mark Baker,
        Mark Hapner, Daniel Austin, Dave Hollander

Chair: Daniel Austin
Scribe: David Booth

Topic: How to capture and organize use cases

Agreed: Separate use cases from Requirements, and
        requirements should reference the use cases.

Proposal: Usage scenarios will consist of a group of specific use cases.
Common between them: stakeholders and actors.

Proposed format for a Scenario:
        Description: (1-3 paragraphs)
        Scope: (1-3 paragraphs listing issues that are in scope)
        Stakeholders/interests: (enumerate)
        Actors&Goals: (enumerate entities that play a role but do not have a ve
sted interest)
        Use Cases: (enumerated; may be many)
                Scenario/Steps: (including pre-conditions, post-conditions, err
                Extensions: (error handling)

Example: User auction site (from User's POV)
        Description: User auction system (like ebay) that sells items.
        Scope: transaction, search, catalog, financial, security/privacy, monit
                Out of scope: shipping, Financial reports, legal
                Auction company: Increase revenue from transaction fees.  Incre
ase volume.
                Seller: Get good price for stuff.  Find reliable buyer.
                Buyer: Pay cheapest price for stuff
                Buyer, seller: as above
                Web master: QOS, customer satisfaction
                Bank(s): Qualify buyer, credit seller
                Monitor: Arbitrate disputes without losing customers
        Use Cases:
                Sell an item
                Buy an item
                Change an item description

                Scenario/Steps: (including pre-conditions, post-conditions, err

Steps for "List an item":
1. Select item category
2. Descibe item
        Seller data
        Item data
        Auction style
3. Auction site accepts item
        Assign UID
        Add to catalog
        Create page
        Authenticate Seller
4. Acknowledge listing
        Return auction ID
        Give response within 2 minutes

        Auction site has sufficient computer power

   Output from this group by Chris:

- User auction system (like eBay) that sells items

        transaction     financial
        search          security/privacy...
        catalog         monitoring/tracking


        eBay company: increase revenue through transaction fees
        + volume

        seller: good price for "stuff"
                reliable buyer

        buyer: cheapest price for "stuff"


        buyer, seller: as above
        web master: QoS, customer satisfaction
        banks: qualify buyer, credit seller
        monitor: arbitrate disputes w/o losing customer?


- monitor
- sell an item
- buy an item
- change item desc

Steps -> programmer view -> wire view
"list an item"

1. list current items
        category lookup         desc+trans
        category select         "GET"/"POST"
2. describe items
        (list for sale)         "get form": describe
        seller data
        item data
        logistics               idempotent
        seller authenticate eBay
        (uri - message or reserve eBay auction uri)

3. eBay accept item
        assign uid
        add to category
        create page
        authenticate seller
        authorize seller

4. acknowledge listing
        item auction id
        response <= 2 minutes   QoS
                        listing requires <= 2 minute response

                store & forward
                accept response(status?)

   After the sub-group meetings, Chris asked each sub-group to go through
   their work. Dave, Daniel, and Mark summarized the work of their
   respective sub-groups. (The output of each group is supposed to be
   mailed to the working group list, and so these summaries are not
   captured here.)

   There was discussion started by Anne during Mark's presentation
   regarding whether the internals of the web service that Mark mentioned
   in his Amazon example should be considered as part of the overall MEP.
   Glen said that they wanted to include the whole thing because the
   implmentation of the web service might itself use other web services,
   and that they were really trying to use the whole example as a way of
   exploring the whole space.

   Dave O. pointed out that Mark's sub-group essentially created a sample
   application, and that the sample app could be used to drive a wide
   variety of use cases. He said he liked the technique.

   Glen mentioned that you could look at the whole use case cut across a
   number of areas, and it might be interesting to look at the individual
   nodes involved and see how they're affected by all the various areas.

   Sandeep said that if you had multi-party scenarios and everything goes
   right, that's one thing, but what happens if things go wrong, i.e.,
   you have to make sure all parties properly communicate failure back to
   the appropriate other parties.

   Glen said failure issues were interesting, but wondered how we could
   describe such issues at an architectural level. Chris also wondered
   how much of the overall high-level scenario of Mark's group was
   architectural vs. other levels. Mark pointed out that it's iterative,
   that you talk for awhile at the architecture level, then at the design
   level, top-down, bottom-up, etc.

   Glen wondered if the use-case approach to identifying requirements
   might take too long to work through. Dave H. said that if we don't we
   don't have any way to ground our judgment about what we should be

   Chris said we have the idea of a use case repository that can be
   shared among other W3C groups. He wondered how the repository works,
   does each case need a URI, are they described in RDF. Suresh said we
   need a template, Daniel pointed out that his sub-group had come up
   with such a template.

   Mark H. said that in Daniel's group the need to precisely define terms
   came up. There are elemental building blocks that make up use cases,
   and those elemental building blocks needed to be precisely defined.
   Daniel suggested these terms should all be part of the glossary.

   Activities/techniques for handling use cases:
     * glossary/language for use cases
     * categorization of use cases
     * multiple levels of formalization
     * templates for use cases
     * labels for use cases
     * refactoring the cross-referencing
     * task force (TF) within the WSAWG to maintain the use case
       repository (perhaps this TF needs to be cross-group)
     * calls for use cases (after maturity, after working through our own
       uses cases)
     * leverage other works outside W3C
     * migrating existing use cases from other groups into our use case
     * references between top-level use case document and lower-level use
     * cross-reference use cases and requirements (Dave O. expressed that
       in his experience doing this was quite difficult, Chris reminded
       the group that we're giving ourselves work and we have to really
       be willing to take it on)

   Chris said when we think about use cases, requirements, and the gaps,
   we also need to think about requirements around the relationship
   between use cases and requirements. Dave H. said the template out of
   Daniel's group has use cases, requirements, issues, implications, and
   assuminge all captured together. Dave O. said that requirements should
   be structured functionally to easily show priority, rather than trying
   to dig the requirements and priorities out of use cases. Dave O. also
   asked about requirements that are duplicated across use cases. Suresh
   said that analysis is crucial to not only finding requirements but
   also finding duplicates. Mike M. mentioned that in the WSIA someone
   went through the use cases and eliminated duplicate requirements. Tim
   or Mike will post the URL for this to the mailing list. Chris said
   there are probably use cases we could get from the SAML work. Dave O.
   asked if this is about harvesting requirements or use cases, and Chris
   said that we should be looking at both. Anne said some other sources
   would be ebXML message service, CPP, and BPSS, and OASIS BTP, SAML,

   Notes from the board (by Chris):

Usage scenarios thoughts from board

leverage other works (other WS WGs, elsewhere)

reference between leaf node and high level usage scenario

cross reference use cases and requirements

captures requirements, issues and implications/assumptions

uris for use cases

boil down use cases

other sources: WSIA, ebXML (MS, CPP/A, RegRep, BPSS),
BTP, SAML Provisioning

glossary/language for use cases (building blocks)

categorization of use cases

multiple levels of formalization

templates for use cases (DTD or schema?)

labels for use cases

refactoring through cross referencing

task force for managing use case registry

call for use cases after maturity of initial
harvesting excersize

Usage scenarios requirements and goal rewrite

R - terms must be well defined and used consistently
R - use cases organized around usage scenarios, usage
scenarios should reflect common usage patterns for architecture
R - target audience for architectural deliverables must
be defined
R - usage scenarios and use cases must be referencable
via URI(reference)
R - architecture should support use casesat all levels of
WS activity
R - usage scenarios and use cases shall be used as justification
for recommending the formation of new WSA WGs
G - identify or create use cases that support/illustrate the
requirements and web services architecture

  Wednesday 10 April - morning session

   Scribe: Zulah Eckert <zulah_eckert@hp.com>

    Teleconference time

   Chris F: Conference call time toggled between 3:30-4 as opposed to
   3:30-3. This is a problem. Alternating weeks was too confusing. So for
   the next 4 conference calls we will move the meeting to 3:30-5
   (Eastern). We will decide what to do after these four meetings.

   Ayse (ATT) - Next thursday there is a conflict with a WS-I meeting.

   Chris F - if this isn's a significant majority conflict, we won't move
   our meeting.

   Chris f - thanks to Cisco for being great hosts.

    Goals and requirements

   Chris F. - Goal for today is to draw out additional requirements from
   work that we have done over the past few days.
     * Starting with use case discussion from yesterday, identify CSFs
       and requirements to put in our requirements document.
     * Then go over other requirements that we may have arrived at over
       the past two days.
     * The discuss what the reference architecture looks like, what we
       are planning to produce, etc.

    Use cases

   Chris- Use Cases - Suggested prose for glossary/vocabulary/language
   for use cases Is this a different glossary? This is different, it may
   have hyper links to glossary.

   Katia (DAML) - "terms should be well defined and used in the document"

   Daniel - "must"

   [ "terms must be well defined and used consistently" ]

   Daniel - do we think that it a good idea to follow the convention of
   defining the term first time that it is used in place. This is what
   XML Schema did.

   Chris - editorial choice.

    Categorization of use cases and scenarios

   Chris - categorization of use cases and scenarios?

   Daniel - use cases should be organized around a user scenario and user
   scenarios should reflect common usage patterns for the architecture.

   Mark (ATT) - do you mean spec writer?

   Daniel - yes, usage scenarios should be aimed at architecture rather
   than technologies.

   Sandeep - use case could span multiple categories? how do we organize
   this? Cross reference?

   Daneil - Let's get to this when we come to it. Minor detail , not a

   Ayse (ATT) - define users.

   Anne- define target market. In our (breakout) discussion we had this
   as an issue.

   Chris - target audience for all deliverables must be defined

   [ General agreement ]

    Time horizon

   Daniel - we as a group should develop a time horizon in which we plan
   to operate (so a range of time in which we think that our technology
   would be useful).

   Chris - we aren't defining any technology. There is a time to market
   aspect that needs to be addressed. We can have time objectives but do
   we want them to be public.

   ATT - time horizon for deliverables, not group. [ no agreement on this
   - tabled ]

    Formalization of uses cases

   Chris - formalization of use cases

   Daniel - this is a requirement on the group putting the use cases
   together, not the use cases.

   Mike Mahon - stronger words for organizing the user cases. What's the
   point of the organization. Getting to the root common elements of the
   use cases.

   Tim - high level use cases tell stories which are distilled to
   functional use cases which are distilled to requirements. ??

   Katia (DAML) - this is a different point, 1) use cases reflect real
   world (scenarios), 2) how do we organize them, 3) categories of use
   cases. I don't think that these are all captured.

   Daniel - we are getting into what a good editor might do as opposed to
   a requirement.

   Mike Mahon - satisfied with existing statement.

    Refactoring use cases

   Chris - Boil down and refactor, URIs for use cases

   Daniel - Use cases recorded in the document now are not nearly
   sufficent to match what we need to produce a good architecture.

   Dave (BEA) - high level use case must be referenceable and we ask
   other groups to make things addressable by the task force. (URIs for
   use cases).

   Daniel - yes, there needs to be a naming convention for the use cases.

   Suresh - use cases can be in all sorts of languages

   Daniel - URi to each use case may be an issue because this needs to
   (managed by W3C??)

   Hugo - (side conversation about URIs) Not a problem.

   Daniel - task force should have methodology, but it should not be
   exposed to others necessariy

   Mike Mahon - boiling down is alot easier than using a template - you
   have to hunt around for overlap

   Dave (BEA) - if someone submits a use case there might be a rational
   or justification for why existing use cases are not sufficient - make
   the submitters do the work.

   Katia (DAML) - Are we submitters or gatherers? We have to do 1/2 the
   work before we call for use cases.

   Daniel - requirement to send out a call for use cases is a bad idea.

   Dave (BEA) - we might have to define what we mean by use cases

   Daniel - is there a requirement to form and maintain this group over
   time? We only have a two year charter so that would be the time frame.
   I would expect that this task forth will colaborate with other groups
   in the activity. This is a cross group activity not soley the
   responsibility of this group.

   Glen - does the level of granularity of a use case for protocol match
   the level of granularity for this group?

   Dave (BEA) - in identifying the patterns that we find interesting,
   they also might be interesting at a lower level ( ?? this could have
   been the other direction ?? ).

   Glen - good thing to have reference, does not make sense to have a
   single bag of use cases that this group maintains. There are varying
   levels of granularity - you should keep the use cases at the level of
   granularity for your system. Our level of granularity is higher than
   other groups.

   Dave (BEA) - presumably the features in XMLP are there because there
   were requirements, why wouldn't these requirements be also for the
   architecture group (which contains XMLP).

   Glen - we would not touch a use case on headers, but we might have
   non-snoopable channel between a and b style of use case.

   Katia (DAML) - Are we suggesting that we not collaborate? That we
   should have just our own task forse particular to architecture as
   opposed to a cross group taskforce?

   Glen - we should not from the get-go take on the responsibility of
   being the clearing house for use cases for the activity.

   Suresh - We don't want to be boxed into collecting use cases for
   securing message headers. We want to be at a higher level.

   Daniel - if we find that there is a usage pattern that isn't present
   in an existing groups use cases, then we need to identify this.

   Suresh - we do not want to collect their use cases although we may
   want to do this identification.

   Daniel - that's why we are suggesting a cross functionality group.

    Support of different-level use cases

   Heather - it is our responsibility to ensure that the architecture
   will support all of the fine grained use cases.

   Chris - I detect a requirement.

   Suresh - this is a good idea but how will you validate this?

   Katia (DAML) - there is an organizational issue and the above issue

   Hugo - this is a resource issue. In order to get a cross task force
   group, we need the buy in of the activity.

   Mike Mahon - Is this necessary. We can make our complete set and then
   deal with the other groups as needed.

   Daniel - What's the over ridding requirement? One of our requirements
   might be that other groups work with us. We can place requirements on
   other groups.

   Katia (DAML) - We could do this with representatives

   Hugo - This may be simple. There is a good chance that each group has
   a small group of people working on use cases.

   Dave (BEA) - this was brought up at the AC meeting and several people
   were nodding their heads.

   Joe - Each group should reserve the right to rule what is in scope and
   what is out of scope

   [ There was a call to adopt heather's requirement ]

   Suresh - can't do this without defining what we mean by architecture

   Mike Mahon - devil's advocate. What if there was a use case proposed
   that we thought was bad.

   Suresh - trouble with new requirements "all levels" wording. To what
   degree will we attempt to meet the requirements of a B2B use case?

   Anne - the architecture should try to support these use cases, whether
   or not this is achieved is another matter.

   Heather - Either we can meet the requirements or we should throw the
   use case out.

   Dave (BEA) - let's stress requirements. Use cases are there to
   identify requirements. Our purpose is to identify requirements that
   can be used to charter working groups.

   Daniel - use cases also support the creation of the reference
   architecture itself

   Chris - a function of the use cases shall be to support the
   justification for chartering new working groups.

   Katia (DAML) - isn't the primary goal of the use cases to define the
   architecture (the boxes)?

   Dave (BEA) - to define working groups

   Chris - Use cases are supporting documentation for starting WGs

   Anne - basic agenda is not to write the architecture, it is to start
   new groups

   Glen - that's argueable

   Chris - let's not go there right now

   David Booth - we don't form working groups (we recommend possible
   areas for formation of WGs) - word smithing is needed to this effect

   Chris - we provide recommendations (agreement to modify requirement as

   Hugo - this seems a bit of a stretch. Are we advocating jumping over
   intermediate steps (such as identifying requirements, writing a
   charter, etc.). We are creating supporting material for our document
   which will be used as input to the process of determining new working

   Hugo - Once we have a doc and we have identified needed technologies,
   is it our intent to justify our identification through use cases? This
   wording does not exactly put this point forth.

   Chris - We can do more word smithing on this
   The goal wording now says - "Identify or create the use cases that
   validate the requirements and the architecture and illustrate the
   benefits of web services.

   Daniel - the original purpose of using the use cases to illustrate the
   WS architecture came from a goal that got compressed into (?) "explain
   the WS architecture".

   [ much word-smithing which resulted in new wording and closing on this
   item ]


   Chris - Can we go through the goals and nail them down and move on.

   Zulah - We have done this for 1 and 2, 3 and 17 in our breakout
   session on Monday. Now, the goal and CSFs needs to be re-written.

   [ Agreement to take this to the list after a re-write ]


   Chris - platform independence and interoperability

   Daniel - we are including implementation and platform independence

   Mike Mahon - why are we talking about implementation?

   Daniel - because the architecture is obliged to support

   [ there was a long discussion about goals that Zulah(scribe)
   participated in - the result is that interoperability and platform
   independence goals as well as modularity have been significantly
   re-written or structured and will be presented to the list shortly ]

   Tom - we didn't wordsmith but we did identify the sub CSFs (goals).
   Tom discussed some of the notes.

   Daniel - less worried about exact word smithing that having everyone
   be happy with the elaboration of the existing goals.


   Chris - Security?

   Joe - There are changes to CSF 3, strike the parenthesis part

   Heather - there was some rewording about these by the group. Some
   disagreement on requirements

   Joe - would like next step to be to remove the parenthesis part and
   see how the group feels.

   Sandeep - In addition there was general disagreement around 011 and

   Heather - there was dissention in group about 01 and 011 and this
   needs to go to the list.

   Chris - we should identify items not agreed to in the document. Zulah
   take action.

   ACTION: Editorsannotate goal 01 and 011 in document as draft.


   Chris - goal #7, we kept pushing this off.

   Anne - are we defining a generic architecture or other? Until we
   discuss this we can't resolve #7

    D-AG0009 D-AG0010 D-AG0011

   Chris - Goal #8, covered Goal #9, web friendly

   Hugo - There were a few requirements from the discussion.

   Daniel - what do we think about Eric P.s two additional requirements

   Hugo - we have those already

   Heather - we did not adopt the derived goals under 11. They were
   removed. There are 9 new subgoals that the group identified that
   replace the three original goals under a new goal category ("web

   Hugo - Volunteers to email out 9 sub-goals

   ACTION: WG email out sub-groups notes


   Chris - 12 covered, 13-14 is now a team goal. This was not covered by
   the break-out group.

   Suresh - need to work on 7, 11, 13-14 (everything except 8 which was
   covered by the group).

   Hugo - not clear what type of requirements that we will get from this
   (which is a behavior that we would like to have).

   Heather - how do we call out our relationship to other groups?

   Chris - we don't have to do that. It is called out in our charter for
   some, others not necessary.

   Daniel - establishing formal relationship with other groups.

   Hugo - Chair and W3C contact should be working on this. We know for
   example that Oasis is sending liasons and that we need to work on
   ebXML. WS-I, ..

   Hugo - WS-I specific, some liason work with WS description. Unclear
   what activity WS-I is doing right now that we could liase with.

   Dave (BEA) - why can't we (WSAWG) say who we want to work with on what

   Chris - Let's take a 20 minutes break. And return and cover 15.


   Chris - Time-to-market

   Glen - these are great goals and worth discussing but probably go to

   Hugo - Why you would want architecture document to be up-to-date. This
   is weird requirements because of 2 year span of group. This
   requirement goes beyond our life.

   Mark (ATT) - do we want to recommend an after life?

   Chris - There is an aspect of prioritization about this

   Heather - make progress as opposed to focus on wording

   Daniel - must prioritize with respect to working group
   recommendations. This is a higher priority than creating a reference

   Chris - does prioritization become a requirement - specifically early
   visibility and understanding of the nature of requirements for WGs

   Daniel - maybe we should just agree to this ourselves as opposed to
   writing a requirements. We should address the urgent issues, then the

   Prasad (Web Methods) - Introduces himself (W3C, RosettaNet -
   represents web services at Web Methods). Scoping is necessary prior to
   defining what groups need to do.

   Suresh - This means that we have to have an architecture before
   recommending groups

   Heather - we can publish things as we go and this is the
   time-to-market. As opposed to producing documents and saying ta-da!

   Joe - we need to strike a balance.

    About the reference architecture

   Chris - Change of discussion - What do we think that we are building
   (reference architecture)

   Daniel - looked at 3 ref architectures (J2EE, Corba, ??) all have
   specific sets of componenets: 1) an architectural meta-model 2)
   description of views of architcture (views: logical, process,
   development/design time, physical) 3) rational - text description of
   justification for design decisions 4) reference technologies, 5)

   Mark (SUN) - in J2EE we focused on roles arch describes and the
   contracts between them (roles). this clarifies information hiding.
   Specifically in the case of J2EE, developer, assembler, container,
   deployer, deployment tool. Our contracts were primarily java
   interfaces so there was no additional communications - it allowed us
   to specifically focus on dependencies within the system that we were
   defining. This made communication easier. We had a packaging
   architecture which was the communication arch (implied artifacts). And
   an explicit work flow defined by the artifacts.

   Heather - We need to include communications. You made a statement that
   said you need to define the roles and responsibilities of the
   components. This does not seem like what J2EE did. The role is partof
   the architecture as opposed to having a component that has a role.

   Daniel - We can say identify the roles and responsibilities in the

   Mark (ATT) - can you share more about what an arch meta model might be
   for us?

   Daniel - A vision and a set of principles on which the architecture is
   based (what Henrick has called guidelines). The meta model is text.

   Mark (SUN) - In J2EE we focused on explicitly listing the requirements
   and identifying how to test them. We were specifically interested in
   conformance. In the end, our primary goal was to define a boundary
   that you could determine what was part of J2EE and what wasn't (to the
   developer and platform implementor).

   Daniel - where do the system boundaries withing the arch lie and can
   we describe them. This is part of the meta model.

   Mark (Sun) - What was out wasn't bad, just that the model didn't say
   anything about what was out.

   Daniel - the 4+1 architecturl approach is very widely adopted approach

   Mark Baker - 4+1 is control-centric while web architecture is
   data-centric. Roy Fielding says this.

   Daniel - we have more to say about some views than others - logical
   has more meaning to us than the physical.

   Dave (BEA) - overview diagram should be included (stack view, others).
   Stack view is a projection of deployment and in that sense it is
   lossy. There is more detail in other views of the same information. So
   we will need a few views.

   Daniel - Stack diagrams convey a good view of the boundaries of the
   system. We should have component diagrams, dataflow diagrams, etc.

   Dave (BEA) - what is the different between the arch doc and the meta

   Daniel - one is contained in the other.

   [ There is general consensus that this should be "guidelines and
   principles" and that "meta-model" was not the appropriate wording ]

   Hima - Does it help to take a use case and fit (test) this on the
   architecture? ???

   Dave (BEA) - Is the proposal that we would use 4+1 as the methodolgy
   for reference architecture?

   Jeff (Oracle) - this is a proposal for ????

   Hugo - (on rational) it is going to be hard to have this section
   because if you wanted to be very detailed you could point people to
   the email list.

   Daniel - at a larger more abstract level you want to provide this
   justificcation for decisions (could be 1-5 pages).

   Chris - an example is we might provide rational for why we choose
   infoset (at this level)

   Dave (BEA) - Normative or non-normative - is this a section or what?
   Rational belongs in primer, not architecture document. It is

   Hugo - not the highest priority - every working group ???

   [ there is dissent on whether we have a high level rational section or
   whether this type of information belongs in a primer (or sprinkled in
   document) ]

   Dave (BEA) - what is referenced technologies

   Daniel - a list of technologies used within the architecture. E.g.,
   WSDL is how we describe web services. Version numbers may or may not
   be necessary.

   Dave (BEA) - how is this different from a W3C document of normative
   and non-normative stuff. Is this any different than W3C normative and
   non-normative references section.

   Daniel - Yes. We should have a list of technologies that we are

   Jeff (Oracle) - in the contect of a ref architecture saying something
   is normative or non-normative makes no sense. Will there be
   conformance tests to validate conformance to the web service reference
   architecture. Dave (BEA) - there is a difference between a suggestion
   and a commandment for a technology.

   Jeff (Oracle) - we are doing this so W3C specs fit together.

   Mark (SUN) - for J2EE we explicitly wanted a conformance test for the
   overall platform. So, we versioned the platform just like any other
   spec. On the other hand if we are producing a web services bill of
   rights, and the group will be around forever, and we will never put
   explicit laws on the books (architecture is conceptual and for
   organizational purposes only).

   Daniel - Goal 1 calls for conformance criteria. We need ot define
   criteria for others can make conformance tests (as opposed ot doing
   them ourselves). We need to lay down laws on how to play nice with
   each other.

   Dave (BEA) - this is a scripture reading sort of thing, we are all
   reading it differently. We need to decide whether we are defining lock
   down conformation testing or guidelines/recommendations.

   [ the charter does not say anything about conformance testing ]

   Anne - the charter does not specify an abstract architecture or a
   functional architecture.

   Mark (SUN) - The reality is that someone has to define this
   architecture. If it doesn't fall to this group it will fall to

   Mark (ATT) - There is a sense in the charter that the interactions
   need to be proscribed. This won't come from an abstract bill of

   Hugo - We should have a functional view but this group produces an
   abstract architecture.

   Dave (BEA) - reads charter and concludes that this says that we are
   not doing conformance level architecture. This is guiding us to
   produce a document to guide the creation of WGs. Conformance doesn't
   seem to be in scope.

   Anne - this doesn't include describing specific profiles of use.

   Suresh - we could provide an abstract architecture with guidelines on
   how to use today's technologies. We should separate the binding of
   technologies and architecture because today's technologies do not
   account for the future.

   Anne - e.g., the way that we desribe security should be compliant with
   SOAP 1.X... We scope requirements for WGs. If we have identified that
   a technology exists, then we can have new WGs work with them. It is
   not the job of this group to decide what will work together.

   Mark (SUN) - We have to define a full stack. If this group wants to
   take on the job of the WSDL meta-model and delegate the choice of
   type-system, etc. If this is the case, then this group can't really
   say anything. You have to go to the individual groups.

   Dave (BEA) - Proposes that we could send down guidelines

   Daniel - guidelines are a note (advice) they are non-normative.

   Chris - notes the relationship between this discussion and time to

   Dave (BEA) - November AC meeting is an important delivery date for
   this group. We need to have new WGs starting up the chartering
   process. We will be forced to justify our existence if we have not
   delivered by then. My proposal is that one of the goals as a group is
   that we have n-numberof things layed out for proposal in this
   timeframe. W3C is getting reputation as being a slow body in which to
   do things. There is no way that we can figure out a charter for
   something like discovery in this short term. We can prioritize because
   we have some feel for complexity. There is demand for other things

   Chris - what do we have to produce in support of this? Do we have to
   point at a 4+1 in order to convince the AC to create a WC?

   Daniel - Two goals - suggest the creation of working groups, create
   reference architecture. He suggests a draft of the architecture and 3
   new WGs recommended by the November deadline.

   Suresh - on whether the architecture draft is normative or not. There
   are normative principles. Principles don't define conformance at the
   elements level. You can't do conformance testing without specs. But
   you can conform to principles.

   Anne - Conformance is wonderful but if we get wrapped in this we won't
   get anything done. Time to market is most important.

   Prasad (WM) - ??

   Dave (BEA) - proposes that for the things that we can do in a time to
   market scenario we focus on. (See prioritization above). The
   prioritization can be very simple.

   Notes from the board (by Chris):

What is a Reference Architecture?

- Architectural guidelines, principles, vision
- Descriptions of views (4+1)
        - logical view
        - process view
        - development/design-time view
        - physical view (does this apply to us?)
        - user scenarios
- Rationale (not a section per se, but sprinkled throughout
where appropriate to support aspects that involved specific
architectural choices)
- Referenced technologies (version specific?)
- Glossary
- Conformance criteria (?)
- concentrates on roles and contracts betweeen them
- defines boundaries
- note contracts/communications between components
- identify roles and responsibility
- describe requirements as testable assertions
- overview diagram of how this stuff fits into the stack

    Wrapping up

   Chris - we have alot of work to do this summer. We are taking August
   off. We are still struggling with these issues. We need people to be
   fully engaged and to contribute.

   Glen - Talk to your customers - find out what they need

   Zulah - We have a good proposal on the table (Daniel's), and we have
   people who are interested in moving forward with this prioritization.
   Let's agree, assign responsibility, and move forward. We can work in
   multiple threads.

   Dave (BEA) - make it very easy to submit directly into the document.
   Be very receptive of this. Companies can be very proactive in this

   Chris - thanks to everyone

Summary of new action items

     * ACTION: Editorsannotate goal 01 and 011 in document as draft.
     * ACTION: WG email out sub-group notes

   See also the list of [17]pending action items.


  Monday 8

Chris Ferris
Jeff Mischkinsky
Shishir Garg
Ayse Dilber
Mark Jones
Tom Carroll
Zulah Eckert
Daniel Austin
David Booth
Hugo Haas
Krishna Sankar
Sandeep Kumar
Sharad Garg
Jin Yu
Hima Mukkamala
Doug Bunting
Suresh Damodaran
Steve Vinoski
Patrick Thompson
Mike Mahan
Tim Jones
Yin-Leng Husband
Dave Hllander
Abbie Barbir
Joe Hui
Sinisa Zimek
Glen Daniels
Mark Baker
Allen Brown
Henrik Frystyk Nielsen
Tom Bradford
Heather Kreger
Anne Manes
Dave Orchard
Mark Hapner
Scott Vorthmann

Remote via Zakim
Joel Munter
Hao He
Prasad Yendluri
Mike Champion
Paul Denning

  Tuesday 9

Tom Bradford
Chris Ferris
Jeff Mischkinsky
Scott Vorthmann
Heather Kreger
Shishir Garg
Ayse Dilber
Mark Jones
Alex Cheng
Glen Daniels
Mark Baker
Katia Sycara
Allen Brown
Henrik Frystyk Nielsen
Mike Mahan
Yin-Leng Husband
Dave Orchard
Suresh Damodaran
Steve Vinoski
Tim Jones
Doug Bunting
Hima Mukkamala
Jin Yu
Sharad Garg
Abbie Barbir
Joe Hui
Dave Hollander
Tom Carroll
Daniel Austin
David Booth
Hugo Haas
Zulah Eckert
Sandeep Kumar
Srinivas Pandrangi
Mark Hapner
Anne Manes

On Zakim
Prasad Yendluri
Hao He

  Wednesday 10

Tom Bradford
Jeff Mischkinsky
Chris Ferris
Heather Kreger
Ayse Dilber
Mark Jones
Glen Daniels
Mark Baker
Katia Sycara
Allen Brown
Mike Mahan
Yin-Leng Husband
Dave Orchard
Suresh Damodaran
Tim Jones
Hima Mukkamala
Sharad Garg
Abbie Barbir
Joe Hui
Tom Carroll
Daniel Austin
David Booth
Hugo Haas
Zulah Eckert
Sandeep Kumar
Mark Hapner
Anne Manes
Prasad Yendluri

On Zakim
Shishir Garg

    Chair: Chris Ferris <chris.ferris@sun.com>
    Minutes assembled by: [18]Hugo Haas <hugo@w3.org>


   1. http://www.w3.org/2002/ws/arch/
   2. http://www.w3.org/2002/ws/arch/#records
   3. http://www.w3.org/2002/ws/arch/wsawg-f2f-apr2002
   4. http://www.w3.org/2002/ws/desc/2/03/f2fAprilLogistics
   5. http://www.w3.org/2002/ws/arch/2/04/04-minutes
   6. http://www.w3.org/2002/ws/arch/2/wd-wsawg-reqs-04012002
   7. http://www.w3.org/2002/ws/arch/2/04/f2f-minutes#item01
   8. http://www.w3.org/2002/ws/arch/2/04/f2f-minutes#item02
   9. http://www.w3.org/2002/ws/arch/2/04/f2f-minutes#item03
  10. http://www.w3.org/2002/ws/arch/2/04/f2f-minutes#item04
  11. http://www.w3.org/2002/ws/arch/2/04/f2f-minutes#item05
  12. http://www.w3.org/2002/ws/arch/2/04/f2f-minutes#item06
  13. http://www.w3.org/2002/ws/arch/2/04/UCSFA
  14. http://www.w3.org/2002/ws/arch/2/04/TAG4WSARCHF2FApr2002
  15. http://www.w3.org/2002/Talks/0408-ws-f2f-sweb/
  16. http://www.w3.org/2002/ws/arch/2/04/WSAWGF2Fdiagram.png
  17. http://www.w3.org/2002/ws/arch/2/04/f2f-minutes#curr-ai
  18. http://www.w3.org/People/Hugo/

Hugo Haas - W3C
mailto:hugo@w3.org - http://www.w3.org/People/Hugo/ - tel:+1-617-452-2092
Received on Wednesday, 24 April 2002 12:53:54 UTC

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