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

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsrp message

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


Subject: Re: [wsrp] Spec defined events


My point is that the Producer does not always know what "each consumer" 
means.

Subbu

Rich Thompson wrote:
> 
> Interesting questions. Other than the last one, they all seem predicated 
> on an implementation style that tracks changes and does a computation 
> upon interaction to determine whether or not to generate one of these 
> events. Another implementation choice (that happens to avoid the bulk of 
> these issues) is to persistently store the need to provide one of these 
> notifications to each known Consumer and then delete the record saying 
> the need exists when it is delivered. In addition to removing datetime 
> computation while processing a request, this also permits notification 
> by means other than event delivery. An example of this would be to 
> consider a getServiceDescription invocation as removing any 
> Producer/Portlet metadata change notifications as the response will 
> already update the Consumer.
> 
> The other point about these event definitions is that their purpose 
> would not be to require any particular functionality, but rather to 
> provide a standardized means by which a Producer could proactively 
> inform a Consumer about changes. Whether or not a particular Producer or 
> Consumer implementation makes use of this means to reduce polling for 
> metadata would still be entirely implementation dependent.
> 
> On the last question, I do not think it is up to the spec to define what 
> a change is that should trigger any of these notifications. Rather they 
> are defined as a means for carrying a notification that a particular 
> form of metadata has changed. As a result of this, I would resist 
> optimizations such as having the ProducerMetadataChanged event payload 
> carry the new ServiceDescription. Instead, the event is just a 
> notification and it is up to the Consumer to decide when and how to 
> respond to the information.
> 
> Rich
> 
> 
> *Subbu Allamaraju <subbu@bea.com>*
> 
> 03/10/05 10:57 AM
> 
> 	
> To
> 	wsrp@lists.oasis-open.org
> cc
> 	
> Subject
> 	Re: [wsrp] Spec defined events
> 
> 
> 	
> 
> 
> 
> 
> 
>  > As to other options to carry such notifications by other means, why
>  > would we add such dependencies when we already have a channel that could
>  > easily carry the information. I agree that the Consumer is not likely to
>  > display the fact that it received such an event to normal end-users, but
>  > it certainly would be valuable info to display to system admins (or
>  > queue for display to them).
> 
> Thanks Rich. You make some good arguments. So, let me counter with few
> more questions.
> 
> o Producers don't necessarily know whether the Consumer's version of the
> Producer's metadata is current or not, unless it starts to keep track of
> all metadata requests.
> 
> o The Producer has to keep track of metadata changes persistently and
> make sure to cleanup those changes periodically.
> 
> o The only time a Producer could return events is via handldEvent(s) and
> pbia responses (excluding fault conditions). This may be acceptable.
> 
> o Assuming that the Producer recognized a change, how would it know
> whether a given Consumer should be notified or not? Should it start
> sending notifications to all Consumers (including those that already
> have the current metadata)? Such Consumers will have to do some extra
> processing before ignoring the event.
> 
> o Should the Producer keep sending events for ever or just once? It
> can't be the latter since the Producer does not always know about
> Consumers. So, it does not know which Consumer was already notified.
> 
> I think, a more fundamental question how would the spec define what a
> "change" is.
> 
> Regards,
> 
> Subbu
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: wsrp-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: wsrp-help@lists.oasis-open.org
> 
> 




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