wsrp message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [wsrp] Spec defined events
- From: Rich Thompson <richt2@us.ibm.com>
- To: wsrp@lists.oasis-open.org
- Date: Thu, 10 Mar 2005 12:52:32 -0500
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]