0

I am currently experimenting with implementing the micro service architecture on a REST service that I will be developing. The REST service will communicate with a third party SOAP service and also another component that I will be creating to perform additional business rules validation. I plan to split the application into three distinct components: the Web API to which clients will send requests, a windows service that will call a third party SOAP service and a windows service to perform business rules validation. I am planning on using a combination of the actor model (Akka.net) along with a message bus (NServicebus or RabbitMQ + Mass Transit).

From what i understand, messaging is meant for fire and forget commands, so it cannot be used by the Web API project as the clients will be expecting a response from the call to the API and I am not sure how I would await receiving the message from the Bus/Queue in the client request to the Web API as there would need to be away for the Web API to listen for an event from the bus in the request.

My question is, Am I correct in my understanding of how messaging queues operate? And, I will have to use an Akka.net based micro service to accept calls from the Web API and return the response to the API?

NyronW
  • 1
  • 1
  • 1
  • I don't see a compelling argument in your question for using _both_ Akka.Net _and_ a message bus, and of course even using one is a choice. (I've used an Akka.Net service from an MVC web app; no reason for a message bus.) With Akka.Net, you generally use "Ask()" from the web app to make it wait for a response from the service. There's some stuff on the Petabridge site you should read but the best how-to I've seen for getting started with a web-app + back-end-service is at http://firojshaikh.com/?p=79 – mwardm Jul 27 '17 at 23:35
  • I understand what your saying, however, I believe that message bus makes it much easier to extend the system with new services by simply subscribing to events on the bus. Not sure if that's the case while Akka.net – NyronW Jul 27 '17 at 23:59
  • Hey, as long as you've thought about it. (I think I've heard it said that Akka.Net uses the paradigm of messaging _within_ a service while message buses / queues are for messaging _between_ services.) The "Ask()" still applies, though :-) – mwardm Jul 28 '17 at 23:20
  • You're right, I just wanted to ensure that I was fully understanding the options that are available. I think that, in general, you use the actor model to gain concurrency, while messaging is for message durability. So they both offer something different to distributed systems. I plan to use micro services architecture for the application and one of the suggestion is to not have coupling between services; but how would you achieve this with akka.net, as each service would need to share the message types in the application. So all services would be coupled to a shared library. – NyronW Jul 30 '17 at 02:40
  • Not sure I'm the authority on what your options are (in fact I'm certain I'm not), but with (some definitions of) strong typing you'll always have that coupling, no? You could always pass a message as a string with some serialisation mechanism of your own, of course. I think akka.net's story for providing loosely coupled services is more vague than I'd like (or at least I'm vague on it). More-knowledgeable people are helpful in the Gitter room if you want some more opinions. – mwardm Aug 02 '17 at 19:07

1 Answers1

1

Technically you can use request-response, see example here. However, that approach should be used with caution, in legacy apps or in specific situations where the situation really requires it.

Generally though to fully benefit from messaging, its reliability and scalability, you should redesign your solution to be asynchronous. If you need response then use request-response pattern (i.e. send two one-way messages instead of using callbacks), or look into technologies such as SignalR. Here and here are webinars talking about connecting front-end apps with messaging in more detail, I hope you'll find them helpful.

wlabaj
  • 468
  • 2
  • 6
  • Thanks for your feedback, I have done some research and found similar article to the links that you provided. How ever my front end will be a REST web API, so I'm not sure that us g signalr would be applicable for that implementation as the api clients need a response from the api for the current request – NyronW Aug 10 '17 at 14:28