[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