- From: Hugo Haas <hugo@w3.org>
- Date: Wed, 24 Apr 2002 12:53:53 -0400
- To: www-ws-arch@w3.org
... are available at:
http://www.w3.org/2002/ws/arch/2/04/f2f-minutes
The text version follows.
Regards,
Hugo
----------------------------------------------------------------------
Web Services Architecture Working Group
8-10 April 2002 face-to-face meeting minutes
[1]Working Group home page · [2]Meeting records
Agenda
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
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>
* [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
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
[13]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
[14]Presentation
Tuesday 9 April - morning session
Scribe: Sharad Garg <sharad.garg@intel.com>
Semantic Web presentation
[15]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
[16]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 ve
sted interest)
Use Cases: (enumerated; may be many)
Goal/Context:
Scenario/Steps: (including pre-conditions, post-conditions, err
ors)
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, monit
or/tracking
Out of scope: shipping, Financial reports, legal
Stakeholders/interests:
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
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, err
ors)
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:
* 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
repository
* references between top-level use case document and lower-level use
cases
* 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,
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.
* 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
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
* 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.
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: [18]Hugo Haas <hugo@w3.org>
References
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