OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ws-rx message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [ws-rx] Minimalist GetMessage proposal



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]