Hokay...so a bit of background: at the moment our LoB apps use a custom in-house transport protocol (TRAF) to communicate with Java application servers and Cobol application servers. Because it's a custom (read: badly designed) protocol, we have no way of monitoring the traffic servers and getting any real information from them. Over and above that, our CAB-like composite screen framework has a "bootstrapper" that it uses to update the assemblies before launch...which doesn't help when call centre staff leave their machines on and logged in with the app open overnight. I doubt we can get the infrastructure guys to agree to bounce their machines remotely (staff apparently have an ethical right to consume electricity overnight:-P) and as much as we try training them, we're never going to convince them to shutdown. (On an aside, one of the call centre staff insists on holding down the power button instead of going Start->Log Off, because it's "so much faster". She's been given two written warnings, she still does it.) Also, the infrastructure guys don't have MOM or SCOM. They're very hands-tied with the desktops, because responsibility has traditionally been so disparate - and this isn't going to change for a few years still.
I need to design a framework that will allow us to work with the current backend hacked-together infrastructure, whilst still being forward-thinking and giving us the ability to quickly turnaround should we begin changing communications methodologies and the like.
Proposed solution: CAG framework with one infrastructure module (for communication), one infrastructure module for utilities and code snippets, and the view modules (screens, really) entirely up to whatever the LoB developers need to create. The communication infrastructure module will NOT pass messages directly to the JBoss/Cobol app servers. Instead, it will pass it to a local Windows service (using WFC or ESB or whatever...any suggestions for this?). The Windows service will programmatically decide what to do with the message, and pass it on to JBoss or Cobol or whatever brand spanking new, completely disparate technology they introduce. Perhaps it will use the Sync framework as a means of caching data (it needs to shred and recompile the messages to reformat them for the destination service anyway), but it will have to have some sort of logging system either through a local cache or outside of one. Routinely (say, every 2 mins) this comm service will push it's message statistics (not the actual message contents) to a de-centralised monitoring database (SQL 2005+ has proper support for partitioned tables, allowing us to partition the data geographically, and pull a report from partitioned views). The flip-side is that the infrastructure team will be able to spot problems on a dashboard that updates from the monitoring database, and then connect to the Windows service remotely and subscribe to a copy of its messages, allowing for live inspection of messages (types, destinations, sources, content) as well as arbitrary command execution (I've had experience locking such services down on FreeBSD, they're not as dangerous as everyone imagines, especially in our relatively well-shielded environment - this is all internal). One other thing that the service will do is routinely poll the framework rollout directory (the logon directory is incrementally bit-copied between DC's, so we use a dedicated directory in their - which means that any client accessing the directory will always get a live DC and the one that is geographically closest to it) for an XML file, compare against a local XML file of directory contents, remove files no longer necessary, and then wait for assemblies to be unloaded before replacing them with current copies. A forced rollout could also be done, whereby we push a message to the user telling them that such-and-such a screen needs to be closed for an update; pass a message to the framework requesting a screen close; restart the screen. Self-updating of the service can be done on reboot, emergency updates can request a reboot and force one after a timeout. Roll-back strategy will use local backups (shadow copy?) and change control will be in place to ensure that only a limited number of people have write access to the rollout directory. The infrastructure guys are kinda excited about this, as they're tired of dealing with the existing pull-an-update-on-app-startup strategy.
Bearing in mind I've only thought about this for, like, a day...any thoughts on problems and improvements?
-Ric
And so the kief looked and lo, it was kief.