Issue 3427: Semantics of Event Service disconnect_push_consumer/supplier()                                                                                                                                          (event-rtf)
Source: Motorola (Mr. Tom Ziomek, CTZ001@email.mot.com)
Nature: Uncategorized Issue
Severity: 
Summary: The question concerns the disconnect_push_consumer() family of operations
(push and pull, consumer and supplier) on both the Event Svc side (proxy
suppliers and consumers) and application side (suppliers and consumers).

1) Is a proxy's disconnect_..._...() meant to be called by (any or all of)
   - the corresponding application supplier/consumer?
   - some other part of the application?
   - any portion of the Event Svc implementation?  If "yes" in this case,
     is the connected application object also supposed to be invoked, to
     notify it of the proxy's shutdown?

2) Is an application consumer/supplier's disconnect_..._...() meant to be
   called by
   - some other part of the application?  If "yes" in this case, is the
     application consumer/supplier then expected to invoke disconnect_()
     on the corresponding proxy object?
   - any portion of the Event Svc implementation?  If "yes", under what
     circumstances?

The specific issue at hand presumes the application object's disconnect_()
operation is to be invoked by the Event Svc.  The question is when -- one
opinion is that a call to the proxy's disconnect_() results in the invoca-
tion of disconnect_() on the proxy's application object.  The opposing o-
pinion is that the application object's disconnect_() is invoked only when
the application object is being disconnected by some means other than a
call to the proxy's disconnect_() (for example, if the event channel's
destroy() is called while application objects are still connected).

Resolution: 
Revised Text: When a channel is destroyed, all its proxies invoke the disconnect callback (if a callback was registered). In addition, calling a disconnect operation on a proxy causes the proxy to make the appropriate disconnect callback. Proxy implementations are responsible for avoiding infinite recursion. See http://cgi.omg.org/pub/notification-rtf/2_modules_draft1.pdf for a version of the original specification that includes the edits for this issue marked with change bars.
Actions taken:
February 27, 2001: closed issue
Discussion: 
see issue 3114 (Notification Service RTF) for resolution and discussion
End of Annotations:=====