For once, we have the luxury of a few days to sit and plan the architecture in some depth before diving into the code. I found myself in an interesting situation pondering the difference between service agents and gateways.
In my previous projects, i used to implement a gateway component at the boundary of the system and in that , there would be dedicated service agents for each external system. So the gateway was really a collection of agents and some helpers for the same. Anyway, now i find myself in a vast integration project with a collection of 'core' systems providing some common services, a set of internal business applications and a few external systems waiting in the wings.
So, the question is, where do we apply these specific patterns?. Is everything outside the hub (in the corporate firewall or not) a 'external' system which needs a service agent via a gateway? or should i maintain the gateway only for totally external systems to handle both incoming and outgoing traffic.? If we have service agents for all systems, it would be consistent (and they woul, in almost all cases, be implemented as orchestrations). Interesting choice huh? Im still chewing the fat on that one so any comments would be welcome.
Anyway, another really good resource i came across is the APPLIED INTEGRATION BASELINE from Microsoft. The narrator application is really cool and walks you through the whole set of patterns. Theres also a ton of code and they've even managed to do BTS deployment using .NET Code instead of the mickey mouse VB scripts and batch files that seem to be all over the place. Gotta check that one out. The code organisation is quite interesting too(although for some reason, they have chosen to put every single use case in a separate solution... that isnt very maintainable is it?)
Speaking of code structure, i'd really like to see some guidance from MS on structuring code for very large projects, setting the correct relation between namespaces and folders etc. I've seen this vary vastly in different peoples projects. I've even seen some Java folk who move into .NET doing exactly the same kind of namespace naming standards and structures that they used to follow in Java. Feedback welcome.