Is it assumed that all these events
express backward-compatible changes on the Producer side? I mean if the
Consumer ignores these “proactive notifications” and keeps invoking
the Portlets in the same way, they keep working?
If an event expresses a non-backward-compatible
change on some Portlet and the Consumer ignores this event, then on the next invocation
of this Portlet an exception will be thrown. This exception could be for
example OperationFailed, and it will not be easy to the Consumer to understand
the reason of the fault and to recover.
Do you think that the
backward-compatibility semantics should be defined for each spec defined event,
and the Consumer should be responsible to treat the “severe” events
before the next invocations?
Since the Producer may notify the Consumer
only on pbia or handleEvent invocation, there always can be a situation when:
1. Portlet
P1 is changed and the producer is waiting for the next invocation to inform the
Consumer
2. The
Consumer invokes P1 and gets an exception
So if the backward-compatibility is really
relevant here, we have to admit that sometimes exceptions should be used for
passing information to the Consumer.
Regards,
Artem
From: Rich Thompson
[mailto:richt2@us.ibm.com]
Sent: Thursday, March 10, 2005
7:53 PM
To: wsrp@lists.oasis-open.org
Subject: Re: [wsrp] Spec defined
events
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