W3C home > Mailing lists > Public > www-ws-desc@w3.org > December 2002

Notes, 17 December 2002 MEP telcon

From: Jonathan Marsh <jmarsh@microsoft.com>
Date: Tue, 17 Dec 2002 13:57:14 -0800
Message-ID: <330564469BFEC046B84E591EB3D4D59C08ABBFAC@red-msg-08.redmond.corp.microsoft.com>
To: <www-ws-desc@w3.org>

Notes on Tuesday 17 December call on MEPs

Present:
  Gudge, Jonathan, Don Mullen, Youenn, Sanjiva (Gudge takes notes)

Summary:
- General agreement that WSDL is written from POV of service
- General agreement to define MEPs at an absract level (by referring to
SOAP MEPs or by defining our own MEPs, or having WSArch define it)
- No conclusion about whether we need to define a binding for each MEP
- Which specific MEPs do we include in our spec?  Seems to be interest
in adding more over and above the ones we have.

Cleaned up IRC log:

<DonM> discussion topics:
http://lists.w3.org/Archives/Public/www-ws-desc/2002Dec/0068.html

1) Should WSDL continue to define operations from the 'service' POV? 
JMarsh: Is this related to reusing the MEP Framework from SOAP?
Youenn: MEPs have the idea of direction, so you need to say somewhere
what that direction is
Youenn: e.g. IF we define solicit-response it would be implemented using
a request-response MEP
DonM: Should seperate out the binding specific MEPs from abstract (
portType level ) MEPs
Youenn: At the portType level it's abstract, no notion of direction. But
at the operation level direction becomes important
DonM: If we add serviceRole to operation then things can get confusing
as to what the WSDL is specifying ( as far as is it a service POV )
Youenn: It's still the service POV
DonM: Don't you get the same thing by defining specific message roles?
Youenn: If we say input is request and output is response then we will
be stating request/response semantics twice
Sanjiva: But then I have no idea what I'm going to be receiving and what
I'm going to be sending. It's very confusing
Youenn: But using Don's idea you say twice what the direction is
Sanjiva: I disagree that it's defining it in 2 places. 
Sanjiva: There is only one place
DonM: In some cases will be important to identify the specific roles
that each message is playing
Youenn: If we have a MEP that defines 3 messages, A, B, C. In the
operation we will say A is of this type, B is of another type and C is
of another type
Youenn: And then different roles will define the direction
DonM: Your other example of having request-response with a different
serviceRole isn't that the same as output-input
Youenn: IN my proposal there will be no more input/output, just types
for the request and response messages

<youenn> <operation mep="request-response" direction="inbound">
<youenn> <...:request type=""/>
<youenn> <...:response type=""/>
<youenn> </operation>

Sanjiva: Defining things and not knowing the perspective seems highly
confusing. It should just be from the service POV
DonM: Concur with Sanjiva
Sanjiva: In WSDL 1.1 they were called request-response operations etc.
In WSDL 1.2 we decided to use more generic names

Youenn: Explains Don's examples ( I think )
Sanjiva: Could use symbolic role names and have the MEP provide
semantics.

<DonM> <operation mep="request-response">
<DonM>   <message role='request' type='xx'/>

Sanjiva: Where do we say input is a response
Youenn: It's in Don's example
Sanjiva: Could use input/output and use them consistently
DonM: Disagree, you are interpreting it differently to what Sanjiva and
I are thinking
Gudge: Why is using MEP and role simpler than saying 'all MEPs are from
the POV of the service'?
Youenn: I dislike having input/output or output/input that is using the
order to determine what type of operation it is
Gudge: Don't understand why order is confusing or error prone
Youenn: We should fix the semantic of output-input
DonM: We should define multiple semantics
Youenn: We should define multiple MEPs
Sanjiva: Partially agree that semantics come from the binding
Sanjiva: output-input has several different interpretations, one output,
one input or one output, multiple inputs
Sanjiva: MEPs document what messages go in and out of the server
Sanjiva: Not convinced that moving away from a 'server only POV' is
useful
Youenn: MEPs don't know anything about direction. We should define WSDL
MEPs same as SOAP MEPs and then put the direction on the operation
Youenn: WSDL should enable me to define things from the client POV too
Sanjiva: So you're saying we should allow things to be define in terms
of what an endpint offers and what it requires
Youenn: I think you can define a MEP and say whether you provide it or
require it
DonM: Seems more complex to be able to define things from both POVs
Youenn: It's only one extra attribute
Youenn: My solution meets Jeff and Gudges requirement for input/output
and output/input ops in the same port type

Everyone agrees that WSDL is written from the POV of the service
Marsh: It seems to me that we have a need to describe message exchange
abstractly
Marsh: If we can do that more thoroughly by refering to SOAP MEPs or by
defining our own MEPs ( or having WSArch define it )
Marsh: Do people agree that we need to do this?
(General agreement)

DonM: We need to coord with WSArch and make sure MEPs are defined at an
abstract level
Marsh: We should give WSArch specific text
Marsh: Once we have a level of detail we want, the second question is
what syntax we need in the language
Sanjiva: One way is to define the semantics of message exchanges. And
then define syntax for as many message patterns as we care about
Sanjiva: How do we define the semantics for the things in our spec
today?
DonM: Does Sanjiva like the idea of defining syntax for each MEP?
Sanjiva: Could lead to interop problems
Sanjiva: Some things cannot be fully documented in WSDL
Sanjiva: We look at the messages that go in and out of a service and
give that set of message exchanges a URI? MEPs are at the 'operation'
level, not at the portType level. Tying together different operations in
a portType is orchestration.
Gudge: Tries to understand what level things are being defined at
DonM and Sanjiva: Explain to gudge that it's at the operation level
Sanjiva: Take a crack at a framework for abstract MEPS and define MEPs
for the operations types we have today
DonM: We should have multiple MEPs for some of our operations
(Some discussion about whether MEPs make sense at the portType or
binding level)
(Some discussion of pub/sub and eventing)
DonM: Example of output/single input and output/multiple input.
Difference needs to be captured at the portType level
Sanjiva: Need to address semantics of operations.
DonM: Another issue: HTTP binding
DonM: There seem to be a good number of people who think that all MEPs
have to work over HTTP
DonM: Don't think all MEPs will work with HTTP
Gudge: +1
Sanjiva: I'm not saying that all MEPs have to work over all transports.
Why would we define a MEP that we don't define a binding for
DonM: Don't have a problem providing building blocks that other people
can use
Sanjiva: Having multiple interpretations of operations is bad
Gudge: Not sure I agree that multiple interpretations is bad
Marsh: There are two proposals we could ask the WG to consider. 
Marsh: We could add an extensible MEP mechanism
MArsh: Do we use that mechanism to define our current operation types
Marsh: Summary
DonM: General agreement that WSDL is written from POV of service
DonM: Report on serviceRole discussion
Marsh: But have no definate conclusion
DonM: General agreement to define MEPs at an absract level
DonM: No conclusion about whether we need to define a binding for each
MEP
Marsh: Would be nice but not a showstopper if we can't do it
DonM: Other question is which specific MEPs do we include in our spec?
Marsh: Seems to be interest in adding more over and above the ones we
have
Received on Tuesday, 17 December 2002 16:57:45 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:58:22 GMT