Abstracting Routing Logic into Configuration Tables

I recently came across a customer that has a really flexible architecture which I haven’t run into before… and would be interested in speaking with anyone that has done something similar.

Rather than code the logic within webM services using flow or client groups, they’ve abstracted out the routing layer and created several “generic” services that route based on the message content. How the services are routed are defined within configuration tables which are then updated as needed to add new services. As I understand it, minimal additional coding is required within the primary flows because the logic is defined within the tables.

Has anyone seen or done something similar? If so, what were your experiences?


HI Dan,

The same way is implemented in our solution.
One general flow and all messages (xmls) enter in this flow. Then extract specific xml tags,
And route according this xml, but routing configuration is not stored in Database table. Routing configuration is hardcode in one large branch. This is faster, and actually these constants are not changed very often.

Krasimir Zlatev