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: Mon, 14 Mar 2005 08:17:34 -0500
While proper SLA and version management
are critical and this is a noble sentiment for achieving that end, I think
it is impractical. In essence it reduces the notification that something
has changed that must be dealt with to the point at which the Consumer
attempts to extend a lease. Since this is likely to be an automated process
that happens a relatively short time before the lease expires, it provides
little in the way of useful notification to the Consumer. Far better to
inform the Consumer as soon as possible.
Also, I fail to see why such events
would be more complex than deciphering a Producer's refusal to extend a
lease.
Rich
"Andre Kramer"
<andre.kramer@eu.citrix.com>
03/14/05 04:25 AM
|
To
| "Spector, Artem"
<artem.spector@sap.com>, <wsrp@lists.oasis-open.org>
|
cc
|
|
Subject
| RE: [wsrp] Spec defined events |
|
I agree. Proper SLAs and service
versioning are extremely desirable, even leaving aside the issue of when/how
consumers are to react to unilateral modifications.
Regards,
Andre
From: Spector, Artem [mailto:artem.spector@sap.com]
Sent: 13 March 2005 11:59
To: Spector, Artem; wsrp@lists.oasis-open.org
Subject: RE: [wsrp] Spec defined events
Wouldn’t it be a simpler solution
to disallow the Producer changing the metadata on a leased instance?
This could simplify the protocol
because the changed metadata could be refreshed by the Consumer on each
new lease.
In this case we could even
tot to define the “metadata changed” – style events at all…
Artem
From: Spector, Artem [mailto:artem.spector@sap.com]
Sent: Sunday, March 13, 2005 10:24 AM
To: wsrp@lists.oasis-open.org
Subject: RE: [wsrp] Spec defined events
Yes, but the question is:
Can the Producer throw a “related
fault” before sending the proactive notification to the Consumer?
If the answer is no, the Producer
will have to maintain the previous version of a Portlet until the next
call.
If the answer is yes, the Consumer
must be ready to get a fault before (or instead of?) the notification.
Regards,
Artem
From: Rich Thompson [mailto:richt2@us.ibm.com]
Sent: Thursday, March 10, 2005 9:49 PM
To: wsrp@lists.oasis-open.org
Subject: RE: [wsrp] Spec defined events
I think the spec would need to have a paragraph describing the difference
between these proactive notifications and related faults. It may also be
worth having the notifications carry a flag indicating whether or not the
next use of the relevant resource is likely to result in a fault if the
notification is ignored.
Rich
"Spector, Artem" <artem.spector@sap.com>
03/10/05 01:48 PM
|
To
| <wsrp@lists.oasis-open.org>
|
cc
|
|
Subject
| RE: [wsrp] Spec defined events |
|
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
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]