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.