Our Service Fabric services can use one or more communication listener from:
WebApi listener
Remoting listener
Message Bus listener
The Message Bus listener is based on this NSB documentation and it works correctly.
The problem is when the same service uses another listener, like remoting or a WebApi and it also needs the NSB endpoint. The services injected in controllers or used in the remoting listener expect a IUniformSession, but the IUniformSession is initialized and registered during the start up of the Bus Communication listener.
How can we correctly set up an NSB endpoint to be used in multiple listeners? or should we create an endpoint on each listener?
What is the reason you went for UniformSession? UniformSession should only be used in the legacy transition from IBus to IMessageSession (or at least that was the intention).
If I understood you correctly your service definition creates two communication listener. One that starts WebAPI and one that starts NServiceBus? Is the one that starts NServiceBus creating send-only endpoints only or are these endpoints also receivers?
We send/publish messages mainly from the following 2 scenarios:
Send commands from apis to backend services
Raise events from AggregateRoots and publish them from the Commit in the Unit of Work (inspired by @jbogard
In scenario 1 we could use the IMessageSession, but in scenario 2, we can’t as the unit of work is called both from message handlers and remoting service methods.
I read about the origin of IUniformSession, but it was my understanding that the use in our scenario was known and proposed way of doing it.
In any case, I think that the use of IUniformSession or specific handler context and IMessageSession don’t make a difference in our scenario.
As you say, some of our services create two (some times more) communication listeners. It is possible that we use send only endpoints (in Api or remoting listeners), but most cases are also receive endpoints. I also think this wouldn’t make a difference in our current set up. Because, regardless of their configuration, our problem is when we need the same endpoint in multiple listeners. In our current set up, only one of the listeners starts the endpoint and the others just inject the interface and obviously, the second ones can only start after the first one has started.
What I did before was declaring local instances of the listeners with variables in the lambda and then expose accessor methods to other listeners that are guaranteed to return something by making sure based on the lifecycle of the listener things are available when needed.
Another option could be to Lazy bind things and then assign those lazy values once the values are available. You’d still have to make sure that you don’t accept web requests before the NSB endpoint is available which you can do by placing the listeners in the right order into the ServiceInstanceListener collection