Having different consumers consume different base implementation of the request interface

Christos Delivorias

unread,

May 17, 2015, 8:17:04 AM5/17/15

to masstrans...@googlegroups.com

Coming back to the example that Chris has published on the Request/Response communication.

I wanted to be able to have a common gateway, that creates a MessageRequestClient<IRequest, IResponse> but then have consumers that impement the IConsumer<ConcreteRequest> or IConsumer<ReenforcedConcreteRequest>, where ConcreteRequest and ReenforcedConcreteRequest implement the IRequest interface. This way from one common gateway I can send multiple base requests, and have consumers with different logic produce Responses.

I guess I could just have a gateway for each class of messages, but I'd like to avoid this kind of code bloat if I could.

Am I missing something here?

I believe MT can have consumers that subscribe to base classes; or is this jus tin the pub/sub model?

Any thoughts would be useful on this.

Thanks

C.

Chris Patterson

unread,

May 18, 2015, 12:55:59 PM5/18/15

to masstrans...@googlegroups.com

You can subscribe to interfaces, but the approach you are presenting really does not follow what MT and messaging in general is designed to handle. MT will already dispatch messages to consumers by type, so a base class or common interface really adds zero value.

This is particularly true in Command cases, where the command is a contract between the service and service's consumer. In this case, avoid sharing any implementation between different services as it confused ownership of contracts.

Also, I highly recommend interfaces for all message contracts, because it ensures no behavior makes its way into the message itself.

--
You received this message because you are subscribed to the Google Groups "masstransit-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to masstransit-dis...@googlegroups.com.
To post to this group, send email to masstrans...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/masstransit-discuss/a6e34915-8bde-4c5c-8bd2-0f1032038e1a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Christos Delivorias

unread,

May 19, 2015, 2:20:24 PM5/19/15

to masstrans...@googlegroups.com

Thanks for the clarification Chris.

So each message contract would need it's own MessageRequestClient? And for multiple message request you inevitably need multiple buses?

Is that right?

I just want to make sure I'm not duplicating MessageRequestClient constructors all over the place for no reason.

Thanks again.

On Monday, May 18, 2015 at 5:55:59 PM UTC+1, Chris Patterson wrote:

You can subscribe to interfaces, but the approach you are presenting really does not follow what MT and messaging in general is designed to handle. MT will already dispatch messages to consumers by type, so a base class or common interface really adds zero value.

This is particularly true in Command cases, where the command is a contract between the service and service's consumer. In this case, avoid sharing any implementation between different services as it confused ownership of contracts.

Also, I highly recommend interfaces for all message contracts, because it ensures no behavior makes its way into the message itself.

On Sun, May 17, 2015 at 5:17 AM, Christos Delivorias <c.deli...@gmail.com> wrote:

Coming back to the example that Chris has published on the Request/Response communication.
I wanted to be able to have a common gateway, that creates a MessageRequestClient<IRequest, IResponse> but then have consumers that impement the IConsumer<ConcreteRequest> or IConsumer<ReenforcedConcreteRequest>, where ConcreteRequest and ReenforcedConcreteRequest implement the IRequest interface. This way from one common gateway I can send multiple base requests, and have consumers with different logic produce Responses.
I guess I could just have a gateway for each class of messages, but I'd like to avoid this kind of code bloat if I could.

Am I missing something here?
I believe MT can have consumers that subscribe to base classes; or is this jus tin the pub/sub model?

Any thoughts would be useful on this.

Thanks
C.

--
You received this message because you are subscribed to the Google Groups "masstransit-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to masstransit-discuss+unsub...@googlegroups.com.

Chris Patterson

unread,

May 19, 2015, 5:49:29 PM5/19/15

to masstrans...@googlegroups.com

For each request/response pair, you would create a different MessageRequestClient. The clients could all be on the same bus, however. The services, which consume the request and Respond should be on separate receive endpoints (their own queues). At least that's the way I see it making the most sense for your case.

On Tue, May 19, 2015 at 11:20 AM, Christos Delivorias <c.deli...@gmail.com> wrote:

Thanks for the clarification Chris.
So each message contract would need it's own MessageRequestClient? And for multiple message request you inevitably need multiple buses?
Is that right?
I just want to make sure I'm not duplicating MessageRequestClient constructors all over the place for no reason.

Thanks again.

On Monday, May 18, 2015 at 5:55:59 PM UTC+1, Chris Patterson wrote:

You can subscribe to interfaces, but the approach you are presenting really does not follow what MT and messaging in general is designed to handle. MT will already dispatch messages to consumers by type, so a base class or common interface really adds zero value.

This is particularly true in Command cases, where the command is a contract between the service and service's consumer. In this case, avoid sharing any implementation between different services as it confused ownership of contracts.

Also, I highly recommend interfaces for all message contracts, because it ensures no behavior makes its way into the message itself.

On Sun, May 17, 2015 at 5:17 AM, Christos Delivorias <c.deli...@gmail.com> wrote:

Coming back to the example that Chris has published on the Request/Response communication.
I wanted to be able to have a common gateway, that creates a MessageRequestClient<IRequest, IResponse> but then have consumers that impement the IConsumer<ConcreteRequest> or IConsumer<ReenforcedConcreteRequest>, where ConcreteRequest and ReenforcedConcreteRequest implement the IRequest interface. This way from one common gateway I can send multiple base requests, and have consumers with different logic produce Responses.
I guess I could just have a gateway for each class of messages, but I'd like to avoid this kind of code bloat if I could.

Am I missing something here?
I believe MT can have consumers that subscribe to base classes; or is this jus tin the pub/sub model?

Any thoughts would be useful on this.

Thanks
C.

