If I had to guess, the original architect (or team) couldn't quite reconcile how to deal with synchronous-like communication in an asynchronous system. This isn't uncommon.
In an async system (using the bus), you submit a message and the system will process it as it gets to it, which in most cases is right away. Because the message is dropped on the queue, there's no direct way to get a response if you need one. So for example, if I wanted to provision a phone number with an SMS provider, I'd issue a message (a command) and some service would pick it up and provision it, but since I might not know what that phone number is, I'm relying on the server to tell me right now so that I can display it to the user. In this scenario, the async message pattern is problematic. In a synchronous system, I would ask for the SMS number and wait for the process to finish; the server would return the phone number directly. It's simpler and good enough for most systems, but you lose some resilience and the ability to buffer system loads.
There are a few patterns to get around this in an async system such as basic pub/sub, sagas, web sockets, etc., but I think the most common one in SOA is to have a response queue that the message producer would subscribe to after submitting the original command. When the system is finished processing the message, it'll deposit a response message into the response queue and the producer will get its answer. The most popular with web client -> server is to be event-driven over web sockets. Those that have not used these patterns before will almost always scoff at it and call it too complicated, then reject it and turn around to tack on a synchronous interface which may be what happened in your case with the rpc implementation being alone side the bus.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
If I had to guess, the original architect (or team) couldn't quite reconcile how to deal with synchronous-like communication in an asynchronous system. This isn't uncommon.
In an async system (using the bus), you submit a message and the system will process it as it gets to it, which in most cases is right away. Because the message is dropped on the queue, there's no direct way to get a response if you need one. So for example, if I wanted to provision a phone number with an SMS provider, I'd issue a message (a command) and some service would pick it up and provision it, but since I might not know what that phone number is, I'm relying on the server to tell me right now so that I can display it to the user. In this scenario, the async message pattern is problematic. In a synchronous system, I would ask for the SMS number and wait for the process to finish; the server would return the phone number directly. It's simpler and good enough for most systems, but you lose some resilience and the ability to buffer system loads.
There are a few patterns to get around this in an async system such as basic pub/sub, sagas, web sockets, etc., but I think the most common one in SOA is to have a response queue that the message producer would subscribe to after submitting the original command. When the system is finished processing the message, it'll deposit a response message into the response queue and the producer will get its answer. The most popular with web client -> server is to be event-driven over web sockets. Those that have not used these patterns before will almost always scoff at it and call it too complicated, then reject it and turn around to tack on a synchronous interface which may be what happened in your case with the rpc implementation being alone side the bus.