MEPs TF minutes 20030331

Participants: David, Amy, Jonathan, Philippe, Sanjiva (late)
Regrets: Umit
Missing: Gudge

Agenda:
http://lists.w3.org/Archives/Public/public-ws-desc-meps/2003Mar/0010.html
- MEPs vs IOPs document 
- Use cases that accentuate the trade-offs between using MEPs versus
IOPs
- How MEPs would be indicated in bindings
- Amy's suggested use cases

Topic: MEPs vs IOPs document 

http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl12/meps-vs-iops/meps-vs-iops_clean.htm

David: one of my intent was to use this as a basis for the work in the
TF.

Jonathan: would then be involved in the report?

David: yes. other comments about it? showed the correspondence between
IOPs and MEPs. try to isolate the difference implications of IOPs vs
MEPs.

Jonathan: ok, so the document differentiate clearly IOPs and MEPs. the
question is whether or not the difference needs to be exposed at the
abstract level in WSDL. is this addressed in this document?

David: no but it enumerates the pros and cons. in order to highlight
those, I have the use cases section.  we have a couple of use cases for
the moment. didn't do the pros and cons yet.

Amy: what happening is the question of how much semantic constraint is
in WSDL.  interactions with protocol capabilities.  one thing would be
to consider proposing to create an interface based on IOPs, then take
some protocols to express those.

ACTION: Amy to generate an example of an interface defined in terms of
an abstract IOP, with two different protocols binding that as
*different* MEPs.

Jonathan: is it possible to define one WSDL with IOPs/MEPs and bind that
to a request-response case and something which is not req-resp.

David: other use cases might demonstrate that it is useful to model MEPs
at the abstract level.  other missing thing: some clear understanding of
if the information is not available at the interface level, how would it
be at the binding level?

Amy: what we did in Scottsdale was to provide a set of definitions,
which
was used to draw the original WSDL draft. sequence, directionality,
cardinality and fault. but nothing else.  nothing about the interesting
MEP http://www.w3.org/2003/03/An_interesting_MEP.html

Amy: it would be useful to figure out what else do we need
(requirements, clauses) to allow to say: this is a MEP and IOP. "what
makes a MEP?"

David: there is an arch definition and a soap definition.

Amy: there is also the question of direct specification of faults in the
patterns.

[Sanjiva joins]

Amy: any message may trigger a fault or a fault may be substitute at any
message in the pattern after the first one.

Philippe: if you have (out)+, you can't expect a fault in the middle.

Amy: disagree. you can have a service that send a fault in the middle.

Sanjiva: comment on the MEP part someone from IBM looked at it and had
no clue what is was talking about.  pictures would be helpful.
http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl12/wsdl12-patterns.html

David: in other words, he is expecting MEP and what is currently
described are IOPs.

Sanjiva: the cardinality question came up.

[...]

Jonathan: the current MEP part represents the statu quo. the output of
this TF will probably influence it.

[...]

Philippe: In my mind, WSDL described an interaction between a client and
a service.  If try to represent IOPs it may be more than just another
client the service is interacting with. What use would it be for a
client to know that the service is interacting with another client?

Amy: It's important for Pub-Sub. It's important to know that others may
be subscribing to it.  It's important to each client to know that there
are other clients in competition.

Philippe: It would be relevant at the abstract level to know, but at the
binding level it doesn't change anything.

Amy: Generally in terms of Pub-Sub, the client simply subscribes.  There
is a subscriber, and 0 or more publishers.

David: the point of view is really a separate issue.

Sanjiva: but it affects the language. what I need in WSDL is what the
client needs to know. pick up the WSDL and use the service. you can
document a contract between 2 parties using BEPL...

David: [clarifying] looking at the purpose of the WSDL is to ensure that
the parties that will interact are in agreement on how they interact.
the point of view is not important, at the abstract part.

Amy: you're leaving power dynamic. it's a take-it-or-leave-it
contract. it is a contract between a service and its correspondents.

Sanjiva: WSDL may not care if more than 2 parties are involved.

David: do we have agreement that WSDL represents the contract between
interacting parties?

Philippe: 2 parties...

Amy: disagree. but we have one service.

David: no, in UC1, BigCo wants to interact with its suppliers. the WSDL
is given to the suppliers. the suppliers implement the service: abstract
part of the WSDLs are the same.

Sanjiva: there is no single contract between the 2.

David: 2 completed WSDL in this case. for the complete WSDL, there is
one service. the abstract part can be implemented by more than one
service.

Philippe: do you envision bigCo asking for the suppliers to use
broadcast-type IOPs?

David: it doesn't preclude to do so.

Amy: it's a contract in a sense of a software license. problems with the
term "contract".  it's a set of requirements.

David: so, should we use "requirements"? "take-it-or-leave-it" contract?

Sanjiva: WSDL describes what the service can do from its point of view.

Amy: disagreement is that the contract is between 2. WSDL describes one
server and any number of correspondents. we have a fair amount of
agreement that we have a contract offered by the service, without
negotiations. describe the contract between the service and each of its
correspondents.

David: at the interface level, it may well applied to multiple services.

Philippe: when we model the web, we don't "care" that we can reproduce
10 millions of time the interaction between the client and the service.

Amy: [...]

David: at the abstract level, we can either model using IOPs or using
MEPs. there is more information using MEPs. I'll add a section for
recommendations at the end following Amy's suggestion.

[...]

Amy: seems that Sanjiva would like to make something out of our
recommendations: make it stronger, or replace it.

Sanjiva: I'd like to understand why we don't document MEPs instead of
IOPs in the MEPs part.

David: at the f2f, it became clear that the group had misunderstanding
on the Scottsdale consensus.  and the group said that there is an
important need for at least a req-resp MEP.

Amy: I would argue that there was no enough understanding of the
restricted definition for patterns.

Sanjiva: to document your MEP, I can document that using a choreography
language. we should not go there.

Amy: so we should restrict at IOP?

Sanjiva: no 2 parties only.

David: so it's MEP?

Sanjiva: the first picture (in David's mesage) identifies the parties,
that should be leave to choreography.

David: would like Sanjiva to come up with a use case regarding the
advantages of IOPs and disadvantages MEPs.

Sanjiva: I believe that documenting the MEP would be more functional
that documenting the IOP. However, I don't believe that's in scope for
WS-Desc. (where "that" refers to MEP)

Amy: if I understand Sanjiva: there is a point in the MEP at which it
becomes choreography, rather than WSDL.

Sanjiva: fundamental misunderstanding of terminology here :(

Amy: agree.

David: anybody can make suggestion of things that are misunderstood to
the list.

Next teleconference:
This Wednesday.
 Regrets: Amy

Received on Monday, 31 March 2003 16:53:50 UTC