Notification/JMS Interworking Service Avatar
  1. OMG Specification

Notification/JMS Interworking Service — All Issues

  • Acronym: NOTJMS
  • Issues Count: 5
  • Description: All Issues
Open Closed All
All Issues

Issues Descriptions

Third-party client not able to create bridge due missing channel information (CosNotifyChannelAdmin::ChannelID)

  • Key: NOTJMS-5
  • Status: open  
  • Source: FastDS ( Ulrich Berl)
  • Summary:

    Imagine the following use case:

    Server creates an EventChannel.
    This channel is registered in NameService using path <path/to/channel>.
    Client A resolves channel path <path/to/channel> using NameService and listens for events.

    Now third-party Client B wants to create a Channel->Jms bridge.
    Client B is able to resolve the channel path <path/to/channel> using NameService.
    BUT Client B cannot create a bridge as the ChannelID (for defining the ExternalEndpointConnector) is not available...

    Maybe as a workaround Client B can do a list() on the NameService, resolve each eventchannel-entry and compare the objects with them from EventChannelFactory (get_all_channels/get_event_channel) - but this seems to be expensive.

    So only the creator of an event channel has the information to create a bridge (ChannelID) - is this the desired behavior ?

    Actually for my implementation I adapted the ExternalEndpointConnector as follow (as I have to know the path in the jms message too):

    struct Channel

    { CosNotifyChannelAdmin::ChannelID channel_id; string channel_path; }

    ;

    union ExternalEndpointConnector switch (MessageType)

    { case JMS_MESSAGE: JMSDestination destination; //default: CosNotifyChannelAdmin::ChannelID channel_id; default: Channel channel; }

    ;

  • Reported: NOTJMS 1.0 — Tue, 6 Mar 2018 13:05 GMT
  • Updated: Fri, 6 Apr 2018 19:27 GMT

Remove read-only attributes from EndpointSender and EndpointReceiver

  • Key: NOTJMS-4
  • Legacy Issue Number: 6342
  • Status: closed  
  • Source: ZettaScale Technology ( Dr. Ramzi Karoui)
  • Summary:

    Removing the read-only attributes from EndpointSender and EndpointReceiver from the Bridge Interface and replacing them by two external ExternalEndpoints.

    The Bridge interface change from:
    interface Bridge

    { readonly attribute EndpointReceiver end_point_receiver; readonly attribute EndpointSender end_point_sender; void start () raises (BridgeAlreadyStarted); void stop () raises (BridgeInactive); status get_status(); void destroy (); }

    to:
    interface Bridge

    { readonly attribute ExternalEndpoint end_point_receiver; readonly attribute ExternalEndpoint end_point_sender; void start_bridge () raises (BridgeAlreadyStarted,InvalidExternalEndPoints); void stop_bridge () raises (BridgeInactive); status get_status(); void destroy (); }

    The EndpointReceiver and EndpointSender types should be removed from the IDL also.

    The rational behind this change is that the EndpointReceiver and EndpointSender object interfaces were exposing internal implementation parts that no third party needs to have access to. Removing those interfaces from the public IDL of the bridge improves the bridge security.

    Note that for the purposes of connection the bridge implementation has to manage internally these objects and publish their interfaces to the appropriate Notification Service or JMS.

  • Reported: NOTJMS 1.0b1 — Mon, 20 Oct 2003 04:00 GMT
  • Disposition: Resolved — NOTJMS 1.0
  • Disposition Summary:

    Accept proposed resolution

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

Adding InvalidExternalEndpoint Exception to new Bridge::start_bridge() ope

  • Key: NOTJMS-3
  • Legacy Issue Number: 6341
  • Status: closed  
  • Source: ZettaScale Technology ( Dr. Ramzi Karoui)
  • Summary:

    Adding InvalidExternalEndpoint Exception to new Bridge::start_bridge() operation.
    · The Bridge::start_bridge operation is now raises two exceptions: BridgeAdlreadyStarted and InvalidExternalEndpoint.
    The rational behind this extension is that during Bridge::start_bridge operation, consumer and publisher are created. If any ExternalEndpoint information (be it source or sink) is invalid, client cannot be created, thus InvalidExternalEndpoint will be raised

  • Reported: NOTJMS 1.0b1 — Mon, 20 Oct 2003 04:00 GMT
  • Disposition: Resolved — NOTJMS 1.0
  • Disposition Summary:

    see above

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

Rename two operations in the Bridge interface

  • Key: NOTJMS-2
  • Legacy Issue Number: 6340
  • Status: closed  
  • Source: ZettaScale Technology ( Dr. Ramzi Karoui)
  • Summary:

    Rename two operations in the Bridge interface name have been made:
    · Original Name; Bridge::start(); New Name: Bridge::start_bridge()
    · Original Name; Bridge::stop(); New Name: Bridge::stop_bridge()
    The Start and stop names are common operation names. Those names may clash with other implementation components.

  • Reported: NOTJMS 1.0b1 — Mon, 20 Oct 2003 04:00 GMT
  • Disposition: Resolved — NOTJMS 1.0
  • Disposition Summary:

    Accept proposed changes

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

Remove the CosEventDomainAdmin::NotificationStyle

  • Key: NOTJMS-1
  • Legacy Issue Number: 6339
  • Status: closed  
  • Source: ZettaScale Technology ( Dr. Ramzi Karoui)
  • Summary:

    Removing the CosEventDomainAdmin::NotificationStyle by CosBridgeAdmin::FlowStyle, defined hereafter :
    enum FlowStyle

    { PUSH, PULL }

    . The rational for that is to avoid having dependencies with the CosEventDomainAdmin module defined in the Event domain manager specification. In fact, few notification service providers provide today this CoS.

  • Reported: NOTJMS 1.0b1 — Mon, 20 Oct 2003 04:00 GMT
  • Disposition: Resolved — NOTJMS 1.0
  • Disposition Summary:

    No Data Available

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