This can be done using a WCF CallBack contract.
If the client can make a connection to the server, the server can use a WCF service with a callback
construction. This describes that the server expects the client to implement a service as well (the callback service), as part of the service contract.
This beaks down as follows:
The server hosts a WCF service.
The service contract has a CallBackContract attribute:
[ServiceContract(CallbackContract = typeof(IMyServiceCallback))]
Clients that want to use this service, must implement the desired callback contract (service) to be able to communicate with the server.
When a client connect with the server side service, the reverse / callback connection will be made over the same connection.
Using callbacks is done over the same connection (that has already been opened). This requires a two-way communication channel (for example http
).
See http://adamprescott.net/2012/08/15/a-simple-wcf-service-callback-example/ for an example how to implement this.
Communications do not usually only go one way. Parties usually communicate using request-response pairs, which are clearly not one way. I presume that you already know this, so what you are probably thinking when you say "one-way" is not how information flows, but who initiates the requests.
So, yes, the way we usually do things is that only one of the parties initiates requests. Which means that the other party always sends responses.
But there is an exception: the "callback", otherwise known as the "notifier-observer" pattern. It is perfectly fine for one side to send a "register observer" request to which the other side will immediately respond with an "observer registered" response and then, in the future, with one or more "event observation" responses.
Your terminology with "front-end servers" and "back-end servers" and other unrelated entities you call "clients" only confuses things, and you should not have brought it into the discussion. Things are very simple: Within the context of a communication session between two parties, the requesting party is always called a client, and the responding party is always called a server. In your case, your server is what you call a "back-end server", and your client is what you call a "front-end server".
EDIT:
Of course, in order to accomplish two-way communication you need to employ two queues. I have worked on one large-scale system which employed two queues per pair of modules that communicated, (one queue for each "way" in the "two-way",) so trust me, it is not something bizarre.
Best Answer
It seems pretty clear that it's preferable to deliver messages only to the clients that are interested in them. For one the other clients perhaps shouldn't know about orders that they are not involved in. The other factor is that as your client base grows, the amount of messages grows at an unsustainable pace.
Let's consider an example under these assumptions:
With a single customer, that's (100 * 10 * 5) = 5,000 messages you need to send a day. Now let's say you have 100 customers. If you send only messages to clients that need them that turns into 500,000 messages a day. Now consider if you send every message to all the clients: that's (100 orders* 5 updates * 100 customers) = 50,000 updates that you need to send to (100 customers * 10 clients) = 10,000 clients. That's 500 million messages or a 100,000% increase in messages. The growth in this situation is quadratic. Each new customer increases is not only more expensive to support but also increases the cost of supporting all the existing customers.