FW: [soaptf] Minutes from today's (7/15) telcon

[Forwarding to the public list as authorized in
http://lists.w3.org/Archives/Public/www-ws-desc/2002Jul/0113.html - JM.]

SOAP TF telcon, July 15th 2002

Present:
    Philippe Le Hegaret (W3C)
    Glen Daniels (Macromedia)
    Sanjiva Weerawarana (IBM)
    Jean-Jacques Moreau (Canon)
    Roberto Chinnici (Sun Microsystems)

Regrets:
    Dietmar Gaertner (Software AG)
    Joyce Yang (Oracle)
    Barbara Zengler (Daimler Chrysler)
    Michael Mahan (Nokia)

Scribe: Roberto


Subject: MEPs in SOAP 1.2

Roberto: MEPs seem very general, they can represent choreographies,
processes, right?
Glen: Right. We should not try to boil the ocean though. We have to deal
at least with
the case of request-response on one-way protocols. If we do the latter,
we may solve
something a bit more general (leaving the rest to future work).
Sanjiva: OK.
Glen: Issue with request-response over one-way: we need a response
address.
Sanjiva: But SOAP doesn't have a one-way MEP even!
Glen: Easy to define. The "experimental" SMTP binding defines a 1-way
binding.
Jean-Jacques: Even that one is request-response, and they use a
correlation property.
Sanjiva: Is a MEP inline in a SOAP message or it understood by sender
and receiver?
Glen: The latter.
Sanjiva: Shouldn't there be a header (or something) specifying the MEP
in use?
Jean-Jacques: The Message Exchange Context lives on every node and
contains the name of the MEP used.
Philippe: No example of this kind in the primer.
Glen: No such header today. Extensibility means that many people will
define their own
extension and the best one will win in the marketplace.
Sanjiva: Let's take the SOAP binding for request-response. It worked in
1.1 because it was
only on HTTP.
Jean-Jacques: We want to support other protocols, say UDP or TCP.
Sanj: Or even two different HTTP bindings.
Glen: Issue: how does the backchannel work? We can: (1) stick MEP URI in
WSDL; (2) specify
where the backchannel URI goes.
Jean-Jacques: We'd like a client to be able to find out which MEPs are
supported by which binding
by looking at a WSDL.
Roberto: If you need to support multiple MEPs for each operation and you
specify them at the binding
level, you risk a combinatorial explosion.
Glen: You shouldn't need that. MEPs should really be specified at the
abstract level.
Sanjiva: No, that ties it to SOAP.
Roberto: Right.
Glen: Features are in SOAP 1.2 spec because that's the first group that
needed them, but they don't
belong there: they should go into a Web Services Architecture spec.
Sanjiva: If you don't have SOAP in the binding, they don't make sense.
Glen: Nothing really ties them to SOAP.
Sanj: We'd need to create our own request-response and one-way MEPs.
Sanj: Any feedback for the XMLP WG? For instance, they don't define a
header for the MEP.
Jean-Jacques: Define a correspondence between WSDL MEPs and SOAP ones.
Do we need a more general
concept of MEPs? How do we tell a client that they need to use a
particular MEP?
Sanjiva: In response-only, should be able to specify how input arguments
are encoded into the URI.
Glen: Using regular expressions.
Roberto: It's a template, really.
Glen: I'd like to see a mapping of SOAP features to WSDL.
Sanjiva: Isn't it a different problem?
Glen: no, for instance it's needed for the webmethod feature (which is
orthogonal to the MEP).
Sanj: So a feature is just a URI and its explanation is plain English.
Glen: Yes.
(Sanjiva had to take another call for a few minutes.)
Roberto: Is there anything in the request-response MEP that prevents it
from being used for,
say, asynchronous RPC?
Glen: No.


Conclusions (to be reported to the WG):

(1) We need to be able to express MEPs in the SOAP binding.
(2) The ability to describe features and MEPs at the abstract level
would be a good thing,
    but right now we don't know how much effort it would take to do so.
(3) Feedback to XMLP WG: lack of something (such as a header) to express
the MEP in use.
    (Glen: perhaps we should say that, for each binding, there must be a
way to identify
    unambiguously the MEP in use; of course, for bindings that support
just one MEP that's a no-op).
(4) Currently, there is no well-defined one-way MEP.

Received on Wednesday, 24 July 2002 18:31:31 UTC