Re: issue 26: transmission primitives

I think I have indeed raised this at the f2f. I think the WG decided that this
was not a dup, but a SOAP 1.2 issue, i.e. how we support SOAP 1.2 MEPs in WSDL
1.2, at the binding level.

Jean-Jacques.

Sanjiva Weerawarana wrote:

> I propose that we close the following issue as its redundant
> against an already closed issue in the part1 doc:
>
>   <issue>
>     <issue-num>26</issue-num>
>     <title>transmission primitives</title>
>     <locus>Spec</locus>
>     <requirement>n/a</requirement>
>     <priority>Design</priority>
>     <topic></topic>
>     <status>Active</status>
>     <originator><a href="mailto:ruellan@crf.canon.fr">Herve
> Ruellan</a></originator>
>     <responsible>Unassigned</responsible>
>     <description>
>     [<a
> href="http://lists.w3.org/Archives/Public/www-ws-desc/2002Apr/0024.html">ema
> il</a>]
>     [See also issue 35-36]
>     <pre>_Background_
> Currently WSDL 1.1 defines 4 transmissions primitives (one-way,
> request-response, solicit-response, notification).
> SOAP 1.2 defines the concept of Message Exchange Pattern (MEP) [1]. A
> MEP is a template for the exchange of messages between SOAP Nodes.
>
> _Issue_
> In its current state, WSDL 1.1 is not able to define which MEP a Web
> Service will use over a SOAP binding (several different MEP can define a
> one-way transmission primitive).
>
> _Proposed solution_
> As MEP are almost independant of SOAP 1.2, I would suggest replacing
> transmission primitives by MEP.</pre>
>     </description>
>     <proposal>
>     </proposal>
>     <resolution>
>     </resolution>
>   </issue>
>
> The corresponding issues in the part1 doc make this redundant:
>
> <issue id="issue-operation-patterns" status="closed">
>   <head>Should more operation patterns be supported?</head>
>   We discussed this briefly at the April F2F (perhaps) but, I think
>   it would be extremely helpful to permit alternate and multiple
>   responses to a request. That is permit multiple output messages in
>   an operation like we have multiple faults in an operation. It would
>   then be helpful to make them alternate or sequence. That is, do all
>   of them come back or just one of them.
>   <source>Prasad Yendluri</source>
>   <resolution>This issue is closed by leaving it to the realm of
>   orchestration languages and applications. June 11, 2002 (at
>   face-to-face).</resolution>
> </issue>
>
> <issue id="issue-extensible-message-exchange-patterns" status="closed">
>   <head>Should we have a mechanism to define extensible message
>   exchange patterns?</head>
>   See http://lists.w3.org/Archives/Public/www-ws-desc/2002May/0271.html
>   <source>Glen Daniels</source>
>   <resolution>This issue is closed on the basis that the open-ended
>   extensibility model we have adopted enables the description of
>   arbitrary message exchange patterns. June 11, 2002 (at face-to-face
>   meeting).</resolution>
> </issue>
>
> Any objections?
>
> Sanjiva.

Received on Thursday, 20 June 2002 11:23:26 UTC