EDA is highly distributed.
This results in LOTS of processes and LOTS of config files.
This is another topic you want to think about at the beginning of the project.
We got this mostly right, by having Agent properties (JVM level) and Services properties. Service properties inherit from Agent properties (and can override them). We had some Java classloader problems, however, with Hibernate (not a big fan of ORM period - time savings are a myth - what is so wrong with SQL!? - sorry for the rant) and ended up with a property file on the system classpath. This seemingly small little problem became a total hassle. Last time I checked, it is still setup this way. We have talked a couple times about fixing it, but it keeps just getting talked about. We have talked about it enough to fix it 2X probably. And people trip over it occasionally.
So anyway, not too proud of this - don't do this. Pick a consistent approach and stick to it. If there is a problem, get it fixed right away or it will cause all sorts of little problems.
2 comments:
I've done configuration a time or two in my day. There are two take-aways from all the times I've suffered through it: keep it simple, stupid and allow inclusions.
The tendency is to make your configuration system the uber-system to end all systems. Avoid that tendency like the plague. Keep it as simple as possible because all that complexity will just make it harder to edit and (this part is more important) validate. This means to sacrifice the sacred cow of XML. Gosling did it right with Java properties; use something like that. Put everything in one place. It can be a directory or even the same URL. That way you only have one piece of data that you have to navigate through all the different systems. Once that prefix gets to your configuration code, it can derive everything else from there. This way you don't have to reconfigure your containers if you decide on a different layout for the configuration files.
The one bit that may look like complexity but actually makes things more simple is enabling the including of one file in another. This allows you to maintain cohesion in your configuration as well as your software.
Oh, and there ain't nothin' wrong with SQL. All you really need is a layer that managers your connections and result sets for you. I've got a buddy who works for an O-R company and I still won't drink that Kool-Aid anymore.
again who is this smart guy named Sarge? Jeeze.
With you on the xml - we tried that together and I have done much worse, but that wasn't worth the complexity I agree. I'm perfectly fine with properties.
Post a Comment