AT&T Mark Jones BEA David Orchard Carnegie-Mellon Katia Sycara Chevron-Texaco Roger Cutler Computer Assoc. Igor Sedukhin Contivo Dave Hollander HP Yin-Leng Husband HP Zulah Eckert IBM Heather Kreger Iona Eric Newcomer Nokia Mike Mahan Oracle Martin Chapman Progress Colleen Evans See Beyond Ugo Corda SAP Kevin Liu Software AG Mike Champion Sun Doug Bunting Thomson Hao He (remotely) Tibco Don Mullen Toshiba Frank McCabe W. W. Grainger Daniel Austin W. W. Grainger Tom Carroll W3C Hugo Haas W3C David Booth Web Methods Prasad Yendluri
Chair: Mike Champion, Software AG
<dbooth> Scribes are reminded of http://lists.w3.org/Archives/Member/w3c-ws-arch/2003Jan/0020.html
MikeC: would like to change this AMs agenda to spend 2 hours on reliability and 1 hour on issues list.
Roger: wants reliability first, otherwise strict adherence to time
MikeC: Breakout had discussion on restructuring the document...
Eric: presents results from yesterday's document breakout session.
... discussion was principles for document organization and an approach to editing it.
Scribe: 1) contract statement (how arch is presented, structured,
and what you will get out of it)
... Introduction to arch approach for target audience
Daniel: should include explaination of doc notation, etc.
... will this say who the target audience
Eric: specification writers, product developers (arch conformance), service developers, technology reviewers
DaveO: include AC reps
MikeC: maybe not developers but architects
<HaoHe> Zakim ??P7 is Hao
Doug: people writing profiles of web services
DaveO: includes WSI
Eric: (returning to 2 above) qualifications or qualities
Scribe: secure, manageable, extensible
... (fix) 2 is concepts and relationships, 3 is qualifications or qualities
... 4) requirements and constraints
... scalability, web friendly
Frank: The meat of the architecture is 2 - an enumeration of key concepts and relationships
Scribe: 3 is a way of interpreting the elements from 2 in terms of qualities
MikeC: grid view of this (one axis is 2, the other is 3) is appealing
Katia: point of bringing in requirements is to relate requirements document
Scribe: Use of the document/architecture for conformance?
... Prescriptive vs. descriptive?
... feeling is that the doc should be descriptive.
... Prefered technologies?
... Need for a Primer? (informative as opposed to normative)
... Suggestion to include the glossary
... two aspects of the discussion: clarify main concepts and definitions, ??
MikeC: include by reference or
Zulah: problem is a process to grow the glossary and get arch consistent use of terms. including the glossary was a proposed solution or process.
MikeC: wants to integrate glossary in document and have a style sheet to generate document.
<HaoHe> I'd like to see the document more formalized.
DaveO: frustrated about navel-gazing over glossary location, we
have gone back and forth about this.
... does not think value over reference will solve the consistency problem. Someone will still have to do work.
Scribe: No decision on what to do with the glossary
Eric: (continuing with list of issues/questions)
Scribe: List non-goals/non-requirements
... Ensure that concepts are related appropriately (level, containment, infosections??, etc.)
... Review to ensure requirements are met
... Diagrams - review as we go after re-org (rather than up-front determining the diagrams)
Frank: emphasises that as soon as concepts and relationships it becomes easier to talk about conformance. The downside of strict enumeration, the current approach doesn't support entry points into the arch (e.g.., manageability). So you can have different views into the arch.
Daniel: Is there an accounting of how the arch meets requirements?
Katia: this is point of #4 above.
... another point was that the distinction between basic and extended architecture would go away with the restructuring.
Roger: action items?
MikeC: Can we take a deeper lookat 2 and 3.
Katia: concepts: providers and requestors, one relationship: interaction through messages, now messages is another concept.
Frank: Classic modeling. The core relationships are isa and hasa.
so requestor isa actor etc.
... the core of the architecture is the enumeration of these concepts
Katia: how the concepts relate is also there
MikeC: within this framework, how would we talk about messaging, reliable messaging, and reliability as a whole.
Katia: not sure about reliability as a whole, vague concept.
Concepts: messaging, reliability, security. Qualifications: secure, reliable,
... provides a more formal way to make inferences about properties.
<Roger> We are getting very close to the time box.
MikeC: Use this and see if it works for reliability discussion coming up.
Scribe: Action: Eric will produce a draft of #1 to be reviewed by the break out team.
Eric: It is up to the editors to work on the other items.
Scribe: Action: Eric, Katia, DavidB to work on proof of concept for
... Action: add Frank to the proof of concept above
<hugo> ACTION: Eric, Katia, DavidB to work
on proof of concept for restructuring
... ACTION: add Frank to the proof of concept above
Scribe: Action: Add DavidB as an editor to the arch document
<hugo> ACTION: Add DavidB as an editor to the arch document
<Roger> I knew action items were going to take ten minutes. And you said "What action items?"
<hugo> ACTION: Eric will produce a draft of #1 to be reviewed by the break out team.
MikeC: we will revisit this issue later in the day. We should keep
2 and 3 above in mind while discussing reliability. Which we will discuss
... discuss concepts, relationships, qualities, and contraints surrounding reliability.
Roger: WSR document is a fairly straight rendering of ebXML messaging into SOAP.
Daniel: WSR might be a place to get our conversation started.
MikeC: identify conccepts relationships, qualities and constraints
around the reliability thread.
... what are the concepts? Message, SOAP headers that leverage SOAP processing model to degociate what can be determined about whether a message was actually delivered.
Roger: You detected 2 themes in the threads: transactional and TCP/IP.
Martin: Can we have a summary of the thread?
<HaoHe> RM is just part of the story
doug: summary there are a number of people trying to convince one person. reading is depressing...
Martin: given the amount of research in the area
Doug: include concised statement about TCP reliability
Ugo: two concepts, making ure that the message gets there, making sure that the message is acted on. another thread is where you focus reliability (Transport, SOAP, application).
Roger: These threads have been going on at incredible length on implementation. From an end users view point want to push a button, send message to trading partner, with high confidence that it will get their or they will know that it did not. Another component is that if you don't know what has happened that you can query the system to determine what happened.
MikeC: In the broadest terms reliability is accpting the reality that there is complex infrastructure between producers and consumers and reliability ...
<HaoHe> do we use the queue at all?
Roger: one other implied component. Want a situation that this is a consistent mechanism between trading partners.
Martin: (takes up the pen and...)
MikeC: three things 1) mechanical to make sure that a message arrives once and only once. 2) rest model of designing your messaging such that you can always retry. 3) Choreography, failure is one of the many things that can go wrong in a business transation and can be commits and rollbacks.
<HaoHe> ok, 1. RM has very little to do with WS reliability
Hao: Reliable messaging is only part of the problem in making sure
that a produce and consumer get the job done, the overall interaction between
the producer and consumer also may need to be reliability. This gets into
some of the management issues related to reliability.
... state of interaction needs to be exposed so that both can see state
Daniel: Will past in a definition of reliable messaging.
<HaoHe> the argument about 1 is that the RM layer does not have enough information to act upon
Scribe: general dislike of definition due to always notify that things went wrong...
<Daniel> Definitions follow:
... Reliability: http://dictionary.reference.com/search?q=reliability
Martin: reliability can be divided into reliable messaging, and reliable service/server (state)
<Daniel> An attribute of any system that consistently
... the same results, preferably meeting or exceeding its
MikeC: as a third could include multiple interaction, transactional
<Daniel> reliable communication:http://dictionary.reference.com/search?q=reliable%20communication
... Communication where messages are guaranteed to reach their
... destination complete and uncorrupted and in the order they
... were sent. This reliability can be built on top of an
... unreliable protocol by adding sequencing information and
... some kind of checksum or cyclic redundancy check to each
... message or packet. If the communication fails, the sender
... will be notified. Transmission Control Protocol is a
... reliable protocol used on Ethernet.
Katia: visibility is a requirement on reliability
MikeC: a property in the architecture that you can't always get what you want.
Martin: diagram that cannot be reproduced in text....
<Daniel> Free online dictionary of computing: http://foldoc.doc.ic.ac.uk/foldoc/index.html
<HaoHe> People need to understand that RM does very little to
the overall reliability of the whole system.
Martin: 1) don't know propoerties of transport layer (visibility and state)
<Roger> I'm sorry, I disagree. In practical, business terms it is a heavy hitter.
Martin: Is going to enumerate cases
Scribe: 1) one way no feedback
<Roger> I think it is the factor that allows you to treat the process as loosely coupled. In that case, I handle my backend problems on my side, you handle them on yours.
Scribe: 2) one way with built in synchronization points (e.g., went
out on wire), can report last known for message transport
... 3) point
... 3) two way is one way with sync at application level - as opposed to transport. Problem is now reciever doesn't know if their response arrived.
Issues: retry? may be sending to a queue - timing
Katia: You get sequence but not in a timely manner
MikeC: part of the point of the discussion is to ensure that we have glossary terms - do we have one for reliabiltiy? Do we need one?
Scribe: Likes DaveO both sides agreeing to a change in state.
Frank: don't connect change of state and reliable messaging.
<Roger> Here is the current glossary definition of RM. I
think the consensus on the threads was that this is not perfect but not bad.
... The ability:
... of a sender of a message to be able to determine whether a given message has been received by its intended receiver and to take compensating action in the event a given message has been determined not to have been received.
... of the intended receiver of the message to be assured that it receives and processes a given message once and only once.
... of both sender and receiver of a message to carry out (1) and (2) with a high probability of success in the face of inevitable, yet often unpredictable, network, system, and software failures.
Scribe: Others disagree, messages effect state change
<MarkJ> Here's the text from the MEP breakout session yesterday -- http://lists.w3.org/Archives/Public/www-archive/2003Jan/0067.html
MikeC: Suggestion to have break out sessions. People who are
interested in reliability (top down) in one team, and realiable messeging
discussion in another (bottom up).
... has a diagram that layers TCP, reliable messaging, and BTP (transaction), and then applications.
<MarkJ> You can also find the MEP text at http://lists.w3.org/Archives/Public/www-ws-arch/2003Jan/0494.html
DaveH: Diagram is one strawman, you would end up with a variation if we brought in more transaction processing. So, don't get hung up on this diagram.
MikeC: Can view this as application's job, or provide various layers of support. Does think that we need something like this diagram.
Scribe: Objective of top down - define terms, concepts, maybe
... Objective of bottom up - define reliable messaging concepts and relationships
DaveH: You have 1 hour to come back with something that we can approve and agree on as a statement of reliability.
<hugo> WS-Reliability: http://otn.oracle.com/tech/webservices/htdocs/spec/WS-ReliabilityV1.0.pdf
MikeC: Leader for bottom up will be Roger (reliable messaging) goals: identify concepts, relationships, qaulities definition of terms, diagrams are good.
Scribe: Leader for top down is Mike goals: yes we have goals.
<HaoHe> I'd like to join Mike
... can I get the phone to Mike's team?
<ericn-scr> Mike summarizes the morning's discussion on
... The discussion did not seem to invalidate the morning's discussion about changing the approach to the document
... Reliability focused on the messaging layer may resolve the largest part of the problem
... Action item on Katia, Mike, Frank, Daniel, Zulah and David to flesh out the spec text on the topic
<dbooth> ACTION: Katia, Mike, Frank, Daniel, Zulah and David to flesh out the spec text on the topic
<ericn-scr> Debate about reliability of network and transport
layers and the impact upon the higher levels
... Roger says we're really taking about an acknowledgment infrastructure, and how to turn that into reliability, statistically
... The acknowledgement infrastructure is only one part of reliability, but they have a lot to say about persistence
... We condidered a three level model: application, soap binding, transport
... Things could be added to SOAP to improve the transport reliability for example
... We did not really get to the other levels in the dicussion, but reviewed some of the traditional mechanisms
... Fire and forget, UDP is the minimum, then tcp you get more, http on top of TCP but doesn't really add anything
... SMTP adds asynch dimension, retries, store and foreward, but the time to discover failure can be longer
... Managing the constraints in time to report failure is essential to business processes
... SMTP is the first thing you encounter in the stack to introduce the timing element
... Then shifted to talking about capabilities, determination of delivery status
... Acknowledgement of message reception or timeout waiting for one
... Persistence, an important part of the ack mechanism, needed to have a retry capability, and on the receiver ncessary to handle duplicates
... Need persistence to guarantee delivery of message from transport to application
... Persistence helps manage resources like security, and can help with performance
... Issue of message ordering was not discussed
... Four levels of ack, you know the message got to the receiver
... Second level is the sender transport has gotten the message to the receiver transport
... Next level is that the sender app got the message to the receiver app
... Last or fourth level is ack that the receiver applicatgion satisfied the request; this part is typically excluded from reliable messaging scope
... Attempt to provide framework for the discussion
... We did not drill down too much on error conditions other than to observe that they are all related to acks or lack of acks
... [sorry last statement was by DaveH, previous summary by Roger]
... DaveH: the main thing we were trying to get to was that we can define reliability through the use of an ack infrastructure
... DaveH: Then associate quality factors with the ack infrastructure, seemed to really simplify tings
... MarkJ: You get a good level of reliability even without acks, reliability ends up being more of a systme property
... MarkJ: You can live with a certain level of (imperfect) reliability since the applications know what state they're in, or can determine it
... MarkJ: The real world works this way, people live with less than perfect reliability mechanisms all the time, you just have recovery from failure in place
... dougb: look at this as composition rather than layering?
<HaoHe> Agree, you cannot really layer this.
<ericn-scr> Frank: question about intermediaries with respect
to the ack framework
... Not an ack programming model, just a conceptual way to attack the problem
... ACTION: David will write it up for the private list, Roger to review
... ACTION: David to write up the ack framework discussion and email it
<DaveH> ACtion to David is to daveh
<ericn-scr> ACTION: Roger to champion the topic on the email list once text is ready
<DaveH> daveh to send to roger, roger to post to email list
<dbooth> My slides on "Re-thinking Discovery": http://www.w3.org/2002/ws/arch/2/10/roles_faq_clean.htm and the associated document on roles: http://www.w3.org/2002/ws/arch/2/10/roles_clean.htm
<ericn-scr> Mike: came at this bottom up and top down,
different views on errors need reconciliation
... Now moving to the discovery discussion led by David Booth
... Suggested change: mention choreography as part of the Web services description
... Note: suggested changes to David's document as he walks through it and discusses it with the group
... Suggested change: re-label the "semantics" box "what else you need to know" or equivalent
... Suggested change: Figure 1 canbe reduced to show the standard web paradigm where the WSD is only a URL
... DaveH: Clarifying the purpose of the discussion DaveB is leading, helps us for example to talk about early vs late binding referring to the diagrams. Let's not look at whether the details are right but whether or not this is a helpful framework for incorporating into the document in the context of explaining to the world what's going on.
... DaveH: Proposes to allow DaveB to continue within the context of our evaluating the framework he's proposing rather than examine all it's details for accuracy.
Scribe: Suggested change: Figure 3 depicts a scenario that is present in mobile operator platforms where there standardized services and interfaces to those services, and you may want to connect to any one of the 20-30 mobile operator platforms in the world providing the service.
<ericn-scr> Suggested change: Review other scenarios in which
the WSDL may come from a variety of sources, clarify whether or not the
abstract part of the WSDL is provided by one person and the port type by
someone else, perhaps can refactor Figure 3 to be more generic (different
roles for different parts of the description), might simplify the figures (to
be discussed later)
... Note: previous suggested change was proposed by MChapman
... suggested change: mention the possibility that the semantic ID can be human readable/consumable
... Suggested change: allow semantics to be returned to the provider as part of the interaction with the requester
... Mike: Important to note that humans are or can be involved in Web services interactions, and to flesh out the fact that semantics are involved
... Suggested change: indicate more clearly the request /response pattern for step 6 in figure 4
... DaveO: Should be sure to include choreography in one of the scenarios
... Suggested change: Clarify discovery and selection roles in Figure 5, with respect to a set of IDs versus a single ID to be applied to the roles
... Review diagrams (as stated earlier) as part of doc reorg
<Heather> Heather agrees with Martin that there are new roles for publishing (or making available) the description of a interface(portType) and service instance(port)
<DaveH> how to complete the various work done today.
<ericn-scr> sense from the morning around refactoring the
document, could include Dave B's material during that process
... Mike: Can we harvest some concepts and relationships from DaveB's document?
... Eric: this is a step by step description rather than a single picture approach (which is kind of like what we have now)
... DaveB: Couldn't find a single picture to cover all the important topics
... Igor: Do the humans have to be there?
... Roger: Could have diagrams without the arrows, two diagrams could handle it, one with an agent in the middle and one without
... Roger: Cannot abstract humans out, have to reflect roles of the humans to have a sensible architecture
... Igor: Two diagrams, first one explains two parties interacting, beyond the technical architecture, how that happens, the second would be the dynamic diagram with three roles
... Note: terminology between DavidB's document and the arch document would have to be resolved
... MarkJ: Is this preface material to the technical part of the document? There's a severe difference in tone between the two and would be hard to just smash them together
... DaveO: Maybe not a primer, but an entirely new document? It's good explanative, descriptive material.
... Heather: Looks like scenarios
... Mike: Could be blended with scenario documents
... Zulah: Concern about supressing it into the scenario document -- might get lost
... Mike: Agree with DaveO, I really like this, good encapsulation of the human interaction use cases, stands on its own, maybe take a couple of diagrams out for the main document
... DaveH: Scanning through the main document, I find the graphics in DaveB's document to be more helpful in terms of exposing some of the important terms, semantics, roles, responsibillities of the roles - at least whoever redoes Chapter 3 should take the best of both and ensure the clarity of descriptions can be put together
... Hugo: One big merit is that it doesn't talk about technologies, as opposed to describing discovery only in terms of UDDI or other technologies, the problem wasn't described as much as the technology was. Here it's all in very abstract terms and we see what the problem is, need agreement, agents talking to each other, etc. After that we can start talking abot how technologies such as UDDI and WSDl solve part of the problem
... Dougb: One problem in the current document is that it mixes the abstract and the concrete, DaveB's document is much more consistently abstract - using this as a starting point for a separate abstract description of the architecture would be good
... Mike: Summarizing the proposals, is it a separate adjunct document, or an introduction, or what? Showing how to meet the use case requirements?
... Katia: This can represent the vision of where we want to get to with the Web in the future, evolving it toward Web services, shows the roadmap - we want to make the arch document that's forward looking, not that describes the technologies avialable today (solely)
... DaveH: I can see a new section 3.0.1 based on a cut down version of this with two diagrams, one the simplest to introduct the diagram and how it works and the most complicated following, the purpose to describe what each of the lines and roles are, serves as a definitino of terms in 3.1. That would allow us to pull out from 3.1 things controversial and unnecessary.
... DaveH: We see an evolution with respect to semantics moving toward WSD, more automation emerging -- but it gives the vocabulary to describe what's in the triangle and avoid some of the controversy. We need to keep the triangle, that reflects commercial reality.
<DaveH> ont the phone----plesase mute until dog is done
<ericn-scr> Discussion about how much of this to possibly include (one or two diagrams) and whether or not to include it within the same document.
<MChapman> haohe, was that your dog speaking?
<HaoHe> yes, he wants to join web services discussion.
<ericn-scr> Heather: How about an interaction patterns section? We had derivatives of the triangle for different interactions, not limited to MEPs, but a pattern chapter for introducing these concets progressively
<DaveH> does the dog know xml? If not, it must be a trout to join.
<MChapman> i agreed with what he said
<ericn-scr> Roger: Disagree about keeping the triangle diagrams, would like to see them gone
<HaoHe> the dog certainly know "mark-up" language, if you know what I mean
<MChapman> bark-up languages
<DaveH> He can at least chew on a bone with the best of us
<ericn-scr> Daniel: Agree this is a much better explanation,
but I don't think we can remove the triangles because all vendors are out
there promoting Ws this way
... Discussion around who is leading who here, whether we are telling the vendors what to say or vice versa
<HaoHe> I think triangles are ok but MEPs are misleading
<ericn-scr> Heather: Good experience that the triangle is
... Mike: Clarify that the discovery role is not only UDDI is positive
<HaoHe> agree with Mike
<ericn-scr> Heather: lots of value in the new diagrams, but I
don't think we throw out what we have and start with a tutorial angle instead
... DaveH: Chair points out that editors are already overwhelmed, would like to give editors a chance to include information in the document
... Eric: Feel like I have my hand up already to work on this because I said I'd work on the doc refactoring, and can take this into account
... Hugo: A problem with the triangle is that everyone interprets discovery within it as UDDI (Roger agrees)
... DaveB: Valid to map the triangle diagram to the diagrams in my text (volunteers to take that on)
... Zulah: I've sat in on many discussions with archtiects who didn't understand the triangle, and the discussion often degenerated into how UDDI works - this document is useful and valid to the extent we can put a stamp on it and let people read it we should do so.
... Zulah: We've had some discussion about refactoring the arch document, in that process we will understand who we're targeting the document, how the diagrams support it, seems like we're wasting or time till we know more about what the new document's going to look like
... Zulah: Let's get this doc out now somehow, and see how it ends up in the arch doc as we go along
... DaveO: Variety of feedback indicating that how the doc is structured does not result in the intended effect, if we're getting feedback that the triangle diagram is not achieveing its goals, the feedback is what we ought to be bringing back to the group, it would really help us move forward - encourage that more
... Roger: Data point - I'm getting people who tell me "we can't use Web services because UDDI is not mature" and I'm sick of it
... Martin: I'd like to support Heather, everywhere you go you seethe triangle diagram and we can support it through the new diagrams
... Dougb: I'd like to support Martin and Heather, the triangle diagram exists independently of our document
... COlleen: Agree with heather, martin, dougb - we need to use a well accepted context (the triangle) and supplement or explain it better
... MarkJ: I agree with the others, and the new diagrams can be used to help better explain the triangle - the two are roughly consistent, as long as DaveB or someone can tie them togehter
... MarkJ: Not an either or
... DaveH: Agree, do the triangle diagram first, illustrate some of the ambiguities, then go through DaveB's scenarios to resolve the ambiguiteis
... Frank: If you agree with what we outlined this morning about what an architecture is, neither the triangle nor these diagrams fulfill the requirement, these are usage diagrams not arch diagrams
... DaveB: I actually initially liked the triangle diagram. What happened was I tried to figure out and understgand wshat the three things really were and what they were doing, and I found I coujld not reconcile the reality with that diagram.
... DaveB: I'm willing ot include the triangle diagram and show how it relates to these diagrams, given people are using the triangle diagram
... DaveH: Can we ask you to do that within the contexdt of the doc rework, and as an editor of the doc rather than as a separate doc. ANyone object?
... Zulah: Need more work before we get to this, Eric to write the contract text and send for review, then start the reqork and evaluate the diagrams, this sounds like a different path, so I want to modify the proposal.
... DaveH: So how about when the rework gets to Section 3.1 Eric drags in DaveB to work on that part, making it a secondary role to the restructuring activity. Can always review again.
... Zulah: What would be most beneficial now is to turn this into a document that starts with the triangle document and explains what' sgoing on with the triangle diagram. So people can benefit today from this work. And then do work at the appropriate time during the restructuring.
... DaveH: If DavidB chooses to add the triangle and publish the document, that would be his perogative and apparently welcome by the group.
... Unanimous show of support for harvesting this information as much as possible during the refactoring.
... Unanimous show of support for the idea that DaveB's document helps explain the triangle diagram.
... Zulah: Critical need to get this information out for people who are trying to architect web services today, and would be good for us to post this on our website
... Mike: Find a good name for it (roadmap, patterns, introduction etc.), do some work to reconcile the terminology with the glossary
... ACTION: to the chairs to make sure the document work items are done so it can be published on the website
... Mike: Add figure 0, figure N, reconcile with glossary -- get it visible from the Web page and position it relative to the work underway
<MChapman> group of us going for mexican tonite
... Arriba Mexican Grill - Scottsdale
... Mexican cuisine
... 15236 N. Pima Road
... (480) 948-3030
... say 7:30