Remoting architecture

[go...@roseen.se]

Dear all, I have a question of a general kind:
 
How do you use log4net in a system with an architecture that involves remoting?
 
Consider, for example, an enterprise system consisting of a webserver W (in the companys DMZ), an
application server A (on the inside) with business logic components that connects to a database D.
Sometimes the business logic components need to call components on a server T that hosts some kind
of third-party software. Calls from W to A to T are using .Net Remoting, calls to D are using
Ado.Net.
 
Yes, I realize that I reveal myself as a person that previously has been forced to work in the ASP 
- COM - DCOM world... But the question is still valid, there are still in the .Net world several
reasons for wanting to distribute your companys software over several servers.
 
Consider some ways to go:
 
- I can have a configuration file on every server, and let every component do it's logging locally,
but that means that the logging info for a single call is spread over all machines that it has
passed, and it is up to me to merge it. Changes in configuration will have to be duplicated over
many machines.
 
- Next level might be to configure a remotingAppender on all machines (all but the one where the
logging will be persisted), transmitting to one single machine that hosts a RemotingServer. I am
not so sure about how flexible this will be though, the "local" config files will have to say
"deliver everything" to the RemotingAppender, but how much can we say on the logging server, when
the RemotingServer have picked up the event?
 
- An ugly solution might be to let every "called" component create instances of class LoggingEvent
(or similar), and return an array of those. Then the main app takes that array and logs them...
 
- A dream solution might involve a special remoting-aware LoggerManager class that takes care of
retreiving and caching the config files from the "logging server", and transparently passes the
events that shall be logged to a repository on the logging server.
 
I guess my wish list looks like this:
 
* One single config file (to rule them all...and in the darkness bind them... :-). At least only
one place where changes will be made.
 
* One place where logging is "done". All appenders that can work over the net (AdoNetAppender,
NetSendAppender, RemoteSyslogAppender etc) may of course so so, but file logs, the windows event
log and so on will be on this machine.
 
* The code that logs will (preferably) not have to know it is in a remoting scenario. An exciting
problem is how the decision wether to log or not will be done, if the logging level, filters etc is
set in the config file on another machine.
 
* Minimal extra "fuzz" (managing clients and servers and config files spread over a big
organizations many servers)
 
So what I really ask for here is; How do YOU do this, and how would you LIKE to do it?
There must be many ways do do this, what do you think the pros and cons are?
 
Sincerely,
Göran Roseen