Hi,
Agreed on all
Abbie
> -----Original Message-----
> From: Alex Rousskov [mailto:rousskov@xxxxxxxxxxxxxxxxxxxxxxx]
> 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.
>
>