Issues for Notification Service RTF mailing list

To comment on any of these issues, send email to notif-service-rtf@omg.org. (Please include the issue number in the Subject: header, thusly: [Issue ###].) To submit a new issue, send email to issues@omg.org.

List of issues (green=resolved, yellow=pending Board vote, red=unresolved)

List options: All ; Open Issues only; or Closed Issues only

Issue 3114: Semantics of Event Service disconnect_push_consumer/supplier()
Issue 3156: Typed event service and disconnect
Issue 3520: The interface on EventChanel does not have the ability to get the ChannelId

Issue 3114: Semantics of Event Service disconnect_push_consumer/supplier() (notif-service-rtf)

Click here for this issue's archive.
Source: Motorola (Mr. Tom Ziomek, CTZ001(at)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:
Actions taken:
November 19, 1999: received issue
February 27, 2001: closed issue

Discussion:

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.

Issue 3156: Typed event service and disconnect (notif-service-rtf)

Click here for this issue's archive.
Source: Triodia Technologies Pty Ltd (Mr. Michi Henning, michi(at)triodia.com)
Nature: Uncategorized Issue
Severity:
Summary:

For the untyped event service, a Disconnected exception is raised
if push() or pull() are called by the appropriate connect operation wasn't
called previously.

What should happen if I use a typed event service?

Resolution:
Revised Text: Append the following to the end of the final para on page 2-12: (Note that, if a consumer operation is declared oneway, there is no way for the caller to find out if the consumer is in the disconnected state because, for oneway calls, the servant cannot raise exceptions.) Append the following para at the end of section 2.5.1: If a TypedPushConsumer is in the disconnected state and a supplier attempts to deliver a typed event, the consumer shall raise a BAD_INV_ORDER exception. Append the following para at the end of section 2.5.2: If a TypedPullSupplier is in the disconnected state and a consumer attempts to retrieve a typed event, the supplier shall raise a BAD_INV_ORDER exception.
Actions taken:
December 21, 1999: received issue
February 27, 2001: closed issue

Discussion:

Typed consumers and suppliers cannot be forced to offer a Disconnected exception, so a system exception must be used.

Issue 3520: The interface on EventChanel does not have the ability to get the ChannelId (notif-service-rtf)

Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
Summary:

1. The interface on EventChanel does not have the ability to get the ChannelId?  This 
is quite contrary to the ability on the admin interfaces to retrieve the adminId's. 
Given a proxy to EventChannels's it will be very handy to retrieve the channelId's.

Resolution: duplicate, close issue
Revised Text:
Actions taken:
November 7, 2000: closed issue