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
Scribe: Zulah
<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
Eric: Questions
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,
etc.
... 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
restructuring
... 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
right now.
... 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
produces
... the same results, preferably meeting or exceeding its
... specifications
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.
... http://www.reed.com/Papers/EndtoEnd.html
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
relationships
... 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
reliability
... 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.
<HaoHe> sorry
<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
relevant
... 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