Re: [wsrm] [REL-XX]Proposal for POLL RM-Reply Pattern

[John Fuller <jfuller@wernervas.com>]

I agree with Sunil that Headers are a good place for extensible information, a good place for information
to be handled by other layers than the application layer, and convenient for implementations in general.

I agree with Szabolcs that Status Request and Response messages need not contain any other content, unlike the headers we layer into the other messages that may have other purposes.  Since these messages may standalone in intent, there isn't a worry about what's in the body: the message really serves only one purpose.  Piggybacking acknowledgements returned in response could be handled by returning a list of service instance statuses in the body of the response.  If the proposed Rq/Rsp messages don't accomodate acknowledgement piggybacking, I think the ASAP draft deals with situations where the observer queries for
a range of responses.


On Friday, October 10, 2003, at 11:16 AM, Sunil Kunisetty wrote:

> Szabolcs,
>
> Before I answer your questions, could you go on record with your position  on
> WSDL? I remember you saying to me at the Redwood City F2F, that you don't
> care about WSDL, and that WSDL is not important. And at the recent Boston F2F,
> you were arguing that a (wsdl) one-way MEP can have a  SOAP envelope in
> the response.
>
> Don't we have a requirement that user's contract for which RMP provides
> reliable messaging service should be defined in WSDL? I believe we also
> say this in our charter?
>
> Szabolcs.Payrits@nokia.com wrote:
>
> > Hi,
> >
> > Unfortunately I have to answer in short due to lack of time, I apologize beforehand.
> > There are some point I don't agree in Sunil's mail and I have my own concerns with Poll operation in Header.
> >
> > > "If this Poll request has to be sent in the SOAP Body, then it has to be defined in the WSDL unlike in the Header case."
> >
> > I am not sure. Where is it written, that you HAVE TO define in WSDL the SOAP operations that are in soap:Body? Where is it written that this is not mandatory if you put
>
> So essentially you are saying that WSDL is not the contract and rather it's
> an open ended contract?  So essentially you are saying that the service
> endpoint should honor some requests (assume they are namespace
> qualified) even though they are not defined in the Port/PortType, right?
> So If I've PortType1 with operations 'a','b', and 'c' and PortType2 with
> operations 'x', 'y', and 'z'? Essentially you are saying  that I can send
> operation 'z' to PortType1 and 'a' to PortType2, right? If the answer is yes,
> I don't think I'll spend my invaluable time convincing further. I'll rest my case then.
>
> > What makes the difference here?
>
> The difference is  Headers are the extensible mechanisms in SOAP. See
> my original snippets and the reply I sent to Scott.
> Headers can be sent
> i) Without be defined in the wsdl as long as it is namespace qualified.
> ii) Can be forced to send it by defining it in the SOAP Binding with mU=1
> iii) Can be optionally defined with mU=0
>
> > My concern: Combination of Poll operation and Application-level operations. There are two possbilities:
> > 1. You don't combine them => same XML elements in the Header and Body case, only difference is that you pick out of the <soap:Body> or from the <soap:Header> element. Why would it bother you if the specification would leave you the option of NOT putting the operation into the WSDL, if it is a problem for you. Maybe there are WSDL-level problems, but you shouldn't care if you don't want to publish the poll operation in WSDL.
> > 2. you combine them => how do you handle two differnt MEPs in the same tranport-level entity (HTTP transaction). How do you define the "state machine" that is associated with MEPs? What if one fails, other succedes? What if both fails?
> >
> > > "Looks odd. All other RM operations are expressed in Headers."
> >
> > It depends. I think that is what common sense requires.
> > Other functionalities (I don't call them operations) of WSRM are supplementary functions, and are closely associated with the payload. This one is different, it has nothing to do with the actual payload.
> > I imagine SOAP headers similar to XML attributes: they tell something about the actual operation. They are not operations themselves.
> >
> > > "Generally speaking Body contents are meant for end applications"
> >
> > I could agree with you, if we would not have decided at the first f2f that SOAP intermediaries are out of question. The consequence of leaving out intermediaries is that you don't differentiate on the SOAP level between "end application" and "WSRM". Yes, if
>
> I don't understand this. If someone can enlighten me, I'll appreciate it. I don't understand
> what has this to do with SOAP intermediaries.
>
> > there WERE SOAP intermediaries, then this operation  should be addressed to that intermediary in a way or another, and there would be a problem to solve. But there aren't.
> >
> > > "Most of us (at least all the Interop participants used some sort of Handlers) will be using Handlers for the RMP implementation. JAX-RPC Handlers are meant to be triggered based on certain Header"
> >
> > Altough general implementation implication must be taken into account, my belief is that tailoring the specifications to specific proto-implementations is a bad specification
>
> I don't think we are tailoring anything for any specific implementations. At the same time
> we shouldn't impose any "additional" restrictions that would hamper the most common
> implementation infrastructure.
>
> > practice. Especially to tailor to specific tools used for the protos.
> >
> > > "Piggybacking will be prohibited."
> >
> > Why ?
>
> If you are sending it the SOAP Body, how can you piggyback on another
> request?
>
>
> > > "There is nothing wrong in sending operations in SOAP Headers.
> > a.       It won't be re-inventing a new MEP, as MEPs deal with Senders & Receivers and not Body or Header. The current proposal still constitutes the R-R MEP."
> >
> > Right, but if you put it into the Body, then the MEP is handled by the SOAP library
>
> What?
>
> > (whatever SOAP library you are using). In the latter case, you have to implement the state machine associated with the R-R MEP. And if you enable the combination of poll operation and application-level operation, then you will also have to find out how tho handle two MEPs at the same time.  I would prevent combining the Application MEP and poll MEPs.
>
> Agree. That's the reason we shouldn't  combine them in the application's WSDL.
>
> -Sunil
>
> > I repeat this latest argument, because that is my major problem.
> >
> > The other issue is secondary to me: if the difference is REALLY only the place of the XML element, and otherwise everything is the EXACTLY the same, then it is just a matter of taste, and maybe question of tools used in protos (altough I still think this latter is not a valid argument).
> >
> > Best regards,
> > Szabolcs
> >
> > > -----Original Message-----
> > > From: ext Sunil Kunisetty [mailto:sunil.kunisetty@oracle.com]
> > > Sent: October 07,2003 19:34
> > > To: wsrm@lists.oasis-open.org
> > > Subject: Re: [wsrm] [REL-XX]Proposal for POLL RM-Reply Pattern
> > >
> > >
> > >
> > > All,
> > >
> > > Attached is my document with my comments and requirements list.
> > >
> > > -Sunil
> >
> > To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/wsrm/members/leave_workgroup.php.
>
>
> To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/wsrm/members/leave_workgroup.php.