Working Group home page · Meeting records
See also: original agenda, logistics.
| Monday, April 8 | ||
| Morning Session I, 8.30a - 10.15a |
|
|
| Break, 10.15a - 10.45a | ||
| Morning Session II, 10.45a - 12.30p |
|
|
| Lunch, 12.30p - 1.30p | ||
| Afternoon Session I, 1.30p - 3.00p |
|
|
| Break, 3.00p - 3.30p | ||
| Afternoon Session II, 3.30p - 5.00p |
|
|
| Tuesday, April 9 | ||
| Morning Session I, 8.30a - 10.15a |
|
|
| Break, 10.15a - 10.45a | ||
| Morning Session II, 10.45a - 12.30p |
|
|
| Lunch, 12.30p - 1.30p | ||
| Afternoon Session I, 1.30p - 3.00p |
|
|
| Break, 3.00p - 3.30p | ||
| Afternoon Session II, 3.30p - 5.00p |
|
|
| Group Dinner, 6.00p - ? | ||
| Wednesday, April 10 | ||
| Morning Session I, 8.30a - 10.15a |
|
|
| Break, 10.15a - 10.45a | ||
| Morning Session II, 10.45a - 12.00p |
|
|
| Lunch, 12.00p - 1.00p (with Web Services Description WG members) | ||
Scribe: David Booth <dbooth@w3.org>
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.Approved.
Approved.
Chris: I reviewed them this morning, and there was no progress.
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.
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)
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.
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
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
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.
Scribe: Sharad Garg <sharad.garg@intel.com>
Eric Prud'hommeaux presented a talk: Aligning with the Semantic web
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.
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.
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?
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.
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
Scribe: Zulah Eckert <zulah_eckert@hp.com>
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.
Chris F. - Goal for today is to draw out additional requirements from work that we have done over the past few days.
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.
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 ]
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 ]
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.
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.
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 ]
Chris - Can we go through the goals and nail them down and move on.
Zulah - We have done this for 1 and 2, 3 and 17 in our breakout session on Monday. Now, the goal and CSFs needs to be re-written.
[ Agreement to take this to the list after a re-write ]
Chris - platform independence and interoperability
Daniel - we are including implementation and platform independence
Mike Mahon - why are we talking about implementation?
Daniel - because the architecture is obliged to support 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.
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.
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
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
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.
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.
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
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
See also the list of pending action items.
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
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
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