${taskforce.name} Avatar
  1. OMG Task Force

Notification Service 1.3 RTF — All Issues

  • Key: NOT13
  • Issues Count: 12
Open Closed All
All Issues

Issues Descriptions

Typed event service and disconnect

  • Key: NOT13-12
  • Legacy Issue Number: 3156
  • Status: closed  
  • Source: Triodia Technologies Pty Ltd ( Michi Henning)
  • 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?

  • Reported: NOT 1.2 — Tue, 21 Dec 1999 05:00 GMT
  • Disposition: Resolved — NOT 1.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Semantics of Event Service disconnect_push_consumer/supplier()

  • Key: NOT13-11
  • Legacy Issue Number: 3114
  • Status: closed  
  • Source: Motorola ( Tom Ziomek)
  • 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).

  • Reported: NOT 1.2 — Fri, 19 Nov 1999 05:00 GMT
  • Disposition: Resolved — NOT 1.3
  • Disposition Summary:

    No Data Available

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Notification Service IDL issues

  • Key: NOT13-10
  • Legacy Issue Number: 6343
  • Status: open  
  • Source: Anonymous
  • Summary:

    just came across Notification Service IDL where
    you are mentioned as contact person:

    When I "grep" on all IDL files I notice that
    orb.idl is not included.

    I notice further that file

    CosNotifyFilter.idl

    in line 105 makes use of TypeCode:

    readonly attribute CORBA::TypeCode value_type;

    However section 3.19 "CORBA Module" of current
    CORBA standard 3.0.2 reads as:

    >> Names defined by the CORBA specification are in a module named CORBA. In an
    >> OMG IDL specification, however, OMG IDL keywords such as Object must not be
    >> preceded by a "CORBA::" prefix. Other interface names such as TypeCode are not
    >> OMG IDL keywords, so they must be referred to by their fully scoped names (e.g.,
    >> CORBA::TypeCode) within an OMG IDL specification.
    >> For example in:
    >> #include <orb.idl>
    >> module M

    { >> typedef CORBA::Object myObjRef; // Error: keyword Object scoped >> typedef TypeCode myTypeCode; // Error: TypeCode undefined >> typedef CORBA::TypeCode TypeCode;// OK >> }

    ;
    >> The file orb.idl contains the IDL definitions for the CORBA module. Except for
    >> CORBA::TypeCode, the file orb.idl must be included in IDL files that use names
    >> defined in the CORBA module. IDL files that use CORBA::TypeCode may obtain its
    >> definition by including either the file orb.idl or the file TypeCode.idl.

    In my humble opinion, "your" Notification IDL is
    not correct.

    Perhaps you have some time left to comment on
    this?

  • Reported: NOT 1.3 — Mon, 13 Oct 2003 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

The Supplier Proxy & Consumer Proxy interfaces don't get ID's

  • Key: NOT13-9
  • Legacy Issue Number: 3521
  • Status: open  
  • Source: Anonymous
  • Summary:

    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. The Supplier Proxy & Consumer Proxy interfaces also do not have the ability to get
    the ID's.

  • Reported: NOT 1.2 — Thu, 30 Mar 2000 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Premature in eliminating Txn interfaces?

  • Key: NOT13-3
  • Legacy Issue Number: 2501
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: I feel there is a flaw in the model described in the current Notification
    Service spec for supporting Transactional Notification.

  • Reported: NOT 1.1 — Wed, 3 Mar 1999 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

EventTypeRepository class issue

  • Key: NOT13-2
  • Legacy Issue Number: 2460
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: In Appendix A it is stated that "the EventTypeRepository class only has
    one instance in any given implementation of the Repository". At the same
    time, there is a package interface and a package factory that implies
    that it"s possible to create multiple repositories (unless the
    NotificationTypesPackage interface is expected to always returns the
    same objects, no matter how many packages one have created).

  • Reported: NOT 1.1 — Fri, 19 Feb 1999 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

