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:]
> Sent: October 14,2003 16:32
> To: Payrits Szabolcs (NMP-MSW/Budapest)
> Cc:
> Subject: Re: [wsrm] [REL-XX]Proposal for POLL RM-Reply Pattern
>
>
>
> Szabolcs,
>
>
> 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.
