[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [no subject]
Rich Subbu Allamaraju <subbu@bea.com> 03/14/05 11:20 AM To wsrp@lists.oasis-open.org cc 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 > > --------------------------------------------------------------------- To unsubscribe, e-mail: wsrp-unsubscribe@lists.oasis-open.org For additional commands, e-mail: wsrp-help@lists.oasis-open.org --=_alternative 005B0F9785256FC4_= Content-Type: text/html; charset="US-ASCII" <br><font size=2 face="sans-serif">From a protocol point of view, the known Consumers are those that have registered. Non-registered Consumers are effectively sharing a guest account and should not expect the Producer to track them for such notifications. Producers can also have other means of tracking their Consumers, but an implementation style that simply sends such events because it is not known if the current Consumer has been informed should be discouraged.</font> <br><font size=2 face="sans-serif"><br> Rich </font> <br> <br> <br> <table width=100%> <tr valign=top> <td width=40%><font size=1 face="sans-serif"><b>Subbu Allamaraju <subbu@bea.com></b> </font> <p><font size=1 face="sans-serif">03/14/05 11:20 AM</font> <td width=59%> <table width=100%> <tr> <td> <div align=right><font size=1 face="sans-serif">To</font></div> <td valign=top><font size=1 face="sans-serif">wsrp@lists.oasis-open.org</font> <tr> <td> <div align=right><font size=1 face="sans-serif">cc</font></div> <td valign=top> <tr> <td> <div align=right><font size=1 face="sans-serif">Subject</font></div> <td valign=top><font size=1 face="sans-serif">Re: [wsrp] Spec defined events</font></table> <br> <table> <tr valign=top> <td> <td></table> <br></table> <br> <br> <br><font size=2><tt>My point is that the Producer does not always know what "each consumer" <br> means.<br> <br> Subbu<br> <br> Rich Thompson wrote:<br> > <br> > Interesting questions. Other than the last one, they all seem predicated <br> > on an implementation style that tracks changes and does a computation <br> > upon interaction to determine whether or not to generate one of these <br> > events. Another implementation choice (that happens to avoid the bulk of <br> > these issues) is to persistently store the need to provide one of these <br> > notifications to each known Consumer and then delete the record saying <br> > the need exists when it is delivered. In addition to removing datetime <br> > computation while processing a request, this also permits notification <br> > by means other than event delivery. An example of this would be to <br> > consider a getServiceDescription invocation as removing any <br> > Producer/Portlet metadata change notifications as the response will <br> > already update the Consumer.<br> > <br> > The other point about these event definitions is that their purpose <br> > would not be to require any particular functionality, but rather to <br> > provide a standardized means by which a Producer could proactively <br> > inform a Consumer about changes. Whether or not a particular Producer or <br> > Consumer implementation makes use of this means to reduce polling for <br> > metadata would still be entirely implementation dependent.<br> > <br> > On the last question, I do not think it is up to the spec to define what <br> > a change is that should trigger any of these notifications. Rather they <br> > are defined as a means for carrying a notification that a particular <br> > form of metadata has changed. As a result of this, I would resist <br> > optimizations such as having the ProducerMetadataChanged event payload <br> > carry the new ServiceDescription. Instead, the event is just a <br> > notification and it is up to the Consumer to decide when and how to <br> > respond to the information.<br> > <br> > Rich<br> > <br> > <br> > *Subbu Allamaraju <subbu@bea.com>*<br> > <br> > 03/10/05 10:57 AM<br> > <br> > <br> > To<br> > wsrp@lists.oasis-open.org<br> > cc<br> > <br> > Subject<br> > Re: [wsrp] Spec defined events<br> > <br> > <br> > <br> > <br> > <br> > <br> > <br> > <br> > > As to other options to carry such notifications by other means, why<br> > > would we add such dependencies when we already have a channel that could<br> > > easily carry the information. I agree that the Consumer is not likely to<br> > > display the fact that it received such an event to normal end-users, but<br> > > it certainly would be valuable info to display to system admins (or<br> > > queue for display to them).<br> > <br> > Thanks Rich. You make some good arguments. So, let me counter with few<br> > more questions.<br> > <br> > o Producers don't necessarily know whether the Consumer's version of the<br> > Producer's metadata is current or not, unless it starts to keep track of<br> > all metadata requests.<br> > <br> > o The Producer has to keep track of metadata changes persistently and<br> > make sure to cleanup those changes periodically.<br> > <br> > o The only time a Producer could return events is via handldEvent(s) and<br> > pbia responses (excluding fault conditions). This may be acceptable.<br> > <br> > o Assuming that the Producer recognized a change, how would it know<br> > whether a given Consumer should be notified or not? Should it start<br> > sending notifications to all Consumers (including those that already<br> > have the current metadata)? Such Consumers will have to do some extra<br> > processing before ignoring the event.<br> > <br> > o Should the Producer keep sending events for ever or just once? It<br> > can't be the latter since the Producer does not always know about<br> > Consumers. So, it does not know which Consumer was already notified.<br> > <br> > I think, a more fundamental question how would the spec define what a<br> > "change" is.<br> > <br> > Regards,<br> > <br> > Subbu<br> > <br> > <br> > ---------------------------------------------------------------------<br> > To unsubscribe, e-mail: wsrp-unsubscribe@lists.oasis-open.org<br> > For additional commands, e-mail: wsrp-help@lists.oasis-open.org<br> > <br> > <br> <br> <br> <br> ---------------------------------------------------------------------<br> To unsubscribe, e-mail: wsrp-unsubscribe@lists.oasis-open.org<br> For additional commands, e-mail: wsrp-help@lists.oasis-open.org<br> <br> </tt></font> <br> --=_alternative 005B0F9785256FC4_=--
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]