It would be nice to be able to do a "subscription request", which would go out to all "subscription single endpoints", and then return to the caller - typically by means of a normal queue-based endpoint. This would in particular be nice for Mats instrumentation: "Get all MatsFactories", "Get all Endpoints" etc - but could probably also be of use for user code that wants to gather information/stats about "all active nodes" (e.g. getGuiSessionCount() springs to mind), and possibly also for other scenarios, e.g. cache updates - in that the sender could record who actually processed the update.
However, it is pretty simple to implement such a functionality using a standard matsFactory.subscriptionTerminator and initiator.publish(..), where a user-side "protocol" would either always reply (by using send(..)) to a static endpoint (typically terminator) - or stick the return endpoint id on the request DTO, or as a property.
This could also be made into a tool, where you'd make a "subscription single endpoint" that would be implemented using a subscriptionTerminator, but which handled a "return" in a proper way (by reading the property, and sending the reply to that). Note that this implies that also the request would have to go through the tool.
If this were to be put in the API, one would have to consider whether it was a special endpoint type (as suggested by the name "subscriptionSingle"), or instead a special stage type.
So - would this be beneficial enough to stick in Mats proper API, or is implementation in user code (possibly with tooling) good enough for this probably pretty seldom needed feature? There is definitely an API weight involved, which easily could lead to confusion. Indeed, the matsFactory.subscriptionTerminator and initiator.publish is already on the fringe of the Mats concept, and a bit confusing for a beginner trying to learn Mats.
I am leaning towards "not in the API", at least for the foreseeable future.
It would be nice to be able to do a "subscription request", which would go out to all "subscription single endpoints", and then return to the caller - typically by means of a normal queue-based endpoint. This would in particular be nice for Mats instrumentation: "Get all MatsFactories", "Get all Endpoints" etc - but could probably also be of use for user code that wants to gather information/stats about "all active nodes" (e.g. getGuiSessionCount() springs to mind), and possibly also for other scenarios, e.g. cache updates - in that the sender could record who actually processed the update.
However, it is pretty simple to implement such a functionality using a standard matsFactory.subscriptionTerminator and initiator.publish(..), where a user-side "protocol" would either always reply (by using send(..)) to a static endpoint (typically terminator) - or stick the return endpoint id on the request DTO, or as a property.
This could also be made into a tool, where you'd make a "subscription single endpoint" that would be implemented using a subscriptionTerminator, but which handled a "return" in a proper way (by reading the property, and sending the reply to that). Note that this implies that also the request would have to go through the tool.
If this were to be put in the API, one would have to consider whether it was a special endpoint type (as suggested by the name "subscriptionSingle"), or instead a special stage type.
So - would this be beneficial enough to stick in Mats proper API, or is implementation in user code (possibly with tooling) good enough for this probably pretty seldom needed feature? There is definitely an API weight involved, which easily could lead to confusion. Indeed, the matsFactory.subscriptionTerminator and initiator.publish is already on the fringe of the Mats concept, and a bit confusing for a beginner trying to learn Mats.
I am leaning towards "not in the API", at least for the foreseeable future.