.NET architecture design issue

Question

Im just starting to work on a particular piece of development.

We have a .NET WCF application, MySql/EF DAL/ORM, that is called by a threaded job scheduler that pulls data from one client, stores it in our DB and passes the latest data to a another client and vice versa.

So to think about it as messages,

ClientB sends an order to ClientA through our system which transforms the order into a readable format for ClientA.

ClientA then can send messages to the ClientB through our system to say stuff like "your order is shipped" or "your order is late".

I need to take these messages and relay them onto ClientB but I want it to be transactional and for us to have full control over failed messages etc.

My current thoughts are, for simplicity sake, to have a OrderMessages table in our DB which receives messages, with a state of "Ready" which can then be processed by a factory and forwarded to the relevant client using a configuration stored against the clients.

Sorry for this being all over the place, but hopefully I've explained what im trying to do :/

Neil

Answer 1

Consider leveraging a message platform for publishers and subscribers. Specifically, consider using a hub and spoke pattern.

Also, BizTalk specializes in workflows across distributed systems.

Also consider the effort involved:

• Transactions (short and long)
• Error handling
• Expected message formats
• Orchestrations

Answer 2

Your proposed architecture is a classic queue table pattern. Remus Rusanu is the canonical resource for building such a thing with SQL Server. The ideas apply to other databases as well.

There is nothing wrong with this architecture. Note, that in case of an error when messaging a client you cannot know whether the message was received or not. There is no 100% solution for this problem. It is the Two Generals Problem.

If you make the clients pull directly from the database you can avoid this problem. Clients can use their own transactions in this case.