CosNotifyChannelAdmin::ConsumerAdmin::obtain_notification_X_supplier oper

  • Key: NOT13-1
  • Legacy Issue Number: 2153
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary: The CosNotifyChannelAdmin::ConsumerAdmin::obtain_notification_X_supplier
    operation, when asked for a proxy for a ClientType of ANY_EVENT,
    returns a proxy that is unuasable by event service clients.

    The reason is that the CosNotifyChannelAdmin::ProxyXSupplier interface
    returned inherits only from CosEventChannelAdmin::XSupplier, and then
    redefines the connect operation that was available in CosEventChannelAdmin::
    ProxyXSupplier as connect_any_x_supplier. The interface can never be
    narrowed to CosEventChannelAdmin::ProxyXSupplier, and therfore is
    unusable by the Event Service style client.

  • Reported: NOT 1.1 — Fri, 30 Oct 1998 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

The interface on EventChanel does not have the ability to get the ChannelId

  • Key: NOT13-8
  • Legacy Issue Number: 3519
  • Status: open  
  • Source: Anonymous
  • 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.

  • Reported: NOT 1.2 — Thu, 30 Mar 2000 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Issue with pushing events

  • Key: NOT13-7
  • Legacy Issue Number: 3518
  • Status: open  
  • Source: Anonymous
  • Summary:

    2. Publishers are allowed to push events for the types they have not offered using offer_change().
    This can allow publishers to never advertise the event types they are offerring. For Example, as
    a consumer it can not tell what are the event types that will be offered on the channel.

    Can we require publishers to always call offer_change() on the new event types before pushing them to
    the event channel? If this behavior breaks existing functionality, then how about having push_xxx()
    check to see if the event type is offered, if not add it to the aggregate list?

  • Reported: NOT 1.2 — Thu, 30 Mar 2000 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Section 3.4.17. Page:136

  • Key: NOT13-6
  • Legacy Issue Number: 3517
  • Status: open  
  • Source: Anonymous
  • Summary:

    I see the following features lacking in CosNotification spec. What is the process on having this raised as
    an issue, and if all agree add it to the spec in the later revisions. Any info is appreciated.

    1. Section 3.4.17. Page:136. The EventChannel interface in CosNotification, does not allow to retrieve
    its ChannelId. This is unlike the interface on the admins which allow to get the adminids? It would be
    very handy to retrieve the channel id given event channel. I also do not see a way to retrieve
    proxyId's given a consumer proxy or supplier proxy.

  • Reported: NOT 1.2 — Thu, 30 Mar 2000 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

Notification service: admin MyChannel attribute

  • Key: NOT13-5
  • Legacy Issue Number: 3175
  • Status: open  
  • Source: Micro Focus ( Bjarne Rasmussen)
  • Summary:

    The notification service administration objects support an attribute
    called MyChannel that returns the event channel that first created the
    administration object. The value type of this attribute is EventChannel.
    For typed administration objects, the typed channel can not be returned
    because a TypedEventChannel is not compatible with an EventChannel. One
    solution is to change the value type of this attribute to a generic
    Object, which can be narrowed to the correct type.

  • Reported: NOT 1.2 — Tue, 4 Jan 2000 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT

suspend_connection/resume_connection messages - issue

  • Key: NOT13-4
  • Legacy Issue Number: 2512
  • Status: open  
  • Source: Anonymous
  • Summary:

    Summary:
    The suspend_connection/resume_connection messages do not describe what should happen to messages that are queued up. Are new messages rejected for the duration between the disconect and resume? Are messages that were queued up flushed? How does the Persistent Event Reliablity QoS effect the way both are handled? size=2> Along the same lines, what happens to events when a consumer disconnects? I assume events in this case would be lost.

  • Reported: NOT 1.1 — Thu, 4 Mar 1999 05:00 GMT
  • Updated: Fri, 6 Mar 2015 20:58 GMT