On Wed, 13 Aug 2003, Markus Hofmann wrote:
Alex Rousskov wrote:
Here is where I would start:
OPES system: OPES system is a set of OPES entities
defined for a given application message. The formation of an
OPES system is recursive: OPES system starts with either data
provider or data consumer (for the given message); OPES system
then includes any OPES entity trusted by (accepting authority
from) an entity already in the OPES system. The trust and
authority delegation is viewed in the context of the given
application message. As implied by the above definition, some
OPES entities in the system may not participate in the
processing of a given message.
Hm... Assume a carrier A trusting carrier B. According to above
definition, they both form an OPES system/domain. As such, they're
identified by a single OPES trace entry. To whom would an end user
turn if there're any problems?
To the [single] entity identified in the trace.
Now suppose there are two or more trace entries. To whom would an end
user turn if there're any problems?
A real-world illustration of the same problem is baggage handling by
airlines. When your checked-in baggage does not arrive with you at the
final destination, you are supposed to complain to a single carrier
only (the last airline, in this case). It is the responsibility of
that carrier to follow the global airline system/domain rules to find
your baggage and deliver it to you. Naturally, you would not normally
know exactly where your baggage have been, who lost it, and how it was
found.
OPES system implementations can adopt the same last-entity model if
they find it useful, but they do not have to. They may choose to
outsource OPES troubleshooting instead (for example).
Alex.