Dependency Management

In the system development, that is really usual that multiple members would join their project to work out a specific function for the coming demand on this system. As the past paradigm which focused on the software and package aspect about the system, the all dependency would be considered about at the early design stage and we have already whole bunch tools that help us to control on those "static binding dependency" between the different binary library files. The compiler is the first stop to be the static binding dependency checker for our software and package. And the programming language infrastructure like C++ has introduced the namespace concept into our practice and give the developers and IDE a good foundation to manage the static binding dependency. A good static dependency design brings benefit on the system flexibility in the future. Therefore, there are so many useful design pattern about how to depict the hierarchy of classes. A good design pattern would have percipient about future change and coordinate libraries in a modest way.
However, just like the beginning of this post, the static binding only solve the internal coupling issue of a set of binary libraries. There are more issues when we combine all those projects into a system. We can categorizing those issues into two genre. One is the issue at early binding. It's pretty common that our program is running on a runtime like .NET or JVM and container like IIS, Tomcat, WPF or even a windows service. The runtime and container provide the variety and useful core libraries for our application. Hence, we write the configuration file for deploying our binary file quite often. Those configuration file is the prime communication way to those runtime and container and tell them what kind of basic service we want those foundation to provide such as authentication method, session control, type including or Resource location. Once the configuration has trouble with the binary files we've deployed or the runtime and container's ability. The early binding activity would alert an error at the initiation of the executable file when Operation system load the whole application into memory. Those executable files such as w3wp, java.exe are the most common container and runtime which require a strong background knowledge about their configuration or command line parameters. Early binding issues require the modern IDE or some trouble shooting skill to dig them out when we try to deploy the application on new machine.
The second genre of dependency management issue other than static binding is the lately binding which is the hardest part without a reliable tool when we deploy the project that we don't familiar with. So called lately binding means that we might never be aware of some type or class implementation loss at deployment until the actual request or running application went through those particular section of our source code. The lost library or class are only initiated when the application ask for. Those libraries or classes are dynamically loaded or reflected by the program when it's necessary. Which means there might be no adequate audit or document that recalls that weak points of the deployment activity. The dynamic loading mechanism is pretty advanced feature in modern system development. Although the blind spot at deployment activity would jeopardize our online application, the flexibility and replaceable binary at runtime still be really attractive to a lot of developers adopt this mechanism into their system design.
The three dependency management aspects mentioned above are all talking about the dependency inside the same process image of a specific memory section that operation system has allocated. But there is a dependency issue that is quiet common at distributed system project. The issues are addressed about the remote service dependency like web service or client-server dependency. At usually circumstance, the consumer (i.e. client) require a specific service provided by a non-existing or accidentally missing server. The occasion was generated by the remiss on deployment activity. Like the missing of dynamical loaded libraries, the possibility of sending the request to a vacant service entry would rise the stake of a certain exception that damages our online application. However, this is due to the neglect of some specific service for the system and the remedy is pretty easy if we have dealt with those exception neatly, just start the remote service. The trade-off between flexibility and integrity of deploying should not be skipped while system analysis. And the balance of flexibility and integrity can also be affected by or do impact to the design of static binding mutually. But this big question is belonging to the domain knowledge among how we isolate the most often changed part in some certain applications. This philosophy perspective has beyond the scope of this article.