see inline,
abbie
-----Original Message-----
From: Markus Hofmann [mailto:markus(_at_)mhof(_dot_)com]
Sent: Tuesday, April 01, 2003 1:31 PM
To: OPES Group
Subject: Re: Need to look at tracing and debuggig
Oskar,
great input, thanks. Just some quick, minor comments:
1. Tracing information has to be provided in-band, I see no
other way
to satisfy current architecture requirements. The OPES architecture
states that:
I agree with that. The question is, though, whether the callout
protocol itself will also carry some tracing information, or whether
the callout server will embedd possible tracing information directly
into the application message.
---- abbie
I agree tracing should be done inline. whether the ocp will carry the
tracing info or not has to be answered with the next question below. I think
that tracing has to go throu the opes processor, the callout server is just
a slave in this case. I know that this will add more burden on the processor
in particular, if info need to be saved.
2. We have to decide on the in-band - out-of-band balance
for tracing
facilities. Two extreme approaches are:
SNIP
Nice comments. I was tempted to lean towards the first
approach with a
refrence to a point for retrieval, but.... Where would such point of
tracing information retrieval be? Would you assume that, for example,
I can retrieve detailed tracing information about a provided OPES
service directly from the callout server the service has been
executed? Such a callout server might very well sit behind a NAT and
might have a non-routable IP adress... If it's not directly on the
callout server, how would the callout server provide the required
tracing information to the other entity?
-----------abbie
see above
The second approach provides a kind of opposite advantages and
disadvantages: simple per-message information binding but
application
protocol may be cluttered with excess information that is
not relevant
to the current session (may be due to the lack of interest of the
participants).
An additional advantage of in-band approach is end-to-end coverage:
tracing information and related directives are available to
all OPES
flow participants, no topology knowledge is required.
Yup, good point, have to agree.
-----------abbie
agree too
A reasonable combination may include message-related information in
snip
Direct point exposure (let's say by inclusion of URL into
the tracing
information)
raises a question about out-of-band protocol used to access this
point. SOAP looks like a good candidate for that.
-----abbie
agree, but how about duration and the extra burden of storing the info.
Do we have to decide on a specific protocol to be used for this
purpose, or can we leave this open and just indicated the protocol to
be used (e.g. withing the embedded URI).
-Markus
-------abbie
I have discussed embedded URI before, it could been argued that this is out
of band.
even with that we need to answere questions such as who did what when and
may require signatures etc..
This sounds like the trace (debugg token) that we spoke about before.
abbie