RE: [wsrm] Rel 44: Duplicate Elimination and Time To Live (TTL)

[Paolo Romano <Paolo.Romano@dis.uniroma1.it>]

Scott Werden <scottw@wrq.com> ha detto:

> Paolo-
>
> I agree with your description of the fault/ack message flow. I described the
> same thing in my email I sent yesterday. The important thing is that WS-RM
> may require an additional MEP, beyond the application level MEP defined in
> the WSDL, for it to carry out its ACK or fault, but this would be completely
> independent of, and would not affect, the application MEP.

>However, I am not
> sure this WS-RM MEP needs to ever be defined in the WSDL.

Do we agree at least on the fact that when an application is layered above a
ws-rm processor, the WSDL used to describe the offered service should advertize
the fact that an apposite header has to be used to request the service (i.e. the
first layer of the stack made up of ws-rm processor + application).
This approach would allow a service requestor to distinguish between reliable
and unreliable web services and this does seem important to me. Moreover a
client could also discover what are the supported features of a WS-RM processor
just by parsing its associated WSDL. Of course this could have been done by some
kind of out of band negotiation, but since reliability is a service property I
believe that the WSDL is the right place where to provide such information.

On the other hand, the definition of additional WSDL operations just to
asynchronously receive acks and faults may seem not to be so useful, since, as
you stated in some past mail, the contract between the ws-rm processors is
already defined by these specifications. In practice, once you know that a
service is layered over the ws-rm level, you do already know that the service
provider has to be able to asynch receive acks and faults, and you do not need
to take a look at its WSDL before actually sending back an ack message.

By the way, this is not always true and I can still see a reason why to query an
UDDI repository and retrieve the WSDL associated to the "ACK/FAULTS receipt"
service. And this is because we are including also the callback (polling)
acknowledgment pattern. Suppose both hosts are behind a firewall and
messages/acks can not be sent directly, but only piggybacked in a response. In
this case the above discussed one-way operations would not be supported by the
ws-rm processors, and this could be discovered in advance by both parts through
their wsdl.

Finally, as I think it would not be very hard to define those operations, and as
they would allow us to thoroughly describe our protocol through WSDL, I think we
should make an effort to include them.

Best Regards,

Paolo



>
> Scott
>
> > -----Original Message-----
> > From: Paolo Romano [mailto:Paolo.Romano@dis.uniroma1.it]
> > Sent: Thursday, July 10, 2003 6:02 AM
> > To: Sunil Kunisetty; Paolo.Romano@dis.uniroma1.it
> > Cc: wsrm@lists.oasis-open.org
> > Subject: Re: [wsrm] Rel 44: Duplicate Elimination and Time To
> > Live (TTL)
> >
> >
> >
> > >
> > >  How does "using the Headers" solution solve the above
> > case? If we have
> > >  to send the Fault in Headers (as HeaderFault), that will
> > still result in
> > >  sending a SOAP response and the MEP gets altered.
> > >
> > >  So I fail to understand how the above unresolved case is solved?
> > >
> > >  -Sunil
> > >
> >
> >
> > I might be wrong, but my idea is the following: Let's
> > consider the case when an
> > existing application has defined a one way MEP in its WSDL.
> > If the application
> > layers itself upon WS-RM, the whole WSDL (ws-rm
> > header+app.dependant) should
> > still be one-way. If a fault has to be sent back to the ws-rm
> > sender processor,
> > this is still possible because the latter has defined a WSDL
> > one-way operation
> > for receiving the ack. This message globally alters the MEP
> > and I suppose this
> > is what you do not like of this approach.
> > Anyway this is a WS-RM level message, not an application
> > level message.
> > Therefore, it does not alter the application defined MEP,
> > which is one-way. In
> > fact, if the WS-RM receiving processor sends back a fault,
> > then the message is
> > not delivered to the application, and the application one-way
> > MEP just does not
> > take place.
> >
> > In other words, the application defined MEP simply does not
> > take place, because
> > the message is stopped at the ws-rm receiver. There is no
> > problem with sending
> > back a fault message, because we have defined a ws-rm wsdl
> > one-way operation to
> > receive acks and faullts. So we have a one-way only from the
> > ws-rm sender to the
> > ws-receiver, followed by an asynch response always at the same layer.
> >
> > I do not know if I have been clear, I think my idea could be
> > better explained
> > with some pictures but I am overwhelmed with work at the moment...
> >
> >
> > Best Regards,
> >
> > Paolo
> >
> >
> > --
> > Paolo Romano
> >
> >
> >
> > You may leave a Technical Committee at any time by visiting
> http://www.oasis-open.org/apps/org/workgroup/wsrm/members/leave_workgroup.ph
> p
>




--
Paolo Romano