- From: Jonathan Marsh <jmarsh@microsoft.com>
- Date: Fri, 24 Jan 2003 11:41:58 -0800
- To: <www-ws-desc@w3.org>
--------------------------------------------------------
Monday 20 January
--------------------------------------------------------
Present:
Erik Ackerman Lexmark
David Booth W3C
Allen Brookes Rogue Wave Software
Roberto Chinnici Sun Microsystems
Youenn Fablet Canon
Steve Graham Global Grid Forum
Martin Gudgin Microsoft
Tom Jordahl Macromedia
Philippe Le Hégaret W3C
Steve Lind AT&T
Kevin Canyang Liu SAP
Michael Mahan Nokia
Jonathan Marsh Chair (Microsoft)
Jeff Mischkinsky Oracle
Dale Moberg Cyclone Commerce
Don Mullen Tibco
Arthur Ryman IBM
Jeffrey Schlimmer Microsoft
Igor Sedukhin Computer Associates
William Vambenepe Hewlett-Packard
Steven White SeeBeyond
Umit Yalcinalp Oracle
Prasad Yendluri webMethods, Inc.
Observers:
Martin Duerst I18N
Phone:
(3:30-4:30) Glen Daniels Macromedia
(9:00-3:30) Amelia Lewis TIBCO
(briefly) Lily Liu webMethods
09:00 Introductions and logistics
- Assignment of scribes
(pool of likely victims: Erik Ackerman, Sanjiva, Jeff
Mischkinsky, Igor Sedukhin, William Vambenepe,
Martin Gudgin, Jeffrey Schlimmer)
Order of scribes:
William Vambenepe, Igor Sedukhin, Jeffrey Schlimmer, Martin Gudgin
Yoenn Fablet
[William scribes]
09:20 Message Exchange Patterns/Output operations.
- Unified SOAP/WSDL MEPs [2].
- Interaction proposal alternatives [3].
- Solicit/Response MEP [4].
[2] http://lists.w3.org/Archives/Public/www-ws-desc/2003Jan/0022.html
[3] http://lists.w3.org/Archives/Public/www-ws-desc/2003Jan/att-0005/01-interaction-patterns-jan-13-2003.html
[4] http://lists.w3.org/Archives/Public/www-ws-desc/2003Jan/0035.html
Topic: Don's Proposal
Don: Minor modification to SOAP MEP. Create abstract MEP specification.
Jonathan: Ideally arch group would own description of abstract meps.
Don: Arch group already created template doc based on soap spec. Not
much activity recently on that. They own MEP framework but are
hesitant to create specific abstract MEPs. They just own the
definition of what an abstract MEP is. We could own some abstract
MEPs ourselves.
Jonathan: Does the group have any feedback on the proposal?
group: (silence)
Jonathan: Have people read the proposal?
group: (silence)
JeffSch: Is the idea to at some point have indication in the portType of the
MEP implemented and in our spec more info on how a MEP is further
defined based on its URI? Would this be a normative part of the
spec?
Don: We would define several MEPs. In the operation syntax you would
indicate what MEP is used by this operation. Other people can
create their own MEPs too.
JeffSch: So this is a proposal for how the MEPs created by this WG would
be described?
Don: Yes.
Jonathan: Wsdl 1.1 has 4 "MEPs" (not by that name) but how they relate to
SOAP MEPs is undefined. At least we need to describe that.
That's the 1st pb. The 2nd pb is for output operations. If we
can define them better, we can keep output operation. 3rd pb is
how do you charaterize a MEP in WSDL. Don's proposal addresses
the 1st pb. For the 2nd pb, amy has shown how you could write
an abstract MEP for output operations.
JeffSch: Is the proposal (for the 1st pb) that something goes in our spec
to explain the relationship with SOAP MEPs?
Jonathan: We would point directly to the abstract MEP framework and to the
MEPs we support (probably the 4 in wsdl 1.1). And SOAP would
also point to the same abstract MEPs. Therefore reconciling SOAP
and WSDL. The proposal is for Arch WG to own it. if necessary
we could start writing it.
Don: Ideal scenario is Arch owns the definition of what a MEP is and
our spec describes specific MEPs.
Jonathan: If we own abstract request-response MEP, how does SOAP use it?
Don: SOAP binding would indicate which one of the 2 SOAP MEPs
correspond to the request-response wsdl MEP used. SOAP MEPs
could be simplified by stripping out the abstract part and
pointing to the abstract definition. Pb of timing.
Arthur: Wsdl has "primitive" MEPs. When do you run into things like
BPEL? what kind of complexity does WSDL cover?
Don: There's an inherent risk of people abusing this mechanism
Jonathan: Abstract MEPs are not going to be machine-readble. The
resulting interop pb will hold people back from going too wild.
So, we won't put anything technically that limits potential for
abuse, but we will restrict ourselves to the most primitive MEPs
and not go overboard.
Amy: If you have control flow then you know you are in the space of
choreography. If you have complex MEPs with a sequence of
messages, you can define them as a choreography or as a simple
MEP (if the flow is sequential, without choices or branches,
even of it is lengthy). I am concerned that we seem to shy away
because of fear of touching choreograhy. I don't think it's such
an issue, if we go in this direction, interop pbs will stop us.
Should not put limit on MEPs in terms of nb of messages.
Steve: Don, can you enumerate MEPs?
Don: Reques-resp, solicit-reps, input only, a couple of variation on
output only...
Youenn: MEPs define nodes, but we don't know which node will be the
service. So in a request-response MEP, you don't know whether the
service will be on the sending or receiving end. so we need to
be able to identify that. And in this case, i am not sure we
need solicit-reponse. It is just the miror of a request-response.
JeffSch: It would be simpler if the MEP said "i am defining inputs and
outputs" and if you are implementing this MEP you know which are
input or output.
Youenn: Disagree. when you implement it, which node you are won't change
which MEP you are using. Either we identify in the spec which node
is the service. or in the wsdl we say "this is the MEP, and I am
this node". In jeffsch's way, the same MEP will be defined twice,
once from each point of view -> concern of duplication.
JeffSch: Concern we discussed at last telecon: if I don't understand the
URI of the MEP, how much do I undrstand the messages?
Youenn: MEP identified as URI. we can create a schema to describe the roles.
JeffSch: Intermediaries will have to process this schema, won't always know
what to do.
Youenn: Intermediaries will process the wsdl and this schema.
Gudge: You're assuming they have access to it.
Youenn: Yes. You can define a triangular relationship (3 parties) with a
MEP and the service says who he is. With jeffsch's proposal we
have a spec to describe each of these nodes.
JeffSch: The trade off we are discussing is the value to be able to do
identity comparison (they point to the same MEP) vs a simpler
rule for an intermediate (doesn't need to retrieve additional
docs).
Youenn: I don't think the 2nd one is simpler. The different between
choreography and MEPs is that MEPs are one-way interactions. MEPs
will be simpler than choreography. If we only have 4 MEPs that we
define, all WSDL processors will have these 4 MEPs so the
difference won't be big (as opposed to 2 MEPs) but I still prefer
the latter.
JeffSch: Still concerned by what happens if the intermediary doesn't
understand a MEP.
Youenn: I could write a proposal of this schema.
Don: Jeffsch, you want an intermediary who doesn't understand the MEP
to understand the direction of the messages?
JeffSch: if you don't understand the MEP, you should still understand the
schema describing the schema of the message. 2nd question, should
you be able to understand the direction of a message? Useful for
an intermediary.
Youenn: In my proposal, in the wsdl file you would have a "direction"
parameter to say whether a specific message is input or output.
(discussion on sanjiva's proposal)
Youenn: In both proposal, if you remove input/output operation you would
need to put this info in a different way.
Don: I agree with jeffsch that we need a way to figure out
directionalitly. not sure what the best way to do that is. But
we can't take this info out.
Youenn: You could have 3 different MEPs that match output-input pattern
but don't have the same scemantic. Esier to have 2 specs in one.
The soap request-reponse MEP identifies 2 messages. If you
receive multiple responses it is a different MEP.
JeffSch: Request-response and solicit-reponse are 2 different MEPs because
different number of messages exchanged. Do you want a client to
be able to use a wsdl to describe itself?
Youenn: Yes, a client can say I am node A or I am node B. You can't
specify your role at the portType level because you might want to
take different roles in different operations in the same portType.
Jonathan: Let's break this discussion down in smaller items.
JeffSch: Maybe we can see whether we can come to an agreement on what
properties of the component model is needed to be able to tell that
you are using the same MEP on both sides of the wire.
Don: Do we want to go down the road of defining what an abstract MEP is?
Jonathan: Youenn's suggestion can work with that fine.
Youenn: Our proposals are very similar. The only difference is whether the
specification of which node is in the spec or in the wsdl.
Jonathan: The abstract MEP template would define a URI for the MEP. It might
expose a role property with Youenn's proposal. In Youenn's proposal
we get fewer URIs.
Tom: Advantages to not doing MEPs in an abstract way? Does wsdl 1.1
have implicit MEPs or no MEPs?
Gudge: You can think of 1.1 as having implicit MEPs.
Tom: A "good" wsdl processor will have a lot of work to support lots of
MEPs. Is this worth it? The people who use WSDL to describe
arbitrary things, will abstract MEPs help them?
JeffSch: Question of extensibility. We will define 4 MEPs. People can
create more. Usual challenge of interop with extensibility.
Jonathan: It is a given that we need to solve the pb of reconciling with
SOAP. The second question is whether we need to define
extensibility.
Tom: Extensibility is ok as long as the basc ones are clearly defined.
We can't just say "somebody will figure it out", we are going to
have to spec it.
Jonathan: Not clear to me while people would use MEPs to do choreography
kind of things.
JeffSch: "Abstract" means you are not saying whether it is soap, what
transport?
Amy: Yes, abstract says how many messages, but not the transport used.
JeffSch: We need to clearly define abstract. Will the abstract MEP define
how long you should wait for the response?
Amy: I don't think the abstract MEP would define that. But not at the
protocol level either maybe. In the concrete MEP.
JeffSch: Would abstract include sequence and cardinality of messages?
Amy: Yes.
JeffSch: Just trying to clarify.
Michael: Would like to see what is fixed and what is variable in an
abstract MEP.
Tom: How many URIs do I have to hard code in my WSDL processor? Not a
lot I hope
[<alewis> One of the problems with MEPs is that *no one* wants to consider
them in scope for their working group. So we get minimal
definitions. If Arch takes it up, we'll be in better shape.]
Tom: What if the arch group does something we don't like?
Jonathan: We comment. SOAP has already specified it well, and the people
are the same. I am not too worried.
Tom: Everyone agrees that the four implicit MEPs in wsdl 1.1 are useful.
Jonathan: We got into this discussion because we considered removing some
MEPs.
Tom: A lot of people now expect notifications.
JeffSch: We should move on to the next topic in this conversation.
Jonathan: Don, is a real pub/sub one of the 6 you propose? Did we drop
the action item on pub/sub from Paris? Should there be a
different pub/sub group?
Dale: A lot of people discussed the MEP type but there is more to
pub/sub.
Jonathan: There might be a "standard" pub/sub portType.
Amy: We are looking for the description of a MEP so that we can bind
them to pub/sub protocols. In many cases it won't expose things
like subscribe to the app level.
Jonathan: Pub/sub discussion seems orthogonal to the MEP discussion.
People can build pub/sub on top of the MEPs we are discussing now.
JeffSch: is the question whether don's abstract works for the way people
want to do pub/sub?
Gudge: MEPs are for message patterns, not programming models. At the
portType level, not at the binding level.
Tom: MEP would live at the portType. If we commit to output/input
MEP, we need a binding to implement that. TCP binding for instance?
Gudge, jeffsch: For instance.
[<alewis> Other possibilities for solicit-response examples: JMS, IP
multicast, net-news, arguably email.]
Tom: Yes we want the abstract model. operations will now have a new
attribute, a URI pointing to a MEP. and will have at least one
binding that implements each MEP.
Gudge: +1 to giving more work to part 2 editors...
Jonathan: TCP binding is just one example. should not go through the work
of doing binding just to show that it works.
Don: +1, we should not do a toy binding. Non-toy bindings would be
JMS or email.
Tom: If we don't spec the binding for output/input, we are going back
to the same situation as wsdl 1.1. As an implementer, what do I
do if I get a binding I don't understand? If it's
request/reponse, we have SOAP/HTTP as the lowest common
denominator scenario. what is it for output oeprations?
WilliamV: +1 to tom
(Discussion on whether Axis implements SMTP)
JeffSch: Need to clarify things. we can't just say input/output. one
message each way? what wait time?
Jonathan: In youenn's proposal, what does the binding look like on the
"other" side of request-reponse (other than the server side that
we understand because it's like wsdl 1.1)?
JeffSch: In the past, you don't describe clients, just services
--------------------------------------------------------
10:30 Break
10:50 Message Exchange Patterns (cont.)
--------------------------------------------------------
Jonathan repeats his previous question (before the break): "In youenn's
proposal, what does the binding look like on the "other" side
of request-reponse (other than the server side that we
understand because it's like wsdl 1.1_). We assume here that
we want a wsdl file for both.
Don: What is the use case for the client publishing a wsdl?
Tom: I don't want to bring the SOAP concepts of nodes and stuff into
WSDL. WSDL must keep a server-centric view.
Youenn: We are service-centric, not server-centric. a service can act
as a client.
Tom: WSDL describes the service from the point of view of the provider.
Youenn: My proposal describes services, not clients. it is based on what
node you act
JeffM: There is still a client and a service role. Traditionaly, the
client role is the one that initiates the message. But for
output messages it gets reversed
Gudge: Whether the provider or something else sends the first message is
orthogonal to the question we are trying to anwser. The question
is : "what is wsdl written from the point of view of"? Looking
at the wsdl you can tell who is the initiator. I don't think both
ends should have the same MEP so that I can describe things from
the point of view of the service.
Jonathan: So gudge you're taking issue with Youenn's proposal. There are
lots of ways to describe output operations, and doing it as a
reversed view of the same MEP is not the way to do it
(jonathan is trying to rephrase what gudge said).
Igor: It's just a syntactic difference.
Gudge: The portType has no notion of SOAP.
[alewis: I don't agree at all that solicit-response is a mirror of
request-resposne, and I don't think it's a useful conceptual
model.]
Youenn: Don defines MEPs at portType level, as a bunch of nodes. There is
no notion in this definition of MEP of what is the service.
JeffSch: Let's not speculate on what the orchestration WG will do.
Youenn: If you define MEPs as sequences of input and output you don't
define them the way it is done is SOAP.
Gudge: That's fine, no SOAP at the portType level.
[dbooth: My previous analysis of Output-Input, etc., which analyzes
different viewpoints:
http://www.w3.org/2002/09/11-wsa-dbooth/output-input_clean.htm]
Youenn: If we are going to reuse SOAP's notion of what is a MEP, we need
to define what node is a service.
{kevinL: +1 to amy and others that solicit-response is NOT a mirror of
request-response.]
Gudge: If WSDL is always written from the point of view of a service,
why do we need to specify which node is a service?
[dbooth: (One viewpoint being service-centric, the other being
non-service-centric.)]
[alewis: I agree with Gudge.]
JeffM: If we take gudge's viewpoint that wsdl just describes the service.
For output-input, is there a wsdl that describes the one that you
are sending the message to?
Gudge: As a service it doesn't matter to me whether the other end has
a WSDL or not. If you have input-output and I want to send you a
message, do I need a wsdl?
JeffM: No, you're right.
Gudge: It's much easier for both parties if the wsdl is written from one
person's perspective.
Dbooth: You need to know what role you are playing. The url in the service
element says who is what. Having wsdl described from the point of
view of the service, there are still 2 parties described, one
implicitely (the client) and one explicitly (the service). So it's
just a question of prefered style.
Gudge: We had this discussion at a previous f2f (paris) and we agreed
that wsdl would be described from the point of view of the service
[alewis: +1 to Gudge. WSDL == webSERVICEdescriptionlanguage]
JeffSch: Does this have an impact on Youenn's proposal?
Youenn: It doesn't.
JeffSch: We agree that there are (at least) 2 roles. Can be implicit (status
quo) or explicit (Youenn's proposal).
Youenn: No, only the role of the service is explicit.
JeffSch: The wsdl would say there are 2 parties.
Youenn: No, just one.
Gudge: wsdl is already described from the point of view of the service,
Why then would we need to add anything? Mapping with SOAP MEPs is
a binding issue, it has nothing to do at the portType level
JeffSch: If there are more than 2 parties, it feels like orchestration to
me and we should not focus on this until we hear from the
orchestration working group.
Jonathan: Do people disagree with the way jeffsch draws the line with the
orchestration work?
Dbooth: Does this mean we could not use wsdl to describe an intermediary
(because this would mean 3 parties)?
All: Yes
JeffM: The implication is that I cannot describe a proxy using a MEP?
[Steve: Is orchestration the same as choreography?]
JeffSch: The proxy would be transparent (that's one way).
JeffM: But then you're not describing it.
[dbooth: steve, yes, for the purposes of this discussion.]
JeffSch: The other way is to have 2 wsdl documents, one from the inside
and one form the outside. In any case you need 2 ports since
there will be 2 endpoint URLs anyway. So maybe this is a use case
for why a service needs more than one portType.
Dbooth: This would be the workaround if you cannot describe the 3 parties
in one wsdl doc. Youenn's proposal is trying to improve by: 1)
factoring a little bit more in the case where they are direct
mirors and 2) allow to describe a service that interacts with
more than one other party at very low cost.
Youenn agrees with dbooth.
[dbooth: (dbooth was not indicating a position, but merely confirming his
understanding of Youenn's proposal.)]
Youenn: Another benefit is to directly abstract SOAP MEPs to WSDL, makes
it easy to abstract SOAP MEPs to abstract WSDL meps.
Gudge: My proposal also does that (by saying that the WSDL always
describes node A).
Jonathan: Our abstract request-reponse URI would be different from the
SOAP request-reponse proposal?
Youenn: At the portType level, we should abstract from the SOAP MEP and
give it a new URI.
Strawpoll: Do we want to describe more than 2 node roles in our message
exchange patterns?
Strawpoll: Do we want to support the creation of MEPs that have more than
2 node roles? (this overrides the previous strawpoll sentence)
Gudge: Let's limit to 2 and if we find out something is critical let's
expand later.
Igor: People can create any kind of MEP they want. are we trying to
limit them to 2 nodes or just limit the MEPs that we create?
Youenn: If a SOAP MEP can have more than 2 roles, I would expect WSDL to
use this.
JeffM: If we were to define a 3 way mep, we wouldn't necessarily have
to define all the possible combinations, just what people find
useful. If someone came up with a well-defined n-way MEP, we
shouldn't dismiss it. It's not really about number of roles,
it's that we are doing things from the service point of view
and the other roles are implicit.
JeffM, dbooth: Saying that the other role is implicit implies that there
is only one other node.
JeffM: What if I have a notification service (output only)?
Gudge: There is only one other role. there could be 3000 subscribers,
but they share one role.
JeffM: And that role would be implicit.
Gudge: If there are 2 differnt roles that the person receiving the
notification might play, then you define 2 MEPs
[<alewis> +1 to Gudge's analysis: let's start with 2-role MEPs, see if
someone produces a use case that clearly requires more.]
JeffM: The important thing is that the roles are implicit, not how
many there are.
Igor: Semantically there is no difference.
Jonathan: Back to strawpoll, do we need to change the wording?
Strawpoll: Should we permit MEPs with more than 2 roles
youenn: What if the SOAP group defines a MEP with 3 roles? we should
support it.
Gudge: There isn't one currently and XMLP is not going to define one now.
Strawpoll: in favor 3, against 11, abstain 6
Potential strwapoll: Do we want to expose the role as a separate component
model property in the portType?
Igor: MEP can be define as a feature.
[<dbooth> I think the essence of this issue is that we are sitting on a
slippery slope. If we allow *some* MEPs to be defined, it's
hard to draw the line about where we should limit them.]
Jonathan: Our component model today does not contain a URI-type property
at the portType level.
Gudge: Part of Don's proposal is to name MEPs with URIs.
Dbooth: I like the idea of flexible MEPs but it becomes difficult to draw
the line on what we should allow, and how what we allow would
overlap with what the choreography WG would define. So do we
want such flexible MEPs?
Strawpoll: Do we want to expose the role as a separate component model
property in the portType?
Strawpoll results: in favor 1, opposed 11 abstain 8
Jonathan: Should we change the variety property to be a URI? (in wsdl
1.1 it is implied by the order of the elements)
Gudge: Alternative is to define extra values for the enumeration for
any extra MEP we define. 3 possbilities: 1) don't change 2) add
more values to the potential list of values 3) make it a URI.
Should it be a closed set or an open set?
Tom: If we don't make it open, there won't be a MEP to support
publish/subscribe (unless we define it in the spec)
Gudge: Pub/sub is a programming level concept
-------------------------------------------------------
12:00 Lunch
-------------------------------------------------------
[Igor scribes]
Topic: Publication issues
Jonathan: Part 1 and part 2 are ready for review. When to call on
objections to publication?
Arthur: What about portType and interface terminology. that was agreed
to fix in the doc.
Gudge: Does not remember anything on the mail about it.
Arthur: Agreed long time ago, before VA meeting.
Gudge: Will look for that.
Jonathan: For this publication, terminology change was not on the list.
[<dbooth> http://lists.w3.org/Archives/Public/www-ws-desc/2002Mar/0084.html :
<dbooth> [[
<dbooth> Keith : should we use portType instead of interface?
<dbooth> Minor disagreements
<dbooth> ]]
<dbooth> That's the only mention I find of terminology change to
"interface" in the minutes.
]
Arthur: Need to batch up all other proposed changes to the doc as well.
Jonathan: Let's put the terminology on the agenda and this one (portType)
too
Gudge: Can't find any decision on termonology of portType going back to
April
Jonathan: Let's get the issues closed.
Tom: It may be too late if someone uses portType
Steve G: e.g. UDDI.
JeffSch: Look at the requirements for WSDL, it was changed there...
Arthur: Was it not decided for AM
[<plh-az> http://www.w3.org/2002/Talks/www2002-ws-desc/slide6-0.html
(WSDL example using interface/interfaceBinding)]
[<dbooth> Gudge, regarding "interface", see also:
http://lists.w3.org/Archives/Public/www-ws-desc/2002Mar/0073.html, which mentions:
<dbooth> [[
<dbooth> Here is a new list of definitions that were agreed today in our
<dbooth> teleconference call.
<dbooth> . . .
<dbooth> Interface (a/k/a "Port Type")
<dbooth> A logical grouping of operations. An Interface represents an
<dbooth> abstract Web Service type, independent of transmission protocol and data
<dbooth> format.
<dbooth> ]]
]
[Chair's summary: We should not wait until the bitter end for this, but
neither should we take it up immediately.]
Steve G: Since GGF suggested in interim draft, they would like a day or so
to review it. This is independent of the Grid proposals being
made.
[Chair's summary: Agreed to move publication approval to Wed morning's
agenda.]
-------------------------------------------------------
Topic: More on MEPs
Continuing on from morning session.
Jonathan: Poll proposal from gudge: variety property to be closed or open set
Gudge: Just open or closed. Do we define the boundary here or not?
Roberto: The property values are not limited.
Gudge: Extensibility is about adding new properties.
Roberto: Keep variety prop values closed set and let extensibility take care
of the rest. Limiting variety prop does not actually limit anything.
Therefore it is not the right question.
Jonathan: We can't disallow any ext, but we can discourage it in certain
places. This is the case here. Variety is a set of predefined
values (closed) or just a URI (open).
Gudge: Is there a different Q to ask here?
Tom: MEPs is the place for mess, WSDL just points to that mess. Should
we even bother limiting that mess or not?
Jonathan: Issue to solve is syncing up SOAP MEPs and "abstract" MEPs. Came
down to how to specify it better.
Tom: Changing WSDL is the interesting part. If we stick URI of a MEP it
has to be open in WSDL sense.
Gudge: Why?
Tom: Darwinian IT :)
Gudge: Abstract is directly translating to syntax so far, but variery prop
is bothering me.
Jonathan: Closed or open?
Prasad: Makes sense to keep it extensible. use existing framework to do so.
Closed is bad.
Gudge: Explicit extensibility point that we specify as opposed to general
"do anything" extensibility.
Prasad: Yes. Instead of extending the language, just use the provided
extension point for good.
Jonathan: Don's abstract MEPs framework is it ... Open or closed at last...
Strawpoll: Open or Closed
17 for open, 1 for closed, 5 abstains
Jonathan: Is the enumeration is the best form or a URI? Is there a better
name than variety (after roberto)
(no one opposed to use URI)
Gudge: Component model as MEP and serialize it as something later
JeffSch: let the editors decide on the name of the serialization (attribute)
(nobody objected - will probably be named "message exchange pattern").
Jonathan: next Q: URI that points to smething and indicates MEP. how to
formalize this
[<alewis> <operation mep="uri" />]
Gudge: URI is just an ID
Jonathan: What the Q to move Don's proposal forward...
Don: Do we define the MEPs that we care about and list them out in our
spec?
Jonathan: i.e. the list of MEPs that we want to standardize
JeffSch: Ordering: decide what MEPs we want, then use that to generalize the
framework, then how they look.
Jonathan: Isn't there still some ambiguity still
[<Gudge> (I), (O), (I,O), (O,I), (I,O+), (O, I+)
<alewis> Gudge: s/+/*/
<alewis> Gudge: I think that it's true, though. Most multiple-response MEPs
are likely to response*, not response+
<Gudge> Right, it's fine, you're right
]
JeffSch: ... 7 MEPs...
(discussion on IO OI IO OI...)
[<scribe> [I lost it here...] :)]
JeffSch: Writing down those MEPs on the wall :)
Don: Factor in the faults
Tom: Faults are and have to be in the interface def
[<Gudge> A. IN
<Gudge> B. IN, (OUT | FAULT )
<Gudge> C. IN, OUT*, (OUT | FAULT)
<Gudge> D. OUT
<Gudge> E. OUT, IN
<Gudge> F. OUT, IN*
<Gudge> C1. IN, (OUT* | FAULT)
<alewis> D == OUT, FAULT*
<Gudge> Not on the board it doesn't!
<alewis> Oh, no. Wait.
<alewis> D == OUT, FAULT?
<alewis> E = OUT, (IN|FAULT)
<alewis> F == OUT, (IN*|FAULT*)
<Gudge> C. (IN, OUT*) | (IN, FAULT)
<Gudge> I'm having trouble keeping up
<Gudge> C1. IN, (OUT* | FAULT)
<Gudge> C2. IN, (OUT2+ | FAULT)
]
JeffSch: Anyone can define their own MEPs. Just what will cover 90% cases
that we have to worry about here.
[ c3. in, (out 2+ | fault)
c4. in, out*, (out | fault)
e. out, (in | fault)
a1. in
a2. in, fault?
e. out, (in | Ifault)
g. out, in, Ofault
]
JeffSch: [talking about] ordinary msg or a fault and then direction
Gudge: Distinction of ordinary and fault does not change MEP, does it?
JeffM: Can one say you always get a fault then?
DBooth: Agrees with gudge.
JeffSch: There could be fire-and-forget MEPs at the level we're modeling.
Tom: We'll have to clarify what to do with the faults and where did
they come from. Wants clear spec, but agrees with gudge...
Amy: Anywhere where is response there could be a fault.
JeffSch: e.g. a sequence of faults...
[* plh-az (in, out, ofault, ifault)*
* plh-az (in| out| ofault| ifault)* actually
]
JeffSch: Proposal on the table: get rid of faults in the MEPs specs.
JeffM: What about just only fault in return?
JeffSch: State diagrams would define that, grammar we're at is not
preventing it.
[<alewis> I think that the argument is that *any* message can provoke a
fault. Which doesn't mean that the fault is deliverable, of
course (the current input-only pattern is an example of
undeliverable faults).]
JeffSch: Only last one could be a fault.
Gudge: Faults are out.
JeffSch: We need to agree where the faults could appear [to help WSDL
processor developers, I guess].
DBooth: We should not be specific where and when fault can occur in
the MEPs.
JeffSch: The convention would be then: any IN or any OUT could be a
fault in a MEP.
Amy: Faults travel in the direction opposite to IN or OUT.
MikeM: Any subsequent msg can be a fault.
Amy: There could be undeliverable faults.
JeffSch: In SOAP model one has to generate a fault, but does not have
to send it :)
[tom & amy discussing delivery of faults]
JeffSch: Prioritize our "care about" MEP list and let others do more.
Prasad: Wants to model faults in MEPs.
MikeM: Contrain MEPs to 2 msgs for the prioritization that we do.
[<alewis> Is that constraint on the MEPs that we are willing, as a
working group, to consider defining? Or a hard limit on
what is to be considered a MEP?]
JeffSch: Then "MEPs are a seq of 1 or 2 msgs".
[<TomJ> I think we are defining the scope of our work, not a limit
on what a MEP is.]
[<DonM> Hopefully the former.]
[* plh-az H. IN, OUT, IFAULT ]
DBooth: Treat faults as completely async, out-of-band msgs. Fault can
be triggered by a power outage, not an IN msg, for instance.
Model faults separately from MEPs.
JeffSch: We need to say all about req-response.
Gudge: Msg in, msg out, why not it be a choice of messages, some
are faults? Just alternative out msgs.
[Whiteboard at this point: (see http://www.w3.org/2003/01/meps.txt)
A.
+A1. IN
A2. IN, OFAULT? "NACK"
A3. (IN | IFAULT)
B. (REQ-REPLY)
B1. (IN | IFAULT), (OUT | OFAULT)
+B2. IN, (OUT | OFAULT)
B3. (IN, OUT, IFAULT?) | (IN, OFAULT)
C. (REQ-REPLIES)
C1. IN, (OUT* | OFAULT)
+C2. IN, OUT* (+ FAULTS TBD)
C4. IN, OUT*, (OUT | OFAULT)?
C5. IN, (OUT | OFAULT)*
D.
+D1. OUT
D2. OUT, IFAULT? "NACK"
+E. OUT, (IN | IFAULT)
+F. OUT, IN* (+ FAULTS TBD)
G. OUT, IN, OFAULT
H. IN, OUT, IFAULT
]
DBooth:why call them faults then?
[<alewis> Gudge: the problem with that is that the second message in
the sequence then *cannot provoke a fault*.
<Gudge> Amy: I think that for a given MEP that might be just fine.
<alewis> Gudge: But for others (OUT, IN*), it really isn't okay.
All of the respondents should be able to receive a fault
message as a response to their response messages.
<Gudge> So that MEP is actually OUT, IN*, OUT? ? So that MEP is
actually OUT, IN*, OUT? or OUT, (IN, OUT?)*
<alewis> Gudge: It would have to be more like OUT, IN*, OUT*, if you
really want to be able to say something quite so silly.
<Gudge> Sorry, didn't realise it was silly :-(
<alewis> Gudge: I think it works far better to say that it's OUT, IN*,
and to say that every message in a pattern can trigger a fault
which travels in the opposite direction.
<Gudge> So, is that a general statement that applies to ALL MEPs? Or just
specific MEPs?
<alewis> Gudge: Saying that each message can trigger a fault (which will
travel in the opposite direction) is not the same as guaranteeing
delivery, though. That will depend upon the binding.
<Gudge> Oh, I agree, I'm just wondering if your statement applies to all
MEPs at the operation level or just certain MEPs
<alewis> Gudge: I would say it applies to ALL MEPs, but that the *binding*
may restrict the faults that can be *delivered*.
<Gudge> Ah, I would go the other way. I would say that for
http://www.w3.org/MEPs/FireAndForget there is no option for a
fault to be generated. But for http://www.w3.org/MEPs/OneWayMsg
this is an option for a fault to be generated.
<alewis> Gudge: Because then, one can model HTTP's implementation of
IN, OUT as able to fault for either message, noting that a fault
generated by the output message cannot be delivered.
<Gudge> Amy: But why is that useful?
<alewis> Gudge: But implementing the same MEP, asynchronously, in email,
one would say that that fault which is undeliverable in HTTP is
perfectly deliverable.
<Gudge> I really, really want to keep this discussion at the port type
level. I don't want to be forced to allow faults for every MEP.
I SHOULD be able to define a MEP that does not admit to faults.
<alewis> Gudge: So do *I*! In terms of the MEPs defined at the portType
level, I think we say that every message defined can generate a
fault. Gudge: Why? Can you write code that doesn't fault,
guaranteed?
<Gudge> It's not about whether the code will actually work.
<alewis> *sigh*
<Gudge> Sorry to be so dense.
<alewis> Gudge: It eases the definition of MEPs if one can exclude
consideration of faults from them, correct? If so, it helps a
great deal to be able to say, blanket, that faults can be
generated in response to *any* message.
<Gudge> Yes. But I can see saying for one MEP 'there are never any
faults' and for another MEP any message can result in a fault
transmitted in the opposite direction'.
<DonM> Gudge: So if that is the case, should we capture that in the
definition of a MEP -- never fault or may always fault?
<alewis> Gudge: Okay. But now faults are back in MEPs, because we are
distinguishing between IN, OUT [no faults result from OUT] and
IN, OUT [fault may result from either message].
<DonM> Amy: Right, which would result in N*2 MEPs, possibly....
<alewis> Gudge: Because what you're defining, I think, is a list of
messages in the pattern for which fault responses are legal,
not just faults: yes/no.
<DonM> Amy: Which is not necessarily the right direction re: reducing
scope of work.
<Gudge> Amy/Don: OK, in the interests of reducing scope, for now lets
make the simplifying assumption that every message might result
in a fault being sent in the opposite direction.
<alewis> Gudge: It seems to me conceptually cleaner to say that any
message can produce a fault, but that in certain MEP bindings,
some fault messages may be undeliverable. This covers, for
instance, the difference between HTTP IN, OUT versus email IN,
OUT.
]
DBooth: Not a glorified out, model faults separately.
JeffSch: In SOAP case the out and fault messages do look differently.
MikeM: What does out-of-band mean, not part of WSDL?
DBooth: Not part of MEP, which defines what's expected and what's
not expected is modeled with something else.
Prasad: Wants to model negative responses in the interface itself
(e.g. a login error).
MikeM: Out-of-band is different from not expected. Still wants faults
visible.
DBooth: Yes, visible
JeffSch: Presenting operation MEP table
[ see http://www.w3.org/2003/01/meps.txt
<operation meep="rr">
DIR MSG FAULT?
---------------------
IN MY:X N
OUT MY:Y N
OUT MY:Z1 Y
OUT MY:Z2 Y
OUT MY:Z3 Y
</operation>
JeffSch: It's possible to write a grammar that defines a MEP quite
formally. How does the grammar and the presented table map.
It is not deterministic.
JeffM: Is it possible to add binding-specific faults?
JeffSch: Faults in ops += faults in bindings.
Tom: There isn't anything extra in the MEP that pertains to
faults, didn't we decide already?
DBooth: Suggested that faults are not part of expected sequence of
messages in MEP, but faults are still part of the operation
def in the WSDL though.
Tom: Any out could be a fault.
Roberto: Every msg but the first can be a fault.
Amy: If any msg can be a fault, then last one can't be the fault.
Because one cannot receive it... ??? E-mail case, faults
run in either dir and in place of the messages.
JeffSch: Need to say where faults are allowed. We're not stating it
about all possible MEPs, though.
DBooth: What the fault can be? Is it in response to something, or
it just happens?
[<alewis> Who are you going to send *that* fault *to*?]
Tom: The message that comes back instead of response. I don't
need to worry about delivery [???]
Gudge: Describing MEPs does not affect the number of MEPs we have
to care about.
[<dbooth> alewis, the recipient may be known from previous interactions
<alewis> I agree, we should postpone this issue and move on to discuss
other issues.]
Gudge: Choose any design approach for faults and move on.
Tom: I don't need to worry about checking for faults when the MEP
I am using doesn't say I have to listen for anything.
Jonathan: Too arbitrary.
[<alewis> dbooth: The idea of sending a fault as the initial message of
a pattern (when fault, to me, implies application-level error,
not system error, which may even be modelled as messages in
exchange patterns) is just surreal to me.
<dbooth> alewis, the assumption is that it is part of a larger
interaction sequence.
<alewis> dbooth: That's an assumption that strikes me as less
justifiable than the assumption that every message can
generate a fault. And I still don't see why application
faults would be generated to describe system errors. Or else
is an issue to be left to choreography. But it's prolly time
to stop arguing.
]
JeffSch: MEP will have to state something about the faults: when and
where they could appear.
Gudge: Forget about faults and make decision about MEPs, then tackle
the faults.
Tom: We already have made some progress on faults...
Amy: Whatever we do is not going to change SOAP MEPs... We can't
exclude the faults.
JeffSch: E-mail case: send a message and who cares. There is no
response no fault required at the application level.
[* dbooth also thinks we should address the issue of faults separately.]
JeffSch: Circles a1, a2, d1, d2.
A1. IN
A2. IN, OFAULT?
D1. OUT
D2. OUT, IFAULT?
B2. IN, (OUT | OFAULT)
E. OUT, (IN | IFAULT)
<plh-az> use '+' in front of [A-H] to represent the red circles: http://www.w3.org/2003/01/meps.txt]
Tom & jeffsch: what binding to cover e,f... let's have e-mail binding...
Jonathan: In and out only are useful for orchestration, out-in... where...
Tom: An example is needed
Jonathan: Who will implement TCP/IP binding even if we define one?
Tom: How useful out-in is then?
Jonathan: [consistency...]
Tom: If those ops are non-interop we need to remove them.
Jonathan: Abstract fwk covers MEPs consistently, but we don't have to
create all the possible binding that make use of that fwk.
Don: Fwk covers binding too.
Jonathan: Enable other people use this std properly.
JeffSch: For the symmetry argument, e. is necessary (circled)
Tom: a2 is a case of in-out
[<Gudge> So, there are roughly 12 MEPs on the whiteboard and 24 people
in the room....
<TomJ> 2 people per MEP!
]
Tom: Where the only out allowed is a fault message.
Prasad: A2 was already voted out.
[<alewis> I disagree violently with that characterization; it appears
to be based on using nothing but synchronous, connection-
oriented protocols.
<TomJ> But MEPs are about messages, and the fault message returning
from a input-only op is an output message.
<alewis> No, it's a fault message. If we agree that faults are
orthogonal to the exchange pattern, this multiplication of
the rabb^W patterns becomes unnecessary.]
Jonathan: Which MEPs we'll spec.
JeffSch: Proposed to exclude 1-N cases to constrain the work that
needs to be done.
Amy: Enormous nb of MEPs because of the faults.
Amy: arguing for F
[<dbooth> f = OUT, IN*
<dbooth> f2 = OUT, (IN | FAULT)*]
DBooth: needs some general rule about faults
New list:
a1. in
b2. in, (out | Ofault)
c2. in, out* (+faults TBD)
d1. out
e. out, (in | IFault)
f. out, in* (+faults TBD)
Jonathan: Is this list a consensus? Is it a working proposal?
DBooth: Still need to state where in general faults appear.
Gudge: They were explicitly included in the list of MEPs above.
DBooth: General rule is preferable. this is key.
Gudge: Tom's generalization: any msg but first can be a fault.
Will take up David's question and fill in the TBD faults later on.
15:00 Break
15:20 Properties and Features
- Amy's summary [6], and suggested agenda
1. Scope
a. Should WSDL support only description of SOAP features and
properties, or features and properties more generally?
b. If only SOAP features and properties, should the namespace be
the WSDL SOAP namespace, or the WSDL namespace?
c. If features and properties generally, should WSDL propose a
universal syntax, or let each feature definition mandate its
own?
2. Concrete Binding
a. Should the current <binding> tree be separated into
<messageBinding> and <protocolBinding> trees?
b. Should the concrete binding syntax live in <binding>,
<messageBinding>, <protocolBinding>, or <service>?
c. Where, exactly, in the preferred subtree may the new
syntactic elements appear?
d. What are the new syntactic elements?
3. Abstract Binding
a. Should it be possible to specify required features and/or
properties in the <portType> tree?
b. If so, where in the tree may these requirements appear?
(portType, operation, individual messages)
c. If so, should consistency checks be performed to ensure that
a binding that claims to implement a portType contains
concrete bindings for required features/properties?
d. What are the new syntactic elements?
[6] http://lists.w3.org/Archives/Public/www-ws-desc/2003Jan/0033.html
Topic: properties and features
1.a should WSDL support SOAP f/p or more generally?
[<DonM> See also: http://lists.w3.org/Archives/Public/www-ws-desc/2002Nov/att-0083/01-terse-features.html]
Gudge: SOAP features @ portType level
Roberto: Concerned about testability. Abtract features are very
difficult to test. Message signing, for instance. at the
abtract level it is easy to say, but making it concrete is
very tedious and lots of variations.
Glen: Not to describe every possible interaction, just give an idea
what is required. Fwk for doing it, but not known how far one
can go with it.
Don: Adding first class features that can be reused by other specs.
Roberto: One can use abstract portion of WSDL and that complicates it.
When connecting to svc binding are enough, why is it necessary
to repeat it at the abtract level?
Don: Fuzzy on abstract, but solid on concrete...
Jonathan: Does this mean yes or no for 1.a?
Tom: Example features besides SOAP?
Gudge: We just support any.
Glen: Features are applicable to a wide range of things, and this
is what do discuss.
Tom: Are these generic switches for SOAP props/features?
Glen: Yes, similar.
Jonathan: Is security such example generic feature?
Glen: Tagging things with URIs is really important and it makes it
clear what's involved.
Roberto: In paris it was decided to go with QName extensibility. Why is
QName not useful for doing exactly that?
Umit: URIs are more robust.
DBooth: URIs are more likely to be dereferencable.
Roberto: URIs are just strings and QNames can hold structured data.
Jonathan: What we get from doing this at the abstract level?
Gudge: Tom will have to remember all those URIs :)
Glen: Originally properties were QNames. This is not important now.
QNames have a problem with RDF mappings. Need a common way
to talk about common things extending WSDL. Requirements and
restrictions.
Jonathan: Spec writers writing a clean spec.. with QName we don't
provide a good way....
Gudge: We have substitution groups...
Jonathan: f/p proposal is easier, but lacks the flexibility in comparison
Glen: The semantic that affects the "wire" is what's important.
Jonathan: How is it different from the existing language ext model
Glen: When writing exts, f/p shows the way. best practices... It is
also SOAP 1.2 compliant and therefore it is "architecturally"
natural.
Jonathan: Opinions?
Jonathan: Examples are needed
Umit: Have not seen compelling arguments for the change
JeffSch: Need more discussions.
Glen: Can start with SOAP and we have to capture that. we could do
it other way, but more natural is to follow the same approach
as in SOAP. Narrowing ext model with f/p is not making it
worse than it already is.
JeffSch: Table this discussion and deal with it later.
Glen: ok
d??: decided to identify MEPs as URIs and it sounds a lot like
feature. it seems 1.a. we've already done it at the abstract
level and just say that we have it.
Gudge: You could already do this given what we have, glen just wants
to make it more specific.
d??: Just document it then and that is it.
Jonathan: Suggestion to table 1.a for a while until we see the value of
SOAP f/p in the binding (next F2F, possibly)... anyone?
JeffSch: So 1.a is answered SOAP 1.2 way?
Jonathan: Just saying table 1.a
Don: Wanted to define message correlation as an abtract feature...
Glen: Yes, but there is no other binding except SOAP that needs this
Don: for out-in and all
Glen: Can say 1.a postponed and let's deal with SOAP 1.2 f/p
Gudge: Sanjiva also has input here...
Jonathan: No objections to postponing 1.a.
Jonathan: Skip the whole f/p topic as key people are missing.
Don: What the best resolution on f/p for the grp. Should we just
form a TF.
Jonathan: There is no clear statement so far as to why is it needed.
Glen: TF should create a few examples. syntax too,
Gudge: Better do the examples at the component model
Jonathan: How much is syntax and how much is CM
Gudge: What the props are and what they mean has to be understood.
Glen: The CM is hanging off the service description and the f/p
are the runtime details.
Gudge: why in WSDL?
Glen: Because of binding details.
Glen: Different binding can do it differently, but stick to the
same semantics.
Roberto: Strip out WSDL abtract features, does it prevent talking to
that svc?
Glen: no
Don: It just says the op has to be secure and then binding would
map it to proper transport or do the hdr work.
Roberto: The abtract part can be used to model svcs and this is not
very necessary.
Glen: Fwk is useful, though.
Roberto: Why make it 1st class if it does not have any implications.
Glen: An example is SOAP mustUnderstand... it allows things to be
done, but not mandates any.
Jonathan: Maybe we just don't have much experience extending WSDL
using existing ext model. Maybe we just have to come up with
examples of one and the other and compare then?
Jonathan: No objections to form the TF for that.
ACTION: Glen, Amy, Yoen, Sanjiva, JJM to form a TF on comparing ext
mechanisms, popose f/p reasoning and examples (use cases) for that
Jonathan: (1) portType op name conflicts or (2) finish up the faults
SteveG: Let's continue on faults because (1) is too important for [Grid?]
Topic: Continuing on MEPs/faults
<plh-az> back to http://www.w3.org/2003/01/meps.txt
Tom: Any msg can be a fault, the last msg can be a fault?...
Tom: Any out msgs can be a fault? is that true?
Jonathan: in, ofault | out*
JeffSch:
c21. in,(ofault|out*);
c22. in,(ofault|out)*;
c23. in, out*, fault?
Tom: Can there be more than one fault? c22 is not acceptable
impl of c2.
Roberto: No data fault and then yes not got the data for you.
Tom: Fault means termination.
Gudge: Agrees
c23 now
Gudge: Last one is the termination message, essentially
Tom: Proposes that c21 is not acceptable
Gudge likes c23
c21 removed
f1. out, in*, Ifault?
f2. out, (in | fault)*
f3. out, (in* | Ifault)
Tom: Need to teat each MEP instance separately
Gudge: No, service talks to the bus and the bus talks to 50 guys.
Umit: It is like a broadcast.
Don: Not modeling a 1-1.
Tom: Each instance is different though, even if same MEP.
Gudge: It is same as b2 anyway.
Tom: Bus is not a WS assumption.
Gudge: Broadcast is a different case then.
Umit: It's very general, e.g. JMS.
DBooth: When e-mailing to a list logically it's same as e-mailing
to one and broadcast is transparent.
Tom: WS communication is P2P, e-mail is a different case'
Don: It is not always P2P...
DBooth: Are you saying that client in MEP represents a set? It is
very different than treating MEPs between single nodes.
Don: Svc gets message from all arround.
Roberto: In f1 fault allows control on how long the communication has
to go on. In f2 is like receiving a reply from multiple
parties.
DBooth: Do we need to model when a client is a set. Personally he
does not want to go there.
JeffM: For pub-sub multiple of these models apply. which should be
defined in the core...
MikeM: Value of use case in general should drive this.
Umit: If it is not pub-sub it is P2P. we need to make this
distinction and classify MEPs accordingly.
JeffSch: Specifying channel helps make it clear which MEP is which
class.
DBooth: How can we specify client as a set. How are the end-points
layed out?
Don: There are no client end-points.
JeffSch: IRC is an example.
DBooth: Recipient is decided transparently then? It is possible to
model client set with just same MEPs. Just apply it to 50
instances of communication.
Jonathan: Is it compelling way to solve donm's issue?
Don: One MEP from the svc standpoint, but it gets to deal with
many clients transparently.
Tom: It would not be reasonable to spec this in this grp.
Don: We have enough representation to make a proper decision on
this.
Tom: If it is a commonly used MEP, then ok.
Roberto: Mirror WSDLs... argues symmetry of MEPs
[<Roberto> the correspondence is:
a1 <--> d1 ;
b2 <--> e ;
c23 <--> f1 ;
f2 <--> b2 (surprise!)
]
Who will write these MEPs?
- f2 Amy will write about
- a1 tom agreed to write about
DBooth: confused by the N-ary thingy in f2
JeffSch: If it is possible to make a good MEP there, it is actually
very good
DBooth: What is the client case for f2?
Gudge: b2
DBooth: Client generates code from WSDL what is it going to be?
Gudge: The cardinality of the things at the other end and
cardinality of the messages and both have to be captured
in MEP and taken into account when gen code for svc and
the client.
JeffSch: Client has to underatand the MEP of the svc...
Gudge: N-ary applies to the whole thing in f2.
Jonathan: Details of that Amy has to explain (e.g. cardinality and scope)
Jonathan: Also sycn with WS Arch WG to see where it all [MEPs] goes...
JeffSch: Wants to write first 6
ACTION: JeffSch and Gudge take first 6 MEPs to develop
...discussion on the place for faults....
ISSUE: where faults can appear, header faults, etc.
ACTION: Amy/Don take f2 MEP to develop
Roberto: Only first 3 have to be fully defines and the following
3 are merely mirrored direction
Gudge: Still wants separate URIs for identify all 6
Jonathan: separate, but complimantary
ACTION: for the editors to close (remove) out-only and solicit-response
issues from the list (as covered by this MEP work)
17:30 Adjourn
-------------------------------------------------------
raw IRC log: http://www.w3.org/2003/01/20-ws-desc-irc
Received on Friday, 24 January 2003 14:42:31 UTC