ws-rx message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [ws-rx] Minimalist GetMessage proposal
- From: Doug Davis <dug@us.ibm.com>
- To: ws-rx@lists.oasis-open.org
- Date: Thu, 4 May 2006 18:38:46 -0400
Paul,
We talked a bit about this on
today's call but....
- reliable out use case: reliable notifications
- unreliable in, reliable out: in the
management space we have lots of devices that are outside the firewall
that need to send back data from time to time - the manager inside the
firewall send a ping type of message every now and then and the response
needs to be sent reliably.
- Using your proposal, RMS is a gateway
machine servicing lots of endpoints - if two of those machines need to
send RM enabled messages to the same anon client and (based on the last
f2f they need different RM sequences because one uses soap 1.1 and one
uses soap 1.2) how does the polling agent know when to Offer?
- As someone on today's call asked,
what about WSA in your proposal? What if the GetMessage has a wsa:ReplyTo
- what's in the response? Where does it go? What about the ref-p's?
As for EPRid being unspecified - look
at the latest proposal, EPRid isn't even in there.
-Doug
Paul Fremantle <paul@wso2.com>
05/04/2006 07:02 AM
|
To
| Christopher B Ferris/Waltham/IBM@IBMUS
|
cc
| wsrx <ws-rx@lists.oasis-open.org>
|
Subject
| Re: [ws-rx] Minimalist GetMessage
proposal |
|
Chris
> We've been over this many times. Any RMS should be free to make its
> own determination as to when
> IT requests creation of a Sequence. The RMS at the server side of
an
> RMD that can only be accessed via
> the anonymous endpoint is/should be no exception.
Firstly, the RM spec doesn't state this anywhere. In the submitted spec
there is no way for a server to request creation of a sequence with an
anonymous client. If you are going to justify this you need to back it
up with a use case, scenario, charter words, usage of the submitted spec
or spec lines. To state it as ig it were a given when it plainly isn't
even acheivable today in this scenario is not convincing.
Nothing in my proposal forbids an RMS using any mechanism it can to
create a sequence with an RMD. However, unless the RMD is in some way
contactable then it is simply logic that states it cannot be contacted.
My proposal is that the way a client makes a server aware of itself is
through an Offer. Unless the server has some "knowledge of" a
client
(such as an address, a sequence id, or in your case an EPRId) it cannot
create a sequence, no matter what. You have chosen to create a new
identifier (EPRId) and therefore a context which needs to be managed and
so extend the RM spec in a whole new direction. As I posted in response
to Doug's note, I think the EPRId is poorly specified, with no
lifecycle, no defined faults, and plainly adding a whole new set of
state that has to be managed by an RM agent.
It would be valuable for you to enumerate usecases and real scenarios
which are motivating the statements you are making, because so far the
motivation has been theoretical (freedom for RMSs) rather than practical
(I need to create a sequence because....). I still haven't seen a
thoroughly plausible scenario for unreliable-in/reliable-out which is
one of the reasons I took out the optimisation (section 4.2) from my
earlier proposal.
Paul
Christopher B Ferris wrote:
>
> Cheers,
>
> Christopher Ferris
> STSM, Software Group Standards Strategy
> email: chrisfer@us.ibm.com
> blog: http://www.ibm.com/developerworks/blogs/dw_blog.jspa?blog=440
> phone: +1 508 377 9295
>
> "Marc Goodner" <mgoodner@microsoft.com> wrote on 05/03/2006
11:51:51 PM:
>
> > I agree this proposal is a lot tighter in scope.
> >
> > I'm not to convinced of the need to poll for a CS so that doesn't
> > trouble me very much. Your suggestion for the addition of Offer
is an
> > interesting idea. I'm not sure how much it really optimizes things
when
> > the client instead of polling for an inbound CS could simply
start with
> > an outbound CS with an Offer for an inbound sequence. The outbound
> > sequence would be independent of the inbound one so it could
be
> > terminated before the inbound one if it was not needed.
> >
> > Marc Goodner
> > Technical Diplomat
> > Microsoft Corporation
> > Tel: (425) 703-1903
> > Blog: http://spaces.msn.com/mrgoodner/
> >
> >
> > -----Original Message-----
> > From: Durand, Jacques R. [mailto:JDurand@us.fujitsu.com]
> > Sent: Wednesday, May 03, 2006 7:24 PM
> > To: Paul Fremantle; wsrx
> > Subject: RE: [ws-rx] Minimalist GetMessage proposal
> >
> > I must say the proposal is much improved and scoped.
> > It of course works only with offered sequences - I am still trying
to
> > convince myself that not being able to poll for CS is not a (serious)
> > issue.
> > A wild idea: the unreliable-in/reliable-out case could be handled
better
> > by allowing an wsrm:Offer on the GetMessage...
> >
> > Jacques
> >
> > -----Original Message-----
> > From: Paul Fremantle [mailto:paul@wso2.com]
> > Sent: Wednesday, May 03, 2006 12:05 PM
> > To: wsrx
> > Subject: [ws-rx] Minimalist GetMessage proposal
> >
> > Based on some of the discussions it seemed to me that it could
be
> > valuable to produce a completely "minimalist" GetMessage
proposal.
> >
> > This is a new proposal that is based on the previous WSO2 proposal.
> >
> > The proposal removes the MessageID selector in the GetMessage
- relying
> > on simply getting whatever message the server sends back next.
> >
> > Also it removes the section 4.2. Effectively section 4.2 is an
> > optimisation: for example to support unreliable-in/reliable-out
a client
> >
> > could do a createsequence+offer and never use the outgoing sequence.
In
> > this case there is an overhead, which 4.2 aimed to remove, but
this
> > simplifies the proposal by focussing on the bare minimum required
to
> > support the most common use cases, but still allowing the other
use case
> >
> > with a slight overhead.
> >
> > I've also included a sample message flow which I hope helps understand
> > the proposal and show the general usage.
> >
> > Paul
> >
> > --
> >
> > Paul Fremantle
> > VP/Technology, WSO2 and OASIS WS-RX TC Co-chair
> >
> > http://feeds.feedburner.com/bloglines/pzf
> > paul@wso2.com
> >
> > "Oxygenating the Web Service Platform", www.wso2.com
> >
--
Paul Fremantle
VP/Technology, WSO2 and OASIS WS-RX TC Co-chair
http://feeds.feedburner.com/bloglines/pzf
paul@wso2.com
"Oxygenating the Web Service Platform", www.wso2.com
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]