Our system works with ASB transport with forwarding topology. With this configuration, we don’t need to register the event publishers in order to handle events and our architecture relies on this fact (the event consumers don’t now who the publishers are).
I’m considering using SQL Transport for development purposes (easlier to clean up and recreate subscriptions), but I believe that SQL Transport needs the publishers registration.
Is there any way to resolve this and use SQT Transport without registering the event publishers?
SQL Transport does not support native pub/sub like some of the other transports. Therefore to make pub/sub work, we have to register the publisher. I don’t believe there are other ways around this.
As always switching transports are tricky. Here’s some guidance on selecting a transport:
Also, a really awesome talk from Andreas that provides various informations, pros and cons about transports is here:
Hope this helps,
Cheers,
Indu Alagarsamy
Particular Software
Have you considered using the LearningTransport? For development purposes this seems to be an OK solution and given that it is a transport that supports native pubsub you don’t have to register the event publisher.
Yes, we did consider it and it’s still on the table. It doesn’t work out of the box though because it’s not automatically registering abstract events (base classes and interfaces) if I remember correctly. But a colleague managed to workaround it by somehow automatically creating the right folders.
In any case, we haven’t progressed more than that in this area, although we are still hoping to look into it. It was related to finding a better way of testing our SOA services independently, allowing developers to run the service locally and debug scenarios that depended on external events being fired. BTW, we considered using a project of yours, but I never got to try it because I found this issue: Issues · danielmarbach/ServiceFabric.Testing · GitHub Have you worked more in this project?
That might be difficult without sharing personal identifiable information, but you would get more than one if you visited us in our office in Amsterdam.
