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:]
> Sent: 10 March 2005 14:08
> To:
> 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:
> For additional commands, e-mail:
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:
>
