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

Working Group home page Meeting records

Agenda

See also: original agenda, logistics.

Monday, April 8
Morning Session I, 8.30a - 10.15a
  • Introductions
  • Local arrangements
  • Assign scribes
  • Review agenda; AOB?
  • Approve minutes from 04 April telcon
  • Review action items
  • Our goal is to publish the first WD of our 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 sessions
Lunch, 12.30p - 1.30p
Afternoon Session I, 1.30p - 3.00p
  • Review Requirements, Use Cases and CSFs developed in break-out sessions
Break, 3.00p - 3.30p
Afternoon Session II, 3.30p - 5.00p
  • Review Requirements, Use Cases and CSFs developed in break-out sessions
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>

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

Approved.

Approval of March 28 Minutes

Approved.

Review of Action Items

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

Understanding Critical Succes Factor Analysis, Daniel Austin

Presentation

Daniel: I'll be describing CSF , which was developed at MIT's Sloan School.
... 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 hierarchy.
... 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 out.

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 implementation-independent.
... 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 hierarchy.

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 methodology.

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 group.

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

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 clear.
... 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? Prioritizing?

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:

Grouping:

Reliability, Availability, Scalability, Management
	DAG0007
	DAG0019
	DAG0018

Web Friendly
	DAG0009
	DAG0010
	DAG0011

Interoperability
	DAG0001
	DAG0016
	DAG0004

Modular/extensible
	DAG0002
	DAG0003
	DAG0005
	DAG0017

Team
	DAG0013/DAG0014
	DAG0015
	DAG0008

Security
	DAG0006
	DAG0020

=======================================================

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)
Miscelaneous
Standardized metadata (3)
Time to Market (3)
Interaction diversity (3)
Useful
Consistent


(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.

Requirements:

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

Interoperability
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

Brainstorm-
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
comprehension)
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
implementation
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
specifications

(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 =
specification
3) #21 - developer = spec writer
4) #211 - reduce complexity of the architecture by decomposition of
specifications
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
writers
16) #003 - Strike business goals, remove future, add requirements, add
functionality
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.

Questions:

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

Presentation

Tuesday 9 April - morning session

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

Semantic Web presentation

Slides

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

Process
- 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

UNRESOLVED ISSUES:
==================
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?

Requirements
============
- 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
concepts
- We reach our target audience, and we don't need "WSA for Dummies"
- Other standards groups (internal and external to W3C) reference our
architecture
- 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 terminology.

Hugo: summary on privacy:

Is policy a part of QoS?

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

Does this group need to address social policies?

Generic Web services stack presentation

Diagram

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 above.

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
down.)

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
documents.

=Transactions=
simple atomic
complex atomic (multiple services)
simple extended activity
complex extended activity
compensating

=Security=
digital signing
partial digital signing
encryption
authentication
authorization
partial encryptions

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

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

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

=Routing=
XMLP scenarios are probably already pretty complete

=Asynchrony=
dynamic reply-to

=Management Messages=
ping
heartbeats
estimated response time
starting
stopping
spawning more instances
instrumentation

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
issues.

=Description=
workflow
two-party choreography
multi-party choreography
orchestration
ordering of messages to a single service
ordering of messages to multiple services
conversations

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=
availability
uptime
guaranteed response time
cost of usage
security policies
service-level agreements
privacy

=Discovery=
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
services.

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)

Amazon:
case 1:  USER FETCHES INFORMATION
         + IDENTIFICATION
         + GET LOWEST PRICE
         + 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
=========================================
			2002-04-09

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 vested interest)
	Use Cases: (enumerated; may be many)
		Goal/Context:
		Scenario/Steps: (including pre-conditions, post-conditions, errors)
		Extensions: (error handling)
	Specs:
		Requirements:
		Implications:
		Issues:

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

		Goal/Context:
		Scenario/Steps: (including pre-conditions, post-conditions, errors)

Steps for "List an item":
1. Select item category
2. Descibe item
	Seller data
	Item data
	Logistics
	Price
	Services
	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

Assumptions:
	Auction site has sufficient computer power

Output from this group by Chris:

Description
- User auction system (like eBay) that sells items

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

Stakeholders/interests
                     
        eBay company: increase revenue through transaction fees
        + volume                                               

        seller: good price for "stuff"
                reliable buyer        

        buyer: cheapest price for "stuff"

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

Uses
                     
- 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
        price        
        services
        auction                                                
        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

Request
        Asynch
                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 addressing.

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:

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, Provision.

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.

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 requirements.

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 (identified)?

[ 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 stated)

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 groups.

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 ]

Goals

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 ]

D-AG0004

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 implementations

[ 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.

D-AG0006

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 01.

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.

D-AG0007

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 friendly").

Hugo - Volunteers to email out 9 sub-goals

ACTION: WG email out sub-groups notes

D-AG0013

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 matters?

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

D-AG0015

Chris - Time-to-market

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

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 architecture.

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 important.

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) glossary.

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 architecture.

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 model

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 non-normative.

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 referencing.

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 another.

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 rights.

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 market.

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 (security).

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 (?)
=====================================
J2EE
- 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 area.

Chris - thanks to everyone

Summary of new action items

See also the list of pending action items.

Roll

Monday 8

Present
-----------------
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

Present
-----------------
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

Present
-----------------
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: Hugo Haas <hugo@w3.org>