[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [wsia] [wsrp-wsia joint interfaces] Re: April 9 (Embedded) confcall.
Good points ... The 7.1 Lifecycle discussion was about whether a Consumer should have to deal differently with Producers who choose to operate in a stateless manner (ie. vs the default of being stateful). The consensus was that Consumers would have to operate differently (eg. send all properties on each invocation) and therefore needed a straightforward means of determining if the Producer was stateless (returning a null handle from the "create" lifecycle operation was mentioned as an example). I don't think there has been a request that a Consumer be able to choose the statefulness of the interaction with the Producer. My point was that the Embedded Use Case is not anticipating (or discussing) events (though these become critical in scenarios involving multiple Consumers interacting with a single instance of a Producer - this is beyond simple embedding). The reason a Producer must return the set of modified properties (not the entire set of properties) is that the Producer is allowed to reject attempts to change values (reasons include invalid type, unknown property, and access control issues) and the changing of a property is allowed to have impact that include changing the value of other properties. This also anticipates the requirement stated in the WSRP F2F to avoid roundtrips whenever possible and therefore the discussion has all revolved around sending a request to update the values of a set of properties rather than a request per property. I guess we should capture this in the requirements document .... Graeme Riddell <griddell@bowstre To: "wsia (E-mail)" <wsia@lists.oasis-open.org> et.com> cc: Subject: [wsia] [wsrp-wsia joint interfaces] Re: April 9 04/09/2002 01:19 (Embedded) conf call. PM Alan, Rich, thanks for the productive conf call and the work done so far on Embedded. Couple of thoughts on today's conversation... 7.1 Lifeycle. We discussed the consumer choosing whether he wanted to engage in a stateful/stateless lifecycle. Not sure the consumer has a choice does he? If the producer defines stateful operations (ie, they take as an arg a session handle) then the consumer is going to have to comply in order to make that call. Or the producer might define additional stateless operations where a bunch more data needs to be supplied on every request? The former (stateful, with a session handle) would be more efficient (less data travelling on the wire), and the latter might allow simpler implementations on the consumer side? So if a producer chose to supply both porttypes (meaning published interface containing certain operations) then that's his prerogative and very nice of him to do so, but if he only published a stateful interface the consumer would just have to work with that? 7.6.4 Rich pointed out that it's not event-based, not notifying multiple subscribed consumers - might be worth clarifying that. In which case I'm then not sure why a producer must notify its consumer what properties have changed, since won't it have been the consumer that initiated the change? So (considering performance here too) do we just want to say that a producer MUST notify its consumer that a property change was/was not successful (rather than returning a full list of the new current property settings)? Also do we want to state that producers MAY support the ability to change multiple properties at once? thanks, :-) gr 603.559.1556 ---------------------------------------------------------------- To subscribe or unsubscribe from this elist use the subscription manager: <http://lists.oasis-open.org/ob/adm.pl>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC