See also: IRC log
Present: Abbie Barbir, Chis Ferris, David Booth, Dave Orchard, Doug Bunting, Frank McCabe, Geoff Arnold, Hao He, Heather Kreger, Hugo Haas, Igor Sedukhin, Jeeff Mishinsky, Martin Chapman, Mario Jeckle, Mark Jones, Mike Champion, Mike Mahan, Roger Cutler, Sinisa Zimek, Ugo Corda, YinLeng, Husband Zulah Eckert
Regrets:
Chair: Mike Champion
Scribe: Roger
Scribe: Telecon minutes - last week just up, several up for a
while.
... Telcon minutes in agenda are approved.
... Logistics for F2F in email from Heather but not on Web yet.
... UML description of WSDL - Martin is close to finishing.
<mchampion> http://lists.w3.org/Archives/Member/w3c-ws-arch/2003Jun/0028.html
Scribe: Sept F2F being hosted by SAP in Palo Alto.
... Sept 22-26, we are last part of week.
<hugo> Up-to-date schedule: http://www.w3.org/2002/ws/arch/admin#schedule
Scribe: No task force activity.
Issue: Nomenclature. Standardizing on names for flavors of "Web services". Mike Champion proposed some terminology.
Scribe: http://lists.w3.org/Archives/Public/www-ws-arch/2003Jun/0083.html
... Intention of names are to establish context for Web services, but out of
scope for WSA.
... Martin - why use term WS?
Mike: Only used it in "minimal WS"
Scribe: Used "Service" for other ones.
... e.g. HTTP service.
... XML HTTP service.
... DaveO - What about Web Resource.
... DBoooth - Resource is anything.
... Mark - How do we distinguish app<->app.
... Orchard - only call Web service if use WSDL / SOAP.
... Otherwise Resource.
<dbooth> "Web resource" would (presumably) also include static documents
Scribe: Roger - app<->app is important.
... DBooth - Web resource encompasses static documents.
... DBooth - call out resources that are services.
... Chris - how does consumer know if it is static?
... Robots.txt is an example.
... DBooth - It's a qualitative difference.
<geoff_a> What would be the geopolitical effect if WSA chose to define "web service" in such a way that it excluded a substantial fraction of what John and Jane Doe think of as "web service"....?
Scribe: MarkJ - suggests app to app resource.
... Chris - html with stylesheet - one made for person other for app.
... MarkJ - Designed for human consumption is a reasonable distinction.
Scribe: Orchard - had counterproposal to Mikes - "resource"
... Mike - What is a "service" -- without the "Web"?
... DO - service tends to be app to app.
... Service on the Web vs Web Service.
... I think that came from DO.
... Frank - So what if robots.txt is out there? Our focus is getting the app
stuff right.
... Frank - We don't need to define what we don't define.
... Chris - Agrees with Frank.
... Chris - say don't preclude other things on the Web - knock yourself out.
... Just other stuff, out of scope.
<mchampion> roger: this is something that many people call "web services" so we have to say something abou them. Proposing a nomenclature would be useful to real companies
Scribe: MarkJ - Given huge amount of discussion of Rest arch styles
for services would be huge mistake to ignore as point of reference and
comparison.
... Also don't need to shoehorn it into a standard WS stack.
... Chris - Agree don
... 't want to consider Rest style out of scope.
... Sorry.
<MChapman> +1 to chris
Dougb: Spending a lot of time discussing terms that are out of scope.
Scribe: Headed toward conflict with TAG.
DOrchard: All agreed SOAP and WSDL are what we care about. Having difficulty with case where a reasonable service doesn't use S/W, how do we deal with that.
DO: One solution: Don't even talk about them. Other position: Real
world doesn't see world so simply.
... If we just ignor it then we do a disservice to the community.
... Nobody wants to spend significant amount of time working on non-SD
architecture. Just want a context.
<Mark_J> +1 to DO
DO: Bunch of things we aren't doing, but this is one where people think we ARE doing it. Doesn't need to take a lot of time and space in doc.
<dbooth> I.e., "Acknowledge them and move on"
Geof: If WS definition excludes significant portion of community this would be a disaster.
Geoff: Identify broader class but don't talk about it in detail.
Chris: Doesn't object to ... but ... I'm sorry, I didn't get that.
Doesn't want to have exhaustive list of things not doing.
...
... Wants to limit scope.
DO: Why is XML communication "boiling the ocean"?
<mchampion> ACTION: mikec will re-draft his "nomenclature" proposal in light of this discussion and propose a specific place in the document for it
Mike: out of alloted time.
Scribe: ACTION: Mike will redraft paragraph in light of this discussion.
Scribe: Intro, stepping stone to dictionary.
Scribe: New one posted a few minutes ago.
... Open issues?
Martin: People need to review and comment, build up ambiguity list.
... Multiple receivers OK, but is it one path, many r's or many paths, one R
each?
Scribe: ACTION: Martin will collect group expressions of ambiguity for presentation to XMLP.
Martin: Should not be overly pedantic about every nook and cranny.
... Don't get too picky.
Chris: Not everythign that we might describe is relevant.
Mike: Is the spaghetti diagram a UML diagram with a lot of detail
suppressed?
... S.D. and UML two views of same concept.
Frank: Concerned about large scale diagram vs detailed slice. Wonders whether UML can do the large scale.
Mike: Practical matter might not be able to do whole thing in UML.
Roger: How do we avoid getting bogged down in detail?
Martin: Choice of level of detail that is presented.
MarkJ: Cannot eliminate all cardinality. Sometimes it's prominent issue.
Martin: Can delete some of the boxes and associations and leave the important ones.
DaveO: Is there a process that we can institute?
<MChapman> +2 to do
Dorchard: No reasonable process -- have to use brains.
Mike: Suggestions for excessive detail? Give Martin some guidance, please.
Scribe: Want an architectural diagram, not UML for SOAP.
Chis: Is not the Sp.Dia. the extracted view of the UML?
Martin: Need to converge.
Chris: Two diagrams or one?
Frank: Many.
Mike: Conceptually the same thing, but different view.
Martin: One diagram in principle.
... Someone should build the complete model in some computer.
Frank: Bunch of SOAP-specific stuff in this diagram. As WSA
architecture some of it may not be the right thing.
... A lot of detail, but also a level thing. Same word shows up as SOAP
artifact and in WSA with different scope.
... Property and Feature. SOAP property and feature. We have WSA feature.
Is that the same thing?
Scribe: Jeff - This will fall out when we do the work.
Mike: If the SOAP property and feature is different will have to resolve somehow.
Martin: Will get interesting when put SOAP and WSDL on same diagram.
<Hao> do we have a url to the diagram?
MikeM: Need to take bottom up and validate Sp. Dia - validation.
Scribe: Sorry, Mike. That's not what you said.
Chris: Putting SOAP and WSDL together is huge part of our work.
Scribe: Ooops, who was that who gave the +1?
Chris: Union diagram is probably going to get out of hand. Want chunks in individual diagrams. Do not like removing things.
DaveO: Has tool?
Mike: Geek value in XMI of architecture.
Martin: You can export from Visio.
Mike: Should think about what nodes to extract for SP Diag.
... Martin and MikeM are working on WSDL part.
mikeM: We're working on it.
Mike: Wants to discuss topics to consider -- what is in scope and what is too detailed?
Scribe: Which of the concepts in WSDL UML diagram are things we want to capture?
Mike: Maybe TargetResource maps onto something in our architecture.
... Actually point of TargetResource is something we should not try to
constrain.
Scribe: Huh?
... ACTION: Mike will make sure the WSDL targetResource discussion and
conclusions, will be harvested into the document.
Service: What of the WSDL view is detail and what is architectural?
DaveO: Proposes considering everything in SOAP and WSDL to be architecturally important.
Scribe: At least as starting point.
Frank: Meshing WSDL and SOAP is good thing. Big diagram is OK.
Risk: May miss something important that affects entire enterprise.
... e.g. REST, where would that fit in?
... We have more to do than combining the details exposed by SOAP and
WSDL.
Mike: Stakeholder part of the document can be used for this. If I am developing RESTful app, how does that relate to WSA.
Frank: Example - Suppose adopt resource viewpoint, everything has ID etc, then need to represent core concepts in architecture. Don't have much to do with how messages are packaged or described,.
Scribe: Risk that we will miss bigger concepts.
DaveO: Concern is that we will miss things. Probably we will. Probably will be pointed out to us.
ChrisF: Agrees.
Martin: SOAP/WSDL model is a starting point to work out from. Need
to factor in Reliability, Security, transactions, etc.
... More difficult because there are competing specs. Use this as core.
<mchampion> chris said something I found important: when people note "bugs" in our component model we can decide whether it is a missing concept or relationship, or an analysis we need to do, or what
DBooth: TargetResource is something important but semantics are outside WSA.
Roger: Is shell of turtle = Agent in WSA?
Mike: WSDL people seem to find this too restrictive.
... WSDL people really care about what has identity. We may wish to identify
things architecturally that might not translate to identity.
DBooth: Is the TargetResource the agent? No. Could be, but not necessarily.
<jeffm> that is correct - not the agent
Mike: We need the shell of the turtle somewhere.
<fgm> I recommend abandoning the term 'shell of the turtle'
DaveO: ... Wants to include SOT. Use case for why WSDL has TargetResource is interesting architecturally. Important to WSDL group.
Scribe: Need to show relationship between these various concepts. Will help community.
DaveO: We should provide context for these "realm people".
DBooth: Should indicate it in arch even if not much can say about it.
Hao: I'm sorry, I didn't catch that.
... Start with more basic WS concepts, rather than SOAP/WSDL specifics.
... e.g. Kind of server???
<dbooth> Hao: We should start with more basic WS concepts, such as client and service and discovery.
Scribe: Sorry - I had trouble hearing that.
... I'm sorry, I have a meeting in 2 minutes that I must attend, because they
intend to grill me.
... About something I know NOTHING about. Sigh.
... Thanx.
<dbooth> ChrisF: As we extend beyond SOAP and WSDL and
consider security, etc., and especially semantics, that's where the
targetResource becomes more relevant, and it will help the world to address.
... Mike: What about the code that does something? E.g., printer driver?
... ... Or do we just say there's a SOAP interface with a black box?
... DOrchard: I think we should talk about it.
... MikeM: Is this different from agent?
... MikeC: The shell of the turtle is the agent, the guts is the thing behind
it.
... MikeM: That sounds consistent with the TAG.
... MikeC: We need to map "Legal Entity" and these other concepts onto each
other.
... MikeM: On the SOAP UML diagram, someone suggested validating it.
... ... Was that a proposed action?
... MikeC: Martin might do it. There seemed to be ambiguities. Are they
ambiguities in SOAP itself? Or are they artifacts of the UML diagram, or
modeling errors?
... ... We first need to come to understanding. If we find things we really
don't understand, then we need to raise them to the SOAP WG.
... MikeM: I was thinking of the cohesion of XMLP and WSDL.