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

[<Szabolcs.Payrits@nokia.com>]

	Hi,

 I think I've told all my technical arguments and clearly expressed my proposal as well. 

 I'm not into personalities, so I am out of this thread.


	Best regards,
		Szabolcs

> -----Original Message-----
> From: ext Sunil Kunisetty [mailto:sunil.kunisetty@oracle.com]
> Sent: October 14,2003 16:32
> To: Payrits Szabolcs (NMP-MSW/Budapest)
> Cc: wsrm@lists.oasis-open.org
> Subject: Re: [wsrm] [REL-XX]Proposal for POLL RM-Reply Pattern
> 
> 
> 
>  Szabolcs,
> 
> 
> Szabolcs.Payrits@nokia.com wrote:
> 
> >                 Hi,
> >
> >  Before answer you mail, I express my hope that we can come 
> to a compromise in the end.
> 
>  As I said on the 2nd mail on this topic, I'm all ears on any 
> proposal as long as
>  it doesn't put additional design/implementation constraints.
> 
>  Also, most of the replies on this topic is nothing but 
> rumblings. I haven't
>  seen a complete & concrete alternate proposal with all the 
> details and
>  how this alternate solution solves the problems I mentioned before.
> 
>  As I agreed before, the only issue with my proposal is 
> un-intutiveness.
>  Except for that I don't see any problem with that. Other 
> pseudo proposals
>  are some what less un-intutive and have problems with them.
> 
> >
> >
> > >  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.
> >
> 
>  It is important to know this as it will reflect your 
> commitment and understanding.
>  I apologize upfront to say this, but you don't seem to be 
> reading all my mails nor
>  you seem to understand the usage & importance of WSDL.
> 
> >
> > >  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
> 
>  Strange. Let me quote something from your email which 
> prompted my response.
>  You said earlier:
>              "Where is it written, that you HAVE TO define in 
> WSDL the SOAP
>               operations that are in  soap:Body? ".
> 
>  So, now you are saying that you don't like that idea.
> 
> > 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.
> 
>  Few comments:
>  1) As I've been saying for a long time, I'm not treating 
> Poll as an operation,
>      rather QoS directive just as "AckRequested" and 
> "DuplicateElimination".
>      If according to you it's  the latter 2 are operations 
> (because they are doing
>      some RM actions), then fine, treat PollRequest as an operation.
>      But then it is nothing different from the others.
>  2) Operations can be sent in Headers as pretty much most QoS 
> WS specs.
>       are doing. I don't think it is written any where that 
> operations cannot be
>       sent in Headers.
>  3) There is a distinction between User operations and System 
> operations.
>       The former is generally defined closurely in WSDL and is sent in
>        SOAP:Body and the latter may or may not be defined in 
> WSDL (using
>       SOAP Headers in SOAP Binding part) and is sent using SOAP
>       Headers.
> 
>  So I don't understand what you are trying to highlight here ...
> 
> >
> >
> > > If the answer is yes, I don't think I'll spend my 
> invaluable time convincing
> > > further. I'll rest my case then.
> >
> >  Well...
> >
> 
>   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.
> 
>  First of all what SOAP "roles" has to do with it.
>  Second of all, there is distinction with User operation and 
> System operation (even
>  though I'm not treating Poll as an operation).
> 
> >
> >
> > > > 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.
> >
> 
>  Not necessarily.
> 
> >
> > 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.
> 
>  We don't differentiate anyone in between, however, on both 
> ends we distinguish
>  RMP/SOAP processor with the application layer. Look it all 
> our pictures in our
>  specification.
> 
> >
> >  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.
> 
>  Why not?
> 
> >
> >
> >  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.
> >
> 
>  I understand, but I don't understand the relevance here.
> 
> >
> > > > (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.
> 
>  So what is your proposal? Who ever is proposing one, could 
> send in another
>  mail the complete proposal.
> 
> >
> > I simply don't want to mix different MEPs (dont' repeat my 
> section above). And definitely
> 
>  who is mixing the MEPs?
> 
> > NOT piggybacking the poll operation on the top of any other 
> operations.
> 
>  Why not?
> 
> >
> >
> >  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.
> 
>  If piggybacking is your only concern, and everyone has the 
> same concern, we can
>  exclude it.
> 
>  As I said before, yes there are some issues with 
> piggybacking in this case, but
>  the issues are general as in  other piggybacking messages we 
> will. If we solve
>  them with certain rules, we could apply the same rules here 
> without any problem.
> 
> 
> >  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.
> 
>  As I said before, you can still do that without any problem 
> if it was in Header or
>  using annotations.
> 
> 
> >
> >  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").
> 
>  I don't understand the concern. Do you mean 
> WS-ReliableMessaging etc...?
>  If some WS-Reliability supports  the Poll operation as 
> specified, why won't it be
>  interoperable?
> 
> >
> >  However, I hope  (and only hope), that this would not be a 
> fatal problem.
> >
> >                 Best regards,
> >                         Szabolcs
> >
> > 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.