Hi,
Agreed on all
Abbie
-----Original Message-----
From: Alex Rousskov [mailto:rousskov(_at_)measurement-factory(_dot_)com]
Sent: Friday, August 29, 2003 12:36 PM
To: OPES WG
Subject: Re: [opes-end-comm]: What is traceable in an OPES Flow?
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.