Problems With The Organic Model Of Distributed Configuration
Posted December 13, 2006 at 9:57 PM
Thanks to the recent issue of the Fushion Authority Quarterly (vol 2), I have gained a much better understanding of how Mach-ii and Model-Glue work in the world of ColdFusion. I am sure there are many gaps in my understanding, but that is something I can only learn with experience (of which I have very little). From what I have gathered though, these ColdFusion frameworks are big on centralized configuration. There are probably tweaks that can be done, but it seems that in these frameworks (and many other people's choice configuration) all of the event handlers, controllers, and views are defined centrally.
This centralized configuration makes me very uneasy. There's something about it that just seems very unnatural.
But, what is better than centralized configuration? Distributed configuration? Perhaps. I have never thought about this much, so, the best thing I can do is look at other distributed systems. To me, the best example of this is the human body; an organic, living system. True, the human body does have a brain which could be considered centralized, but it also has a hugely distributed nature. The brain can really only send out messages but it cannot force the body to do anything. The rest of the body only responds based on receptors. If a cell doesn't have receptors or fails to respond to nerve impulsed, the brain is eccentially useless. And what determines the receptors of a cell? The enormous amount of distributed configuration data that lies in the DNA/RNA of the trillians of cells that exist in the body.
Now, you might argue with me, but I think the human body is the most amazing machine every built. So, I would have to think that however the human body does it is a good model. How can I describe this model? Well, as much as it seems like the brain is centralized, it could also be considered just another part of a distributed system; it releases and responds to messages just like any other part of the human system.
This seems great in theory. But it also makes me feel uncomfortable. I couldn't quite figure out why until I was crossing over into Brooklyn on the F-Train. Then it hit me: the body is amazing, but it's not perfect. It only rocks when it works according to plan. If something messes up, the body can crash and burn.
One of the biggest problems with software is making sure everything that needs to happen, happens. If you have object X and its joined to Y and Z, then if you delete X, you also have to make sure that the relationships to Y and Z are deleted as well. If you don't then you have data errors and referrential errors and the system may or may not fail. The problem is, the human body works the same way: if you have cells that need to respond to certain messages but they do not (ex. not being able to respond to insulin), the body, just like the software program, will crash and burn.
I guess that is why you can't just rely on sending out messages from small, independent units; if there is no "greater logic" making sure that all of it goes according to plan, then there is no guarantee that things will work as they are supposed to. That's the problem with a distributed configuration system: there's no garantees.
I am sure I am not looking at this properly. I am sure there are many problems with the way I am interpreting systems and messaging and dependence. I am still not sold on centralized configuration, but I am also not sold on a completely distributed configuration systems with a "messaging" backbone. I am sure in the end, it will be some sort of combination of the two. My gut still tells me to lean towards distributed... but I have no good ideas.
Sorry if this explanation has been a waste of time, but it's helping me figure out how to make things work.
Post Comment | Ask Ben | Permalink | Other Searches | Print Page
Newer Post
Creating And Streaming Simple Microsoft Excel Files With ColdFusion
Older Post
Clark Valberg On Interface Driven Architecture Methodology
Reader Comments
I am sure I am not looking at this properly.
I think that's right. Most programs are built around Events and Listeners. Your "greater logic" suggests a course of action if no events happen. I think only games do that.
I'm programming a business simulation game. For example sake, lets say my factory needs 10 steel a round. If I'm not there to click the "buy steel", the factory sits idle when it runs out of steel. If the factory doesn't make stuff, obviously there is nothing to sell.
If a "greater intelligence" could buy the steel without me having to tell it to do so, that would be great. But, that brings up a cascading set of issues. Does it find a better price? Does it stockpile a reserve? etc.. And it gets immensely more complicated to program.
The frameworks you mention are good at performing actions of buy/sell. But the greater intelligence needs to ask "who, what, where, why, when" questions, if no events are happening.
Jeff,
I am sorry, I believe that I miscommunicated. I did not mean the actions taken if no events occur. By "greater logic", I meant something that ties many events together.
For example, let's say that we have an application that has departments, locations, and employees. Now, for arguments sake, let's say that an employee can exist without being assigned to a department. Likewise, locations and departments can all exist independently.
Now, let's say someone decides that heck, if I delete a department from the system then the system should also delete all employees from the system who worked at that location (provided they don't also work at another location) and all locations that were used ONLY for that department.
To me (with my very limited OOP experience) I would say that departments should not really know about locations and shouldn't really know about employees. These are all independent objects that have indirect relationships.
If someone request that a department gets deleted, perhaps it then announces the event of it's own deletion. This even is now circulating in the system. That's fine if other objects understand how to use it... but, if employee and location do not understand that they need to respond to the event that deleted a department, then nothing happens.
My greater logic entity would make sure this happened and not just rely on a circulating event model. If you had an Application service that had some sort of DeleteDepartment() event it could then turn around and check locations and employees for dependencies that would require them to be deleted as well.
It seems that this "greater logic" that ties independent units together based on business logic, not data-referential logic, is the centralized configuration model.
Again, though, I am just making this up as I go.
