Re: [wsrp] Spec defined events

[Rich Thompson <richt2@us.ibm.com>]

I think clear rationale for when a fault
vs an event is in order would need to be part of such definitions. My suggestion
for the rationale:

Faults indicate that processing has
failed for a particular reason. When a change (e.g. required registration
information) results in such a failure, the relevant fault MUST be returned.
When a change does not result in such a failure, the Producer MAY proactively
inform the Consumer that a change has happened using one of the defined
events. Such a notification would provide an opportunity to the Consumer
to inform relevant parties (e.g. administrators) that action on their part
might be appropriate.

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).

Rich

Subbu Allamaraju <subbu@bea.com>

03/10/05 09:35 AM

To	Andre Kramer <andre.kramer@eu.citrix.com>
cc	wsrp@lists.oasis-open.org
Subject	Re: [wsrp] Spec defined events

Probably, except for one difference. Registration
related faults get 
ruturned for a valid registration issue. In this case nothing else can
be done other than returning a fault. For these events, we're using a 
return path as a broadcast.

Regards,

Subbu

Andre Kramer wrote:
> Similar statements could be made about registration modifications
for
> which we are using a SOAP exception as a signal. Maybe some
> rationalization is in order?
> 
> Regards,
> Andre
> 
> -----Original Message-----
> From: Subbu Allamaraju [mailto:subbu@bea.com]
> Sent: 10 March 2005 14:08
> To: wsrp@lists.oasis-open.org
> Subject: Re: [wsrp] Spec defined events
> 
> I agree that this is one of questions raised by WSRP users, but there
> are few issues to be considered here.
> 
> a. Most of the times, consumer users cannot act upon these events
at
> production time. The only time these events make sense is during design
> time. At production time, such notifications just add more traffic.
> 
> b. We should also consider if such updates can be notified via a
> registry (e.g. via UDDI 3.0 notifications).
> 
> Regards,
> 
> Subbu
> 
> 
> Rich Thompson wrote:
>  >
>  > I was reminded this AM of a couple of possible events we
have
> discussed
>  > in the past:
>  >
>  > *ProducerMetadataChanged* - Notification that the Producer's
metadata
>  > has changed. The Consumer may want to refresh its cached
info.
>  > *PortletMetadataChanged* - Notification that the Portlet's
metadata
> has
>  > changed. The Consumer may want to refresh its cached info.
>  > *AvailablePortletsChanged* - Notification that the Producer
has
> changed
>  > the set of portlets exposed via WSRP. Event payload should
indicate
> the
>  > type of change (added, deprecated, deleted), the portletHandle
of the
>  > subject portlet and the portlet's title.
>  >
>  > Rich
> 
> 
> 
> ---------------------------------------------------------------------
> 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
> 



---------------------------------------------------------------------
To unsubscribe, e-mail: wsrp-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: wsrp-help@lists.oasis-open.org