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

;

union ExternalEndpointConnector switch (MessageType)

;

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

to:
interface Bridge

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.

Accept proposed resolution

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

see above

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.

Accept proposed changes

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

. 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.

No Data Available