[Top] [All Lists]

RE: Need to look at tracing and debuggig

2003-04-01 12:27:20
see inline,

-----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


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:


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?

see above

The second approach provides a kind of opposite advantages and 
disadvantages: simple per-message information binding but 
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 

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.


agree too

A reasonable combination may include message-related information in 

Direct point exposure (let's say by inclusion of URL into 
the tracing
raises a question about out-of-band protocol used to access this 
point. SOAP looks like a good candidate for that.


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).



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.