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

[Sunil Kunisetty <sunil.kunisetty@oracle.com>]

 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.