--
You received this message because you are subscribed to the Google Groups "masstransit-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to masstransit-dis...@googlegroups.com.

To post to this group, send email to masstrans...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/masstransit-discuss/a6e34915-8bde-4c5c-8bd2-0f1032038e1a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "masstransit-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to masstransit-dis...@googlegroups.com.

To post to this group, send email to masstrans...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/masstransit-discuss/3753d90d-e1ac-412e-b1db-a176e3b45871%40googlegroups.com.

Christos Delivorias

unread,

May 28, 2015, 12:15:06 PM5/28/15

to masstrans...@googlegroups.com

Hi Chris,

If I set the receivepoints on the services that consume the requests to something else than the same as the clients' then I get no responses from the workers. Messages just time-out.

No problems if they are the same though.

Client Consumer

bus => common bus =>unique to consumer
MessageReqClients => unique

RecPoint => "request_service_name" RecPoint => "request_service_name" <-- Works

RecPoint => "request_service_name" RecPoint => "response_service_name" <-- Doesn't work

Any thoughts?

Thanks.

On Tuesday, May 19, 2015 at 10:49:29 PM UTC+1, Chris Patterson wrote:

For each request/response pair, you would create a different MessageRequestClient. The clients could all be on the same bus, however. The services, which consume the request and Respond should be on separate receive endpoints (their own queues). At least that's the way I see it making the most sense for your case.

On Tue, May 19, 2015 at 11:20 AM, Christos Delivorias <c.deli...@gmail.com> wrote:

Thanks for the clarification Chris.
So each message contract would need it's own MessageRequestClient? And for multiple message request you inevitably need multiple buses?
Is that right?
I just want to make sure I'm not duplicating MessageRequestClient constructors all over the place for no reason.

Thanks again.

On Monday, May 18, 2015 at 5:55:59 PM UTC+1, Chris Patterson wrote:

You can subscribe to interfaces, but the approach you are presenting really does not follow what MT and messaging in general is designed to handle. MT will already dispatch messages to consumers by type, so a base class or common interface really adds zero value.

This is particularly true in Command cases, where the command is a contract between the service and service's consumer. In this case, avoid sharing any implementation between different services as it confused ownership of contracts.

Also, I highly recommend interfaces for all message contracts, because it ensures no behavior makes its way into the message itself.

On Sun, May 17, 2015 at 5:17 AM, Christos Delivorias <c.deli...@gmail.com> wrote:

Coming back to the example that Chris has published on the Request/Response communication.
I wanted to be able to have a common gateway, that creates a MessageRequestClient<IRequest, IResponse> but then have consumers that impement the IConsumer<ConcreteRequest> or IConsumer<ReenforcedConcreteRequest>, where ConcreteRequest and ReenforcedConcreteRequest implement the IRequest interface. This way from one common gateway I can send multiple base requests, and have consumers with different logic produce Responses.
I guess I could just have a gateway for each class of messages, but I'd like to avoid this kind of code bloat if I could.

Am I missing something here?
I believe MT can have consumers that subscribe to base classes; or is this jus tin the pub/sub model?

Any thoughts would be useful on this.

Thanks
C.

--
You received this message because you are subscribed to the Google Groups "masstransit-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to masstransit-discuss+unsub...@googlegroups.com.

To post to this group, send email to masstrans...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/masstransit-discuss/a6e34915-8bde-4c5c-8bd2-0f1032038e1a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "masstransit-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to masstransit-discuss+unsub...@googlegroups.com.

To post to this group, send email to masstrans...@googlegroups.com.

Chris Patterson

unread,

May 28, 2015, 2:27:21 PM5/28/15

to masstrans...@googlegroups.com

Without a more complex example, I'm unable to give any help.

Thanks.

To unsubscribe from this group and stop receiving emails from it, send an email to masstransit-dis...@googlegroups.com.

To post to this group, send email to masstrans...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/masstransit-discuss/a6e34915-8bde-4c5c-8bd2-0f1032038e1a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "masstransit-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to masstransit-dis...@googlegroups.com.

To post to this group, send email to masstrans...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/masstransit-discuss/3753d90d-e1ac-412e-b1db-a176e3b45871%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "masstransit-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to masstransit-dis...@googlegroups.com.

To post to this group, send email to masstrans...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/masstransit-discuss/dbda9d41-52c4-49ed-8e8e-91dc742cdfb3%40googlegroups.com.

Christos Delivorias

unread,

May 28, 2015, 4:14:12 PM5/28/15

to masstrans...@googlegroups.com

That is a fair point actually.

Going back then to your sample here: https://github.com/MassTransit/Sample-RequestResponse

Both the client and the request service share the same ServiceAddress and ServiceName.

Given what you said above, did you mean that the RequestService should/could have a different ServiceName passed to it?

Because I'm not sure it would work then.

Thanks.

To unsubscribe from this group and stop receiving emails from it, send an email to masstransit-discuss+unsub...@googlegroups.com.

To post to this group, send email to masstrans...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/masstransit-discuss/a6e34915-8bde-4c5c-8bd2-0f1032038e1a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "masstransit-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to masstransit-discuss+unsub...@googlegroups.com.

To post to this group, send email to masstrans...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/masstransit-discuss/3753d90d-e1ac-412e-b1db-a176e3b45871%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "masstransit-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to masstransit-discuss+unsub...@googlegroups.com.

To post to this group, send email to masstrans...@googlegroups.com.

Faisal Nadeem

unread,

Apr 11, 2016, 7:08:43 PM4/11/16

to masstransit-discuss

Hi @Chris.

I have the same question. I have two instances of Requester and two instances of Responder.

Would it work fine with the same endpoint?

Because in the Github example both (Requester, Client) has same service address.

Reply all

Reply to author

Forward