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

[<Szabolcs.Payrits@nokia.com>]

		Hi,

 Before I answer you mail, I express my hope that we can come to a compromise in the end.
 
>  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?

 I can't really see your point why you mention my personal comment here. At that time Nokia had no special interest in WSDL, because we had been in Web Service areas, where WSDL was secondary, therefore for us it was more important to proceed with the specificaiton than to argue about WSDL.
 However, we have realized that WSDL is important for other participants in this TC, therefore we cannot disregard it. Other factors have also been changed. 
 Of course, we have different perspectives, but this fact itself shouldn't prevent us from having a fruitful debate.

>  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?

I don't like this idea. I think it is rather you, who demand it. You have been brought up lot of arguments, why you don't want to include the poll operation in WSDL. 
 So do you want these operations to be present in WSDL or not?

 I suspect that you think that if you hide the operation in SOAP Headers, then it is will stop being an operation and then you don't have to answer the question above. I think that would just hide the problems not solve them. 

> If the answer is yes, I don't think I'll spend my invaluable time convincing 
> further. I'll rest my case then.

 Well...

> > 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

All these don't change the basic fact: what you have here is an operation. What you are saying here is that it is easy by to hide this operation by SOAP roles. Yes, it is easy. But is shouldn't be done.

> > 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.

Unfortunate you didn't address this point...

> > > "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.

 I think this is a secondary question, but I have to answer to play by the rules.
When we decided not to support SOAP intermediaries, that decision also meant, that from SOAP point of view, we have only two endpoint: sender and receiver. So we don't have more "horizontal" architectural element, and we dont' differentiate between "end-application" and anybody else standing before the "end application" in the SOAP chain.
 On the other hand, you might think of the vertical, layered architecture, when the Body should be sent to the application on the top of the "stack". Yes, this latter is one possible (and clean) scenario, but I can show you counterexamples from existing specifications (Body element intended for supplementar libararies and header elements indended for the application on the top of the stack).
 That's what I was thinking of, but thisoneisn'tthemain point here.

> > > "Piggybacking will be prohibited."
> >
> >  Why ?
> 
>  If you are sending it the SOAP Body, how can you piggyback on another
>  request?

 That's what definitely shouldn't be done.  

 However, sending more Acks in one Response is a question if we really want to have it.

> > > "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?

SOAP library. Whateven an actual applicaton uses. Check this page for the current implementaions of SOAP 1.1: 
http://www.soapware.org/directory/4/implementations
Last time I've checked (mid 2002), there were already 86 different SOAP implemenations.

> > (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.

You apparently misunderstand me. I am not arguing for having it combined with application WSDL. 
I simply don't want to mix different MEPs (dont' repeat my section above). And definitely NOT piggybacking the poll operation on the top of any other operations. 

 But even if I don't like the idea of hiding full-blown operations into SOAP headers, this spec is a common work of us. So I could live with the fact that for sake of peace the operations are put into Headers, if this  operation is cleary defined by the spec as operation, and it is cannot be mixed with other operations. 
 I think the question still remains if you want the Poll expressed in WSDL or not, but we can pretend we didn't have to solve it.
 Even this solution would cause some problem with the interoperability with other WS standards (how you sigitally sign a Poll operation etc. Yes, you might not want to, but somebody may want. And WS specs are meant to be "orthogonal"). 
 However, I hope  (and only hope), that this would not be a fatal problem.


		Best regards,
			Szabolcs