I have been pondering for a while the process of exposing information during system debugging and tuning, but with minimal to no overhead during runtime. This is something that I have been thinking about for a few months now, and thanks to an article in "Jounal of Object Oriented Programming" (JOOP) I think I have a workable plan. The article in question is from the October/November 2001 issue (Vol. 14, No. 4), "Tracking Software Components", pp. 13-22 written by Jerry Gao, Ph.D., Eugene Y. Zhu, and Simon Shim, Ph.D..
With the bibliography out of the way, let me describe the problem: System administrators need the ability to tune Phoenix and Excalibur components but information such as pool sizes are well hidden, and Developers need authoritative debugging and tracing information so that they can be assured that everything is behaving as expected. The article goes into more detail due to the fact that it is dealing with EJBs, JavaBeans, and other automagic components where their lifecycle is not well publicized or understood. This is exacerbated by the fact that different vendors don't always follow the spec as closely as they should and developers try to outsmart the system. For our case, we have a well defined lifecycle for components and strong contracts surrounding them. Avalon components have strong contracts and well understood lifecycles. This aids development, and the developer rarely feels (or should rarely feel) as if he needs to outsmart the system. In all honesty, the framework is not that difficult, and is fairly easy to grasp. We do need the ability to track that the environment is abiding by the rules (sort of a run-time verification), and we need the ability to expose normally hidden information during product development and initial deployment. Run-time verification simply receives events for a Component that signify the Component is going through it's state/stage transitions according to the contracts. It should provide some sort of notification if there is a conflict. Unfortunately this type of tracking has an associated overhead with it. The overhead can be expensive as 40% or more depending on how much. For this type of tracking the only thing I can suggest with any type of confidence is AspectJ. This allows runtime aspects to be placed on a system. The type of checking is standard accross the board and it does not require embedding hand code in our components. It has the added benefit that the Aspects can be removed in the run time causing an increase in response times for the system. Information Exposing is much more specialized, and needs its own set of contracts. There are three things we must ensure in order to expose information: 1) It is only done with the administrator's explicit approval. 2) It is switched out during the runtime causing only minimal performance degradation (by order of microseconds or less). 3) It is only exposed to an authorized client. This gives us three distinct challenges to overcome. The first is relatively easy, as it can be a switch set by the administrator to globally influence Avalon. That means that it can be a switch in a configuration file, or something similar. The exact mechanism will become evident after we decide on a final approach. Challenge number 2 can be overcome by a static final boolean flag that is initialized by the administrator's switch. That way, the information publishing is only performed if it is turned on. This does have the side affect of only being switchable when the class is loaded in a new classloader. However, this may be desirable as system tuning and running are two different concerns, and not too many people I personally know make a test system live without it being restarted in a new environment any way. Challenge number 3 is more difficult to overcome. There has to be some sort of handshaking that needs to happen to authenticate and authorize a client. For this solution, dynamically generated magic keys might be an attractive solution. It is basically how X Windows servers authenticate clients. They have some sort of magic key value that is used as a shared secret. Again, this may be overthinking it a bit. We have to consider the type of information we would be publishing, and then determine if it is worth it. Another solution is blind trust in the installed jars, and implement the Jar services solution (requiring JDK 1.3+). Let me provide an example of possible information that would be shared with the administrator: * Pool size information--used to determine the most efficient pooling sizes for the particular pooled components or datasources. * Role to Component mapping--used to verify that the expected component is used for the role. By extension, this would apply to Blocks and Services as well. The first example is relatively harmless, but the second example provides a possible security hole. The problem here is that when a security hole is discovered in a Block or Component, you don't want to advertise that you are using it. While this is obscurity, and not security, it does minimize potential attacks until you are able to plug the hole. Again, getting back to the ability of exposing the information, when a security hole becomes known it would allow the administrator the ability to verify if they have the affected component or not. Hense we have a catch 22-- Damned if we do, damned if we don't expose the info. This means we need a secure method of communicating the information to an external client. We also have to consider different types of environments. For example, Cocoon lives in a Servlet environment, but may need to expose information to the administrator. Phoenix is a known environment, and so this facility would be easy to embed. We can go from something as simple as a shared secret (*MAGIC KEY*), or as serious as full PKI (using JSSE for the TLS connections). The demands for such a system are that there should only be one (1) client connected at a time, and that the client be known to the server. This does in effect rule out the Jar services approach. One practical requirement is that the client needs to be able to be detached from the server environment. JSSE does provide automatic handshaking so that would minimize the developer effort (I have implemented the client side of PKI sessions with Apache JMeter). That requirement would in turn require the messages to be sent in a structured and known format. Is this something that is worth the time pursuing? I think so, but it would have to be a community developed approach. Keep in mind that Logging, while vital, does not necessarily provide the functionality we are looking for. It also does not allow us to isolate a specific class of information for quick retrieval and Ad Hoc querrying. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
