On Fri, 29 Aug 2003, Markus Hofmann wrote:
Alex Rousskov wrote:
The intent behind the above two sentences is to allow "higher level" entities to manage traces for or on bahalf of "lower level" entities. For example, if an OPES processor uses 100 tiny callout services, the processor may be configured to remove all callout service entries from the trace and just insert its own entry (to keep the trace reasonably small).
It seems to me, however, that in this case, the OPES processor must still be able to identify those 100 tiny callout services when a user inquiry arrives later on. It's not sufficient just to know "yes, I did something to the message and a several services were executed". It's necessary to know exactly which services were executed. How else would someone be able to solve possible problems?
The above is indeed desirable but on a MAY level:
- The OPES processor may have a fixed configuration so it can always answer your question without any extra information in the trace.
- The OPES processor may insert a [coded] summary of the 100 services applied so that it can answer your question with more (but perhaps incomplete) information about 100 services.
- The user will most likely not understand and not care what those 100 tiny services are. We cannot demand that every service is documented sufficiently enough that every reasonable human being understands what it does.
* It is the job of the OPES processor to solve problems. Let's not tell it how. It is the right of the other side to complain about problems. Let's give it sufficient tools to do so. What is sufficient? Whatever the trace builder considers sufficient (because it is the builder that is responsible for decoding the trace details and solving the problem)! A System MUST be traced so that the other side always knows who to complain, regardless of what the trace builder considered "sufficient".
The first three arguments are just examples of why anything above MAY level would not make much sense when we are talking about something as poorly scoped as an OPES service.
The last argument is the most important one, IMO. It is the cornerstone of what I would consider a good tracing approach in an OPES context. The trace is a trouble ticket ready for submission to a known address. The trace in itself is not necessarily a detailed or clear description of what has happened.
We are not dealing with two "equal" sides communicating with one another. Our sides have very different view of the problem domain. Let's make it easy for a side to complain. Let's leave troubleshooting specifics to the troubleshooter since there are so many different ones that we cannot even enumerate them.
This should be spelled out in the document.
Yes, of course, but that's Abbie's job :-).
It might be a local matter on how this is achieved - one might decide to maintain the necessary state (well, I probably wouldn't opt for that option), or maybe the executed services get somehow encoded/encrypted in the trace entry itself...
Exactly.
Alex.