See also: IRC log
Present: Abbie Barbir, Chris Ferris (remote) Dave Hollander, Dave Orchard, Doug Bunting, Kevin Liu, Martin Chapman, Mark Jones (remote), Mike Champion, Mike Mahan, Roger Cutler, Davie Booth (remote), Eric Newcomer (remote), Hugo Haas, Jeff Mishinsky, Paul Denning (remote), Ugo Corda (remote) Yinleng Husband
Regrets:
Chair: Mike Champion
Scribe: various
<mchampion> ACTION: Concept "endpoint" needs
to be added
... ACTION: Concept "interface" needs to be added
... ACTION: 2.2.31 Service needs to be reconciled with WSDL 1.2
... ACTION: UML diagram for service drawn in Rennes needs to be incorporated
into text
... WSDL: "A service is a collection of endpoints bound to the same interface
and therefore the same resource"
... "Resource" in the WSDL sense can't be used in our document without
qualification.
<DaveH> http://dev.w3.org/cvsweb/~checkout~//2002/ws/desc/wsdl12/wsdl12.xml?rev=1.67&content-type=text/xml
<mchampion> Noted that the term "resource" in discussions of
WSDL does not refer to the same concept in our document (and the Webarch)
... Doug: Are we incorporating WSDL 1.2 normatively? If so, what does that
say about WSDL 1.1's conformance with WSA?
... Martin: This also rules out conformance with ebXML, since it has no
concept of endpoints
<hugo> WSDL text: "Interfaces offerred by a resource MAY be
related to each other, but this specification is NOT defining what those
relationships might be." they are related since they access the same resource
... WSDL text: "Corollary: one URI MAY be associated with multiple endpoints.
Typically this will NOT be the case." not clear
<DaveH> Proposal: section 2.2.31 summary: A service is a collection of endpoints bound to the same interface and therefore the same resource.
<hugo> DaveO: I don't want to talk about the resource because we can't access it
<DaveH> A service is a collection of endpoints bound to the same interface and are *equivelent*
<hugo> *equivelent* needs to be defined
... Martin: *equivelent* can be defined as being offered by the same agent
... No consensus on Martin's proposal
... DaveO: that refers to semantic equivalence
... A service is a collection of *equivalent* endpoints bound to the same
interface.
... above is the modified proposal
<dougb> A service is a collection of *equivalent* endpoints *bound* to the same interface.
<hugo> Proposal #4: A service is a collection of *equivalent* endpoints *bound* to the same interface.
<dougb> [pls note: above was friendly amendment from Hugo]
<hugo> *foo* needing to be clarified
... Consensus of the WG
... Discussing the relationships for services
... DaveH: should we get rid of tasks?
... HugoH: it is related to *equivalent*
... RogerC: I disagree that we should get rid of it
... ... there is a high level goal for a service, and a set of smaller atomic
goal
... DaveH: service is probably not at the top
... MartinC: we have discussed the WSDL model which is the service provider's
view
... MikeC: we are talking about operations here, and the service task isn't
relevant here
... RogerC: but the operation actually does something
... DaveH: the proposal is to remove performing tasks
... RogerC: and it will go somewhere else
... DaveH: yes
... Accepted and draft modified
... DaveH: what about description?
... ... options:
... ... do it hierarchically
... ... do it at both ends
... ... in modeling, one usually define from top to bottom (paraphrase from
scribe which probably isn't 100% correct)
... Proposal: a service is described by a service description
... Martin: a service has a service description
... BREAK
... RECONVENING
... DaveO: we need to go further down certain paths
... DaveH: we need to start nailing down a concept first and walk down the
tree
<mchampion> Daveh: We're nailing jello to the tree, and it's
hard. Try to hold off discussion of other bits unless it is necessary ... "I
can't answer X until I understand Y"
... Doug: have parallel conversations on IRC or in the hall
... Martin: it's hard to work from document as starting point when we really
don't have consensus on anything.
<hugo> MikeC: there are several notions of service floating
around: wsdl:service element; what the WSDWG calls a resource
... DaveH: let's start bottom up with a WSDL:service
... Proposal: create a new WSDL:service-
<mchampion> ...and what WSDLdoesn't name, but we are
tentatively calling frank:service, a more abstract, semanticly rich notion of
service.
... a frank:service has-a description, and a wsdl:service is part of that
description
... Now reviewing wsdl:service ...
... wsdl:service part-of a service description
... Roger: a wsdl:service is the concept of a set of enpoints, it has-a
description
<hugo> We need to define the "has a" relationship
... Discussions about the relationship between a Frank:service and a
WSDL:service
<mchampion> Two different drawings in green and red from Mike
and Martin, same concepts with different relationships
... Martin sees a frank:service as having a collection of endpoints that in
turn have descriptions
... Mike sees a frank:service as having a description that has a collection
of endpoints
... Martin believes that Mike's warm fuzzy "description" thing mixes up types
and instances of wsdl:service
... Martin: we need to distinguish a frank:description from the wsdl:
description
... Hugo: the frank:description is more semantic
... Martin: the frank:description is missing from WSDL, maybe they should
have a placeholder?
... Martin: let's just leave all of this as some fuzzy "description" and sort
out relationships later
... a wsdl:service is described_by a definition
... ACTION: the current definition of HAS-A needs reconsideration
<DaveH> Proposal: sectioin 2.2.39.2 - A wsdl:service is
*associated with* a *wsdl:description*
... Proposal: section 2.2.39.2 - as wsdl:service is associated with a
*wsdl:description*
<mchampion> Real-time changes to the document being discussed and voted on.
<DaveO> I heard: the definition will be "english", as in "service is a. " and then the relationships are in "modelese", as in a service has a ... and has a ..
<mchampion> Long discussion of is-a and has-a versus English words "is" and "has".
<DaveO> should have explanation of the use of english vs modelese ....
<mchampion> ACTION: the editors should ensure that the definition will be "english", as in "service is a. " and then the relationships are in "modelese", as in a service has a ... and has a ..
<DaveO> We need to think about is-a definition: Does it mean substitutability or equivalence?
<mchampion> Martin: we may just want to use UML's definitions rather than invent our own.
<cferris> +1
<mchampion> Process discussion of how to get agreements and stick to them so that people who didn't dissent during a vote can't re-open ratholes
<DaveO> As well as the decision about the way to describe things....
<mchampion> Martin: chairs need to clarify what the process
is
... Martin: need to get more concrete about votes, good standing, etc.
... DaveH: Need the discipline to not re-raise issues without researching
previous decisions
<MChapman> we also need to collectively remember and remind each other of past decisions
<hugo> going back in time: 2.2.39 proposal was accepted by the group
<mchampion> ACTION: Chairs will begin
notifying people of lack of good standing and applying W3C rules consistently
... Note: the reason the chairs haven't bothered before now is that we
haven't been taking votes.
... ... because we have been trying for consensus
... Long discussion of "vote" vs "consensus" and what constitutes a
"decision"
<hugo> RECONVENING
<MChapman> Review of decisions and actions
<hugo> Projecting http://dev.w3.org/cvsweb/~checkout~/2002/ws/arch/wsa/wd-wsa-arch-review2.html#wsdlservice
<MChapman> DECISION: need two different service concepts
currebtly called wsdl:service and frank:service
... DECISION: Need better words for wsdl:service and frank:service
<cferris> please see my recent note: http://lists.w3.org/Archives/Public/www-ws-arch/2003May/0221.html
<MChapman> DECISION: agreed to section 2.2.39 in link above, while undersating that wordswithing and some sub sections need completing
<cferris> I think that it is a mistake to allow concrete things into conceptual part of spec
<mchampion> Chris -- "wsdl" is more of a namespace than a concrete thing in this context. Theree was a discussion that the section called "service" was overloaded, it referred to both the abstract notion of a service and the abstract notion of a service description
<DaveO> Chris, I think the reason is that we do need to "concretize" what we mean by service, endpoints, etc. It just so happens that WSDL will define these things as well. Unless you are suggesting that we should have different definitions that wsdl 1.2.
<cferris> no, I am not suggesting that we and wsdl12 have differing definitions
<mchampion> We were inspired by our discussions with WSD yesterday, but are not pointing to their concrete "thing"
<MChapman> we are conceptualising the wsd model
<cferris> if the point is that the concept of service should
be in terms of hasa versus isa then we should simply give that feedback to
the wsdwg
... it would be a mistake if wsa had differing definition
... than wsd
<MChapman> yes its should be the same modelk and defintions
<mchampion> We tookk the WSDL 1.2 draft verbiage, put into
the context of our previous model and sketched out a "UML" model of that
... A) we only talked about section 40, not 37-38; b) in 40, the editors are
directed to find a better "conceptual" name for wsdl:service c) we chose the
prefix "wsdl" to note that it was aligned with the WSDL conceptual model
... It sounds like you agree, Chris? Net of wordsmithing, of course ...
and
<cferris> then call it a service description
... not a wsdl:service
<MChapman> not its not the decription
<DaveO> Going to talk about the "thing" behind endpoints. WS-RM uses the term "ultimateReciever" and "initial sender".
<MChapman> its the concecpt of the servce being a calooection of endpoints
<DaveO> oh, guess not yet talking about the "thing".
<cferris> is it an isa or hasa
... ?
... a <foo> is a collection of endpoints
... or
<DaveO> Chris, my interpretation is that our formal definition is "has-a".
<cferris> a <foo> has a collection of endpoints
<MChapman> a wsdl:service has_a collection of endpoints
<cferris> right
<MChapman> a wsdl:service has a description
<jeffm> +1`
<cferris> no, a wsdl:service is a description
... or a component of a description
<MChapman> no that is not the model we agreed
<mchampion> Roger: why not call it wsdl:service -- answer (agreememnt with Chris) ... and to emphasize that we are not tightly bound to WSDL specific syntax/namespace/etc.
<cferris> then a wsdl:service is a service
<MChapman> wsdl:service is just a name it os not the same at the wsdl:servuce element
<cferris> then don't use that name
<mchampion> We are agreeing with you :-)
<MChapman> we are now
<mchampion> mikem, daveo: we are tightly coupled to WSDL, why not just admit it?
<cferris> +1
<mchampion> hugo: proposes that frank:service ->web service, wsdl:service becomes service
<cferris> +1
<mchampion> jeff: So are we just doing a UML model of WSDL 1.2?
<cferris> oh, wait...
<mchampion> DaveO: yes
<cferris> why is wsdl service now just service?
<mchampion> Jeff: we should be suppressing details, just
emphasizing architecturally important aspects
... daveh: not inclined to spend too much time on names now
... daveh: not inclined to import WSDL model directly
... roger: If we're bound to wsdl, let's call it wsdl:service and the thing
above it as wsa:service
<cferris> I think that it would be a serious mistake to have 2 disparate terms
<mchampion> roger: strongly opposed to hugo's proposal because "web service" is a non starter
<MChapman> chris, there are two conpcepts 1) a coolection of
endpoints to the "same" interface 2) a collectin of those collections
... 2) currently hsnt been named by the wsd group
<cferris> thought they agreed to add resource attribute
... a resource may have multiple interfaces
<MChapman> that is a mechanism that reprsesent the concept
<mchampion> daveo: what we care about are exactly the things that WSDL defines. The fact that the relationships exists, their cardinality, etc. are concretely what we are describing
<DaveH> - q
<MChapman> now interface is being used as both the wsdl
interface element and now "access points" to a resource
... they are different concepts
<DaveO> Martin, what they are different concepts? The notion that our service is different than a service as understood by wsdl seems very bad to me.
<cferris> daml-s
<mchampion> mikem: in same mindset as DaveO ... WSDL itself is metadata, at a good level of abstraction, doesn't see other description languages on the horizon
<cferris> agree with mikem and daveo
<MChapman> see above concept 1) a collection of endpoints with same interface 2) collection of those collections
<cferris> daml-s and wsdl are fairly similar... my understanding is that they could be mapped
<mchampion> mikem: is it part of our charter to describe WS abstractly enough to cover daml-s
<MChapman> confusion is the term interface
<DaveO> Martin, #1 is a service, #2 is a TBD service. IMO, #2 is a "Web service"...
<bijan> Katya is on that, so it might be worth asking here about alignment issues.
<mchampion> martin, mikem: distinction between modelling data
and software?
... martin: trying to build a model, and these things have descriptions
...
<cferris> we have 2 definitions of "~service", they are quite different
<DaveO> I assert: WS-Arch's conceptual model of web services must map directly to WSD. Any changes in WSD must be reflected in our model, and vice versa.
<MChapman> but we are agreeing chris there are two defitnions of service whioch are different - maybe we should use two tersm
<mchampion> chrisf: it would be a mistake to have two
different "service" types, we have to realize that we are dealing with Web
services not other stuff. We should be consistent with WSDL, if we discover a
problem tell them.
... chrisf: Let's not boil the ocean ...
<MChapman> we are not arguing
<DaveO> +1 to what mike will now say...
<MChapman> we just identified two concepts that we need terms
for
... we propossed working terms, actuall terms tbd
... maybe our choice i.e. wsdl:service wasnt the best!
<mchampion> chrisf: doesn't think there are really two
concepts here; MikeC summarizes previous discussion
... Daveo: collection of endpoints and collection of collections came up in
WSD meeting, no name in WSDL for the collection of collections
... chrisf: we should be building off wsdl model and pushing back if we have
problems ...
... chrisf: if the second definition of service is distinct, it is misnamed
... daveo: we would be happy if frank:service and wsdl:service collapsed ...
but we have the intuition that they have different attributes and
properties
<MChapman> +1 to daveo
<mchampion> daveh: metamodel of a metamodel is similar to UML
MOF ... fact that they did it created much controversy
... daveh: why does daveo think we inherited a concrete schema from WSDL
since that's not in the (sortof) approved text
... davo: we are coupled to the representation of their model, of which their
schema is the expression. That's what we should be coupled to.
... daveo: We're getting to a consensus, believe it or not: there's a
relationship between the WSDL model and our group; WSDL can talk about
service as collection of endpoints...
... WSDL doesn't need to talk about resource behind service or collection of
services, and we must talk about them. Maybe they can be collapsed, but
let's analyze relationships first
<cferris> wsdl has a component model
<MChapman> it does?
<DaveO> Martin, you keep on asking about other people's words for "models". I turn the question around. Please enumerate the "models" that you see are in scope for ws-arch, wsdl, and soap.
<cferris> in wsdl, the components are types, message(which may be dropped), interface, binding, endpoint and service
<mchampion> dougb: we need a name for "service that is a subclass of agent"
<DaveO> btw, I've heard the following types of models are available: data, vertical, domain, component, logical, component, physical, abstract, concrete.
<MChapman> chris, thanks for that clarification, a lest you didnt meant component model in terms of com or corba components
<mchampion> martin: we're trying to identify concepts of interest; when it matches wsdl, use the wsdl term, otherwise assign moniker
<MChapman> daveo, the model we have been developing is class diagram
<DaveO> Is the class diagram the "type" of diagram, or is it an instance?
<MChapman> class diagrams lets you model "entities" for want of a bettter word and the relationships between them
<mchampion> DECISION ?: need two different "service" concepts
currently called wsdwg:service and tbd:service
... DECISION ?: need a concept wsdwg:service that may be separate from
tbd:service
<MChapman> we are trying to serialize the discusion
<cferris> I think that what we *need* is a single definition for the term 'service'. I think that before we decide that there are two terms, that we first make a reasonable attempt to reconcile the two. IMO, that reconciliation ned not be deferred til we get (back) to that section
<DaveO> The reason I use the term domain model is because of sites like http://c2.com/cgi/wiki?DomainModel
<MChapman> i like domain model as well
<bijan> Aren't you reviewing the reviewing of a decision as
to what the decision might have been?
... I may have missed a level or 12 of recursion...
<Roger> If you can distinguish two interfaces as being different, then you cannot avoid saying that tbd:served and wsdwg:service are different concepts.
<mchampion> DECISION ?: need a concept wsdwg:service that may be separate from tbd:service
<cferris> -1
<DaveO> I also proposed that we may remove the wsdwg: once we talk about tbd:service.
<Roger> bijan, yes, I believe you are correct.
<mchampion> DECISION ?: need a concept wsdwg:service that may be separate from service collection
<bijan> VICTORY!!!
<MChapman> we started revieving the term service decided it
wasnt the same as wsdwg:service so decided to adda new section
... its the new section we are trying to agree words on
... not the existing service section
<mchampion> DECISION (with 1 dissent, which has been recorded): need a concept wsdwg:service that may be separate from service collection
<hugo> Note from editor: I have s/Service/TBD:Service/ and s/WSDL:Service/WSDWG:Service/
<cferris> but the new section currently says: A WSDL:Service is a collection of *equivalent* endpoints *bound* to the same interface.
<MChapman> so what is wrong with that chris?
<frankmccabe> knock, knock
<cferris> nothing, but it is basically the same as section
2.2.31
... just uses different terms to say the same thing
<frankmccabe> is the bridge open?
<cferris> yes
<MChapman> but we havent re-worked 2.2.31 and if we find
there are no differences it will be collapsed
... i think wea re just trying to serialze the discussion
... which may not be working
<mitrepauld> I've been reviewing the IRC, and now have dialed in.
<ugo> where is today's IRC record?
<mchampion> ACTION: we will table the decision on using IS-A and HAS-A until we review UML definitions
<cferris> http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl12/wsdl12.html#web_service
<frankmccabe> UML does not define ISA or HASA
<mitrepauld> UML spec at http://www.omg.org/cgi-bin/doc?formal/03-03-01
<mchampion> ACTION: whoever finds a good
definition in the UML domain, please post to IRC or mail so that we can work
off a single normative reference
... DECISION ? We will not define our own modelling terms
<cferris> +1
<DaveO> figure 2 is fascinating.
<dougb> ++
<MChapman> uml isa is generalisation (ingheritance) and hasa is aggregation
<mchampion> DECISION ? We will not define our own modelling terms, thus will remove definitions of isa and hasa from wsa document
<frankmccabe> this is not a pond, but a black hole
<DaveO> service1 and service2 are part of a "servicecollection", ie resource1 and resource 2 are service collection types.
<cferris> don't understand service collection types
<DaveO> It's a term that I just freaking well invented.
<dougb> don't we have a requirement not to reinvent the wheel somewhere?
<MChapman> but this time it should be square
<mchampion> frank: UML is no more rigorous than anything
else!
... mikec: the point is that it is a widely acknowledged convention and will
be less confusing than inventing our own terms
... jeffm: UML people debate semantics, but for drawing pictures it's good
enough
<DaveO> How about we adopt UML in a very limited sense: for doing class diagram pictures and for defining relationships on class diagrams?
<mchampion> DECISION ? We will not define our own modelling terms, thus will remove definitions of isa and hasa from wsa document
<MChapman> the class diagrams give us enough rigor to describe the domain model we are building
<mchampion> ACTION 9: Frank will find a good definition of IS-A and HAS-A in the UML domain and suggest for our normative definition
<dbooth> http://www.w3.org/2002/03/RRSAgent.html
<frankmccabe> I will take on the action to find good
references to isa and hasa.
... With particular reference to UML
<mitrepauld> UML "generalization" - section 3.50 of UML 1.5 - aka inheritance, or "is-a"
<hugo> BREAK; reconvening in 10 minutes
<dbooth> http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl12/wsdl12.html#web_service
<MChapman> has_a is the same as aggregation in uml - section
3.48 on page 3-81 in http://www.omg.org/docs/formal/03-03-01.pdf
... is_a is the same as generalisation in uml - section 3.50 on page 3-86 in
http://www.omg.org/docs/formal/03-03-01.pdf
<bijan> Oh thank you
... It was killing me trying to find them in that document
<dbooth> http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl12/wsdl12.html#web_service
<bijan> aggregation::=a way that one class can refer to
another class without having possession of it + a weak form of 'has-a'
... may be useful: http://www.csci.csusb.edu/dick/samples/uml.glossary.html
<MChapman> so a clarification: has_a and is_a are tersm not used in the uml spec itself so for the purpose of our doc we should state that is_a = uml generalization and has_a=aggregation
<bijan> Note: there are multiple sorts of aggregaton *in
uml*, and even more in general
... In the above mention glossary, aggregation is defintion 10 and
generalization def 36
<frankmccabe> What was the pushback from WSD on resource?
<mitrepauld> bijan's link talks about AKO and APO. Also, composition = strong APO, aggregation = weak APO. Do we need to distinguish?
<bijan> But I'm finding it comprehensible :)
<frankmccabe> I can't see where Mike is pointing!
<bijan> Tutoriallike discussion of aggregation, generalization, and some more relationships: http://www.csci.csusb.edu/cs202/uml1b.html#Special%20Relationships%20Between%20Classes
<dbooth> Ugo, I think you're right that the targetNamespace
identifies the *collection* of services (diagram 2).
... (I think the document simply isn't fully consistent yet.)
<bijan> Er...doesn't a namespace uri identify a namespace?
<mchampion> discussion of WSDL "REsource" given the moniker "X"
<bijan> ANd a namespace isnt' a collection of services or
even one service
... But rather a collection of names?
<mchampion> We have agents, frank:services, and webarch:resources that need to be related somehow
<mitrepauld> is targetNamespace the type or class of service, and endpoints refer to instances of that class?
<mchampion> also receiver, instance, ultimate receiver, consumer ..... these are terms out in the industry for maybe this concept X
<dbooth> Bijan, see second paragraph of 3.1.2 of http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl12/wsdl12.html
<mchampion> also "application"
<bijan> Eek.
... Though, I don't see how you get from that lanague to identifying a
collection of services
... where by "identify" I mean "denote"
<mchampion> If two wsdwg:services use the same resource, what is the container that unifies them in the WSA?
<bijan> The targetnamespace "represents" to the semantcis of the wsdl documents' infoset
<dbooth> no, "identify" doesn't mean "denote" here. ANd
you're right that it doesn't say "collection of services". I'm guessing
based on the recent addition of figures 1 and 2.
... yes
<bijan> It "points to" a document that directly or indirectly
defines those semantics
... Now those semantics probably pick out at least one service
<dbooth> "should", in the same sense that a namespace URI "should" point to a document describing that namespace.
<bijan> I.e., the services which that document/semantics is
true of
... So, yes, the namespace will identify, via the semantics it "represents",
a colelction of services
<cferris> a namespace URI doesn't "point" to anything
<bijan> Hmm.
<mitrepauld> has wsawg discussed figures 1 and 2? Fig 1 = http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl12/wsdl12.html#web_service_fig1
<bijan> actually, maybe
<cferris> if anything, an namespace URI identifies a namespace
<bijan> Aha, mchampion is on it
... cferris: check the scrollback :)
<cferris> we should be using the term resource that web arch uses
<dbooth> chris, http://www.w3.org/TR/webarch/#pr-describe-resource : "Resource descriptions: Owners of important resources SHOULD make available representations that describe the nature and purpose of those resources."
<bijan> And attempted yesetereday to sync WSD use of the term with TAG used thereof
<cferris> you said it did
<bijan> This discussion, from my observer perspective, is the ongoing attempt to get the sync up.
<jeffm> I am now beginning to think that the use of the term "resource" is a bit of a red herring
<bijan> beginning? :)
<cferris> proposal: a service collection is two or more
services that each have distinct interfaces, but that share the same
underlying resource
... I should point out that WSDL permits multiple <wsdl:service>
elements
<mitrepauld> Do we need to address cluster - load balancing - replicated database backends, different web front ends - same resource?
<cferris> I think that that is an implementation detail
... I should also note that with inheritance of interface as currently
prposed in wsdl1.2 that you can have:
... <interface name="I1" extends="mgt:Manageble"/>
<mitrepauld> Conceptually, if the virtual database is the resource, I can have Interface-1 in Chicago and Interface-2 in Boston; or UDDI via IBM, UDDI via MS (same "registry", registry is the resource)
<cferris> yes, and (as I understand) they would share the
same value for wsdl:service/@resource
... they might also share the same targetNamespace and wsdl:service/@name and
have different values for wsdl:service/wsdl:endpoint/wsdl:address
<mitrepauld> In contrast, Chicago (Interface-1) may provide access to Resource-1 (e.g.,Chicago product inventory), but Boston (Interface-2) provides access to Resource-2 (e.g., Boston product inventory)
<cferris> right
... but in that case, they have a different value for wsdl:service/@resource
(IMO)
<frankmccabe> what is the purpose of identifying two `things' as being the same?
<cferris> a service is identified not by a targetNamespace but by a QName that has a namespace name of the targetNamespace and a local name of the wsdl:wsdl:service/@name
<mchampion> s/wsdl:service/wsdwg:service/ :-)
<mitrepauld> chris, you mentioned wsdl:service/@resrource, but I don't see @resource described here http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl12/wsdl12.html#Service
<mchampion> jonathan: suggests that WSDL isn't rich enough to
describe this scenario, and shouldn't be. Maybe RDF can handle it!
... jonathan: wsdl will describe collections of services via a "resource URI"
but that's all
<cferris> paul, this was added as a result of this week's wsd wg f2f
<mitrepauld> oh, I missed that.
<DaveH> Ugo, the chairs have determined that the description of the impacted resource is relevent topic for discussion
<cferris> paul, see http://www.w3.org/2003/05/12-ws-desc-irc
<mitrepauld> so for UDDI (UBR), resource="http://uddi.org". Separate WSDL files possible for different interfaces (inquiry, publish). inquiry WSDL could have endpoint for IBM, MS, SAP, NTT.
<cferris> yes
<mitrepauld> Collection is set of WSDL files with same @resource
<cferris> not wsdl files, but wsdl:service
... could be in the same or different files
<mchampion> jonathan: all this is for description purposes,
not for talking to
... jonathan: allows WSDL to tell whether two services are related
... Jonathan: another way to do this is with a service collection
<mitrepauld> right, but we don't need to constrain collection to a single file.
<cferris> correct
<mitrepauld> @resource is a collection identifier in some sense.
<mchampion> jonathan: use case -- "I have this printer, find me the wsdl file with the management interface for it"
<cferris> the way that this discussion is headed, the issue is not one of description but of discovery
<mitrepauld> Collection of UDDI inquiry endpoints for different resources? (UBR, private registry #1, private registry #2, etc.)?
<cferris> "find me the management interface for this
resource"
... that's discovery not description
... I believe that the addition of wsdl:service/@resource enables this sort
of discovery
<mchampion> jeff: another use case is "i get handed a service references to two things, are they operating on the same entity".
<cferris> and that there is no need of a WSDL conceptual component for service collection
<mchampion> MikeC: "I have a management interface and a bunch of printer interfaces, which jobs will I kill if I shut down the printer"
<mitrepauld> so the term "collection" should exclude discovery. Collection -> same resource. Discovery -> possibly different resources.
<frankmccabe> Of course, the question that is being begged here is `is there exactly one resource being manipulated by a service?'
<mchampion> yinleng: usage scenario - "if you have 100 printers, what do I call the collection of them"
<cferris> a printerGroup
<mchampion> chris: this is a problem of discovery not description
<mitrepauld> different resources (printers), not a "collection".
<dbooth> +1 to cferris
<mchampion> chria: this gets into application space ...
"printer group service"
... chris: should we use target namespace? No.
... Chris: just needs a resource URI or whatever on "wsdwg:service" and apps
can do all these use cases
<dbooth> There could be many axes for defining collections of services.
<mitrepauld> printerGroup = resource (abstract), not a resource with sub-resources. resources not nested. same issue as http:www.foo.com refers to an abstract resource, http://www.foo.com/database is a different abstract resource.
<mchampion> chris: ack mchapman
... jmarsh: the idea of the resource URI was to allow other apps to reason
about relationships, not to support relationships
... jmarsh: target namespace doesn't work because the "what" and "How" axes
are orthogonal
<cferris> +1 to jmarsh
<mitrepauld> management interface - targetNamespace#1, security interface - targetNamespace#2. Resource#1 and both a management interface and security interface. Same with resource#2.
<cferris> exactly
<frankmccabe> Is a collection an aggregate?
... Is there a one-to-one correspondence with services and resource?
<mchampion> Most besides Chris and Frank seem comfortable with the idea of putting ServiceCollection in WSA as a concept ...
<DaveH> not really...don't object but doubt it will be a principle concept
<mchampion> frank: but for management purposes a servicecollection concept might help
<mitrepauld> Lump under "discovery"
<cferris> +1
<mchampion> daveh: this collection stuff will be useful when we start mapping services onto larger domains
<cferris> requirement for discovery: discovery should allow one to find the services that relate to the same resource
<mitrepauld> Make sure WSDL provides what is needed to do discovery
<mchampion> DaveO: "target" is a good word for the "wsdl:resource" concept.
<DaveH> why are we fixated 0on the collection when I thougtht we were trying to characterize the target-turtle
<mitrepauld> @resource does what Chris wants to find different services for the same resource.
<DaveH> what is @resource?
<cferris> wsdl:service/@resource
<mitrepauld> right
<dbooth> "Given a WS, find other WSs that are related to it according to some criteria"
<cferris> right, discovery! :)
<ugo> And the criteria might not have anything to do with sharing the same resource
<mitrepauld> right
<DaveH> you mean the optional resource pointer/url in the wsdl schema?
<cferris> so, what is the relationship then?
... uses?
<dbooth> There could be MANY different kinds of criteria for grouping. E.g. all printers of the same brand, all management interfaces to all devices, or all interfaces to a particular printer.
<mitrepauld> DaveH, yes, added this week by WSDWG as I understand
<DaveH> thanks
<cferris> yes, there can be many criteria, and this is the sort of thing that discovery is for
<dbooth> But the targetNamespace can span multiple WSDL documents.
<cferris> in UDDI, I can also catagorize a service sixteen ways to sunday
<mitrepauld> I expect update to [1] to add @resource in infoset terms, [1]=http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl12/wsdl12.html#Service
<cferris> in a sense, it might be an extension of the "description" (the categorization metadata)
<ugo> depending on the criteria chosen, the "resource" corresponding to the service collection varies
<DaveO> DavidB, the big problem I see with target namespace is that you guys want to use the target namespace for identifying components. Imagine WSDL file #1 has service named A. WSDL file #2 could also have a service named A. How do you differentiate between these?
<mitrepauld> I don't think we're saying that WSDL needs to add taxonomy support, are we (uddi:categoryBag)?
<dbooth> daveo, are they for different services?
<DaveO> DavidB, and plus I think namespace names are for identifying namespaces, not targets.
<cferris> see http://lists.w3.org/Archives/Member/w3c-ws-arch/2003May/0066.html
... +1 to daveo
<DaveO> davidb, they are different services, but in different files. WSDL can't guarantee name uniqueness across files so re-using namespace names would be bad, imo.
<dbooth> I'm wondering if the following two statements
correct:
... [[ 1. If two services have the same targetNamespace, then they should
have the same semantics, but they might not identify the same "thingy". ]]
... [[ 2. However, if two services have the same resource attribute, then
they must identify the same "thingy", even though they may not have the same
targetNamespace or semantics. ]]
<mchampion> [strange discussion of how to make a floppy-based "target" application a Web service by implementing an email and phone binding ...]
<cferris> dbooth, w/r/t [1.], I disagree... I can have a WSDL
that has multiple <service/> elements, each describing a different
service (e.g. may be bound to differrent interfaqces) so I strongly disagree
... dbooth, w/r/t [2.], I think that that is a given per webarch, a URI
always identifies the same resource
<mitrepauld> namespace x may define elements for airplane and boat. WSDL#1 uses namespace x to describe a boat interface. WSDL#2 uses namespace x to describe an airplane interface. x:boat not used in WSDL#2, x:airplane not used in WSDL#1. Or should WSDL#1 and WSDL#2 have different targetNamespaces?
<DaveH> ?q
<mchampion> jmarsh: agents are behind endpoints, and in front of turtles (?)
<DaveO> martin's question: 1 agent per resource/turtle or multiple agents per resource/turtle?
<mchampion> In the dog/floppy example, the software that rings the bell is an agent, the programs on floppies are turtles, and the dog is something undefined.
<DaveH> +q mikeC
<hugo> My diagram: http://www.w3.org/2002/ws/arch/3/05/wsa.png
<frankmccabe> What about a music streaming service? The service is the ambient music, not the collection of possible titles
<hugo> BTW, what I said was: the turtle/resource is exposed to the agent and the agent manipulates the turtle/resoure, the turtle/resoure being the "state"
<Roger> Frank, I think that in a music streaming service the
service is the set of endpoints (URL's) that one uses to gain access to the
streamed music.
... Frank, I think that the ambient music refers to the messages that the
agent sends back to the requestor.
... Frank, In this by "service" I mean what we have been terming
"wsdwg:service".
<DaveH> both the target-turtle and the agent should have ids, the application devleoper will decide which they need
<frankmccabe> A description is also potentially a resource
<MChapman> yes but its not a turtle
<mitrepauld> Someone mentioned "owner" earlier. Got me thinking. http://dev.w3.org/cvsweb/~checkout~/2002/ws/arch/wsa/wd-wsa-arch-review2.html#agent "Agent has **an** owner" Resource:owner ratio is 1:n. If resource is UDDI business registry (UBR), owner is complex (IBM, MS, SAP, NTT). Not sure why we need to introduce "owner" concept. I guess security, access policy controlled by "owner".
<mchampion> DaveH opinion: the combination of a turtle and an agent is the true ur-WebService
<DaveO> DaveO proposal: Agent=Web Service. Resource is
separate from Agent/aka Web Service.
... lol
<cferris> from the doc: An agent may provide one or more
services; a service has
... one or more service providers; a service provider is
... a Web service agent; a service provider provides one or more services
<dbooth> Therefore "your Web service is down" == "it doesn't exist"
<bijan> Ok, I try again: map endpoint --> URL;
Binding...uhm ---> bits of http; interface ---> HTTP methods (get, put,
etc), operation ---> GET, etc.
... THen this diagram is a generalization of web architefture
... Assuming that me map the agent+turtle to "resource"
<cferris> ergo: an agent is a service provider (because the obverse is true) and since a service provider provides a service an agent provides a service
<MChapman> i think we need to modify a service has one or more providers to one provider since we are now taking about a single resource
<cferris> we could ask ourselves whether "provides" in this case equates to "isa"
<dbooth> The agent is the physical entity (a piece of software) that sends and receives messages, while the service is the abstract set of functionality that is provided. To illustrate this distinction, you might implement a particular Web service using one agent one day (perhaps written in one programming language), and a different agent the next day (perhaps written in a different programming language). Although the agent may have changed, the Web service remains the s
<MChapman> the remains teh same measn that there is some
notion of shared state
... this is what we have been calling turtle
<bijan> Continuing in this RESTy vein, a web service is a web resource which responds to a wsdl described set of operations
<DaveH> daveO states a webService has an identiy--that may--may--be either the agents identy OR the resource
<bijan> As opposed to only the predefined set of operations baked into htttp
<DaveH> we arn't there yet bijan...we don't have a def for endpoint
<cferris> a wsdl:service has identity, it is the QName that is targetNamespace plus wsdl:service/@name
<MChapman> let me rephrase; in a statefull web service, if i swap in and out agents, the state remains the same. this state is what i think wea are calling the turtle/resource
<cferris> daveh, see my email: http://lists.w3.org/Archives/Member/w3c-ws-arch/2003May/0066.html
... I have offered a definition for endpoint
<bijan> DaveH: Sure. I'm just pointing out that that diagram maps nicely to a generalization of web architeture
<mitrepauld> How does consumer relate to agent?
<bijan> Which is an interesting reversal fo the usual conceptualization of web services
<cferris> consumer is also an agent
<mitrepauld> I thought so. So agent may not be a service (if agent is the consumer)
<bijan> What DaveO just said conforms exactly to the view
I've been getting
... If one takes the diagram as a generalization of web arch, that suggests
that talking about hte internal structure of "agent+glue" is misguided
... It also suggest that the WSD labeling of it as 'resource' was well
motivatable
<DaveH> yes...that is part of the land for competative differentiation.
<dbooth> DaveO, So the WS is the union of all agents (current, past & future) that act on behalf of a particular resource?
<frankmccabe> Methinks y'all should be hungry?
<DaveO> I'm starving...
<cferris> http://www.w3.org/2002/ws/arch/3/05/wsa.png
... hugo's diagram ^
... there are a couple of points w/r/t hugo's diagram that I am not sure that
I agree with (but thanks to hugo, we have something concrete to discuss!
:)
<DaveO> DavidB, I tend to think that a Web serivce is the
current agent only, and it is not directly related to the "resource".
... DavidB, remember people could "lie" about the resource.
<bijan> DaveO, isnt' that the implementor's view of the web service?
<cferris> a service has an interface
<bijan> I.e., If I want to deploy a "web service"
... I typically write some program and think a lot about its structure
... And have to deploy a "web service server"
<cferris> the service has one or more endpoints that are bindings (to a protocol) of the service's interface that are accessible at an address (URI)
<DaveH> The next half hour if we are honest about trying
<cferris> an interface has one or more operations, and I agree that an operation is implemented by an agent and that that agent manipulates a resource
<DaveO> Chris, do you mean Web service when you say "service"?
<Roger> bijan, I might be wrong, but I think that your definition could include an XHTML page on a website, which I personally think is not a reasonable Web service.
<cferris> but it does point out a flaw in resource==agent because there may indeed be separate agents for each operation
<bijan> I.e., why think of the agent maniuplats a resource
<frankmccabe> web services are not the same as agents.
<bijan> Actually, it's explicitly ruled out
... Roger
<cferris> daveo, I don't draw a distinction
<frankmccabe> (isa is a subtle concept!)
<dougb> agent is an implementation issue usually not visible from an external perspective
<DaveO> Does a turtle have 1 Web service or many?
<Roger> bijan, how?
<bijan> Because a web servcie has to have state
represenations eliciable from wsdl described operations...
... Whoops
<frankmccabe> What is this turtle anyway? (And that is not a facetious question)
<mitrepauld> REST elements = components, connectors, and data. Components=origin server, gateway, proxy, user "agent". Connectors=client, server, cache, resolver, tunnel. http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm#sec_5_2
<bijan> I was originally thinking that web services had
state represntations elicitable by non HTTP represenations
... But of course you can use wsdl to descripe the HTTP methods
... I meant http methods
... So, sure, I think of XHTMl pages as degenerate web services
... In fact that's the cool inversion of the normal view, imho
<mchampion> frank, a turtle is the lowest "thing" in the WSA ... something that performs some service. It rests on an arbitrarily deep stack of implementation details that are out of scope of the WSA
<DaveH> good...I like that perspective...
<Roger> I am very negative about that, because I think that Web services need to be things that are involved with machine-machine interactions.
<frankmccabe> That suggests that an turtle is an agent
<DaveO> Web service can be: 1) Endpoint, 2) Service; 3) Service Collection; 4) Agent
<bijan> Roger, XHTML pages are involed with many
machine-machine intereactions
... Crawlers, for example
... Also, I've wrapped web pages in proxies which parsed them, extracted
information, etc.
<Roger> Bijan, Let's take this off-line.
<mchampion> the "turtle" moniker comes from a famous joke/anecdote about Steven Hawking that has a URL in yesterday's minutes
<bijan> k
<DaveO> Maybe 4) should be Collection of agents
<frankmccabe> One definition os service: A set of related tasks (where a task is combination of a goal and an actin)
<DaveH> no, I liike 4 as is
<mchampion> I tentatively vote for 4) Agent ... not sure about 4) Collection of agents
<dbooth> Please define "5) Collection of agents" to avoid ambiguity
<MChapman> turtle is actually the inportant thing
<DaveH> can't go for Collection - It can't see its real world managment being viable
<MChapman> choices:
<frankmccabe> We are getting in serious philosophy here.
<MChapman> 1) Service collection
... 2) service
... 3) endpoint
... 4) agent
... 5) turtle /choice
<DaveH> if agent inlcude the collection of agent/turtle that has an ID
<MChapman> 5) turtle/resource
<cferris> webservice is down is only meaningful from the perspective of the service requester
<DaveH> 6) None of the above
<cferris> but the manifestation could be: network hiccup, endpoint unavailable, agent unavailable
<DaveO> 1) Service Collection; 2) service; 3) endpoint; 4) agent(agents?); 5 turtle; 6) unioni of service/endpoint/agent/turtle; 7) spoon.
<ugo> is service(#2) == wsdl:service?
<DaveO> yes ugo
<MChapman> 7)spoon=none of the above
<DaveO> 1) Service Collection; 2) service; 3) endpoint; 4) agent(agents?); 5 turtle; 6) unioni of service/endpoint/agent/turtle; 7) spoon (none of the above).
<frankmccabe> I have to vote 7
<cferris> what is the question please?
<DaveO> 1) Service Collection; 2) service; 3) endpoint; 4)
agent(agents?); 5 turtle; 6) union of service/endpoint/agent/turtle; 7) spoon
(none of the above).
... Staw poll: what is a Web service? 1) Service Collection; 2) service; 3)
endpoint; 4) agent(agents?); 5 turtle; 6) union of
service/endpoint/agent/turtle; 7) spoon (none of the above).
... Straw poll: what is a Web service? 1) Service Collection; 2) service; 3)
endpoint; 4) agent(agents?); 5 turtle; 6) union of
service/endpoint/agent/turtle; 7) spoon (none of the above).
<DaveH> Union of agent and turtle with an ID
<MChapman> clarification straw poll is with respect to hugos diagram
<mitrepauld> where is turtle on diagram http://www.w3.org/2002/ws/arch/3/05/wsa.png?
<DaveH> What about my admendment?:?? disallowed or just ignored?
<DaveO> Staw poll: what is a Web service? 1) Service
Collection; 2) service; 3) endpoint; 4) agent(agents?); 5 turtle; 6) union of
service/endpoint/agent/turtle; 7) union of agent and turtle; 8) spoon (none
of the above).
... Staw poll: what is a Web service? 1) Service Collection; 2) service; 3)
endpoint; 4) agent(agents?); 5 turtle; 6) union of
service/endpoint/agent/turtle; 7) union of agent and turtle; 8) spoon (none
of the above).
<cferris> a web service is an agent(s) that manipulates (or exposes) a resource, that is accessed through one or more endpoints
<mitrepauld> turtle?
<DaveO> turtle=Resource
<DaveH> turtle = @resource
<DaveO> Staw poll: what is a Web service? 1) Service Collection; 2) service; 3) endpoint; 4) agent(agents?); 5 turtle; 6) union of service/endpoint/agent/turtle; 7) union of agent and turtle; 8) spoon (none of the above).
<frankmccabe> Does 6 mean Hugo's diagram?
<cferris> I am torn between 3 and 3
... oops,
<ugo> I vote for 2
<cferris> I am torn between 3 and 2
<frankmccabe> I vote for 8
<mitrepauld> 3
<cferris> 2
... no 3
... no 2
... no 3
<DaveO> ton bastarde!
<DaveH> 8888888
<cferris> ahhhhhhh
<hugo> Result of the straw poll:
... 1 = 0
<cferris> what is the maximum speed of a laden swallow?
<hugo> 2 = 7
... 3 = 1
... 5 = 0
... 6 = 1
... 7 = 4
... 8 = 1
<dougb> 4=2
<DaveO> next straw poll: 2) service; 4) agent(s?)
<ugo> 2
<cferris> 2
... but i really think it can be 3
<frankmccabe> I abstain, lean to service
... I have to go folks
<mitrepauld> agent may implement several web services (management service (start/stop), security service (limit access), stockQuote service). I voted 3 (endpoint) as the closest. Next poll I vote 2.
<ugo> what are the results of the latest poll?
<Roger> service = 9
... agent = 4
<cferris> an agent may have multiple services
... and a service may have multiple agents
... interestingly enough, there could be multiple resources manipulated by a
web service
<ugo> exactly
<mitrepauld> service may have endpoints 1/2/3/4... endpoint#1->agent#1, endpoint#2->agent#2, ...
<cferris> I should also note that this whole discussion may
be related to ericn's position as articulated here: http://lists.w3.org/Archives/Public/www-ws-arch/2003Apr/0089.html
... although I disagreed with him at the time
<mitrepauld> depends how many operations you stuff into an endpoint
<cferris> how many operations can dance on the head of an endpoint?
<mitrepauld> Is the length of a WSDL file limited :)?
<ugo> no, it's the equivalent of a Turing machine tape
<cferris> I'm logging. Sorry, nothing found for 'actions'
... I note that the actions were largely unassigned... was this by design?
