3. The Four Universal Parts of Any Software
The file set of any Application Software, graphical, server-side, commercial, open/free, monolithic etc, has allways four universal parts:
1st :: The Software on its own: the body
The executables, libraries, static-data files, examples, manuals and documentation, etc. Regular users must have read-only access to these files. They are changed only when the system administrator makes an upgrade in this Software.
2nd :: Configuration Files: the soul
These are files that define how the Software will run, how to use the Content, security, performance etc. Without them, the Software on its own is usually useless.
Depending on your Software, specific privileged users may change these files, to make the Software behave as they want.
It is important to provide documentation about the configuration files.
3rd :: Content
Is what receives all the user attention. Is what the user delegated to be managed by your Product. Is what makes a user throw away your product and use the competitors', if it gets damaged.
Are the tables of a database system, the documents for a text editor, the images and HTML pages of a web-server, the servlets and EJBs of an Application Server, etc.
4th :: Logs, Dumps etc
Server Software use to generate access logs, trace files problem determination, temporary files etc. Other types of softwares also use this files, but it is less common.
It is the last class of file, but many times they are the most problem generator for a system administrator, because their volume can surpass even the content size. Due this fact, it is important for you to think in some methodology or facility for this issue, while you are in design time.
3.1. Practical Examples
Let's see how universal is this concept analyzing some types of softwares:
Table 1. Universality of 4 Parts
| Software on its Own | Configurations | Content | Logs, Dumps etc | |
|---|---|---|---|---|
| Data Base Server | Binaries, libraries, documentations. | Files that define the directory of the data files. For this type of Software, the remaining configurations usually are in special tables inside the database. | Table files, index files, etc. This software use to have whole trees under the same directory. And many times they need several filesystems to guarantee performance. Their local in the system is defined by they Configurations. | For DBs, there are the backup, generated in a daily basis. And the logs are used by the DBA to define indexing strategy. His local on the system is also defined by the Configurations. |
| Text Processor | The same, templates, modular file format filters, etc | As a user-oriented Software, its configurations must be put in each user's $HOME directory, and are files that defines standard fonts and tabulation, etc. | The documents generated by the user, and they go some place in his $HOME | They show as temporary files that can be huge. User can define their location with a user-friendly dialog (that saves it in some Configuration file) |
| MP3 generator | Same, audio modular filters | Each user has a configuration file in his $HOME, and contains bitrate preferences etc | Similar to Text Editor | Similar to Text Editor |
| Web Server | Similar to Data Base | Files that define the Content directory, network and performance parameters, security, etc | Directories where the webmaster deposits his creativity. Again defined by the Configurations | Preciouses access logs, vital for Marketing Intelligence, that are generated in a location and format defined by Configurations |
| e-Mail Server | Similar to Database and Web-Server | Files that define how to access user database, mail routing rules, etc | The preciouses users mail boxes. Again defined by the Configurations | Mail transfer log, virus detection log, etc. Again defined by the Configurations |
Pay attention that the Software on its Own contains all your product business logic, which could be useless if you hadn't a Configuration to define how to work with a data bundle, provided by the user. So, Configurations are what connects your product to the user.
We can use a metaphor about a Sculptor (business logic), that needs Bronze (content) and a Theme or Inspiration (configuration) from a Mecenas (user), to produce a beautiful work (content). He make annotations in his Journal (logs) about his day-by-day activities, to report to his Mecenas (user).
3.2. The Importance of Clear Separation Between Four Parts
OK, so let's be more practical. The fact is, if we correctly use the universal parts concept, we greatly improve the quality of our Product. We'll do that simply separating, encapsulating, each one of these parts in different system directories (having only different files for each part is not sufficient). There is a standard called FHS that defines the Linux directories for each part, and we'll discuss it later in Section 4.
By now let's see the value of this separation to the user:
He gains a clear vision about where is each part, specially his Configurations and Content, and he feels your Product as something completely under control. The clareza brings ease of use, security and confidence in your Product. And in practice it permits him manipulate each part independently
It is clear now that, for instance, when backing up, user action is needed only for Configurations and Content (the puritans will also backup some logs). The user don't have to care about Software on its Own, because it is safe, original, on the product CD, in his shelf.
For upgrades, the new package will overwrite only the business logic, leaving intact the user's precious Configurations and Content. Here is very important to keep old content and configuration compatible, or to provide some tools help migration of data
The logs being kept in a separate filesystem (obviously suggested in your documentation), avoids that their exaggerated growth interfere with the Content, or with the stability of the whole system
If your Software follows some directory standards, the user don't have to reconfigure his system or environment to use it. He will simply Install-and-Use.
Let's make some exercise with separation using as example a system called MySoftware, in which the business logic is in Example 1 and the configuration is in Example 2.
Example 1. A Shell program referring an external configuration file
#!/bin/sh ############################################################################# ## ## /usr/bin/MySoftware ## ## Business logic of MyProgram system. ## Do not change nothing in this file. All configuration can be ## made on /etc/MySoftware.conf ## ## We'll not support any modifications made here. ## # Default configuration file CONF=/etc/MySoftware.conf |
- Definition of the configuration file name.
- Definition of some static parameters.
- The configuration is readed from an external file, if exists.
- After reading the configuration file, all content directories -- user's + product's -- goes together in the $CONTENT_PATH, that will be used from now on.
Example 2. File containing only the configurations for MySoftware
############################################################################# ## ## /etc/MySoftware.conf ## ## Configuration parameters for MySoftware. ## Change as much as you want. ## # Content directory. # A ':' separated list of directories for your content. # The directories /var/www and /var/MySofware are already there, so # include here your special directories, if any. CONF_CONTENT_PATH=/var/NewInstance:/var/NewInstance2 |
- These are user defined parameters.
3.3. One Body, Many Souls
When I was a system administrator for IBM e-business Hosting Services, I was fascinated by Apache's flexibility letting us do things like this:
bash# /usr/sbin/httpd & bash# /usr/sbin/httpd -f /etc/httpd/dom1.com.br.conf & bash# /usr/sbin/httpd -f /etc/httpd/dom2.com.br.conf & bash# /usr/sbin/httpd -f /etc/httpd/dom3.com.br.conf & |
If we don't pass any parameter (like the first example), Apache loads its default, hardcoded configuration file from /etc/httpd/conf/httpd.conf. We built other configs, one for each customer, with a completely different structure, IP address, loaded modules, content directory, passwords, domains, log strategy etc.
This same concept is used by a text editor of a multiuser desktop (like Linux). When the code is loaded, it looks for a configuration file on the user's $HOME, and depending who invoked him (user A or B), it will appear differently because each user has its own personal configuration.
The obvious conclusion is that the Software's body (business logic) is pure e completely oriented by his manipulator's spirit (configuration). But the competitive advantage lays on how easy we switch from one spirit to another, like in Apache's example. It is very healthy to promote it to your user. You'll be letting him create intimacy, reliability, confort with your Product.
We used this approach with many different Softwares in that e-business Hosting time, and it was extremely usefull for maintenance etc. In a version migration we had total control over where were each of its parts, and upgraded and downgraded Software with no waste of time, with obvious success.
But there were some Products that refused to work this way. They had so many hardcoded parameters, that we couldn't see what divided the body from their spirit (or other parts). These Softwares were marked as bad guys and discarded/replaced as soon as possible.
We concluded that the good guys Softwares were intuitively blessed by their developer's four parts vision. And they made our life easyer. In fact, in that time we formulated this theory, that continues to prove itself.
Do you want to deploy bad guy or good guy Software?