-
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
NOTJMS — Third-party client not able to create bridge due missing channel information (CosNotifyChannelAdmin::ChannelID)
- Key: NOTJMS-5
- OMG Task Force: Notification/JMS Interworking FTF