Alex,
Fully agree with you.
Airline example is the example that we should use. I think we should define
the OPES system in that fashion where there is only one accountable system .
Abbie
-----Original Message-----
From: Alex Rousskov [mailto:rousskov(_at_)measurement-factory(_dot_)com]
Sent: Wednesday, August 13, 2003 4:45 PM
To: OPES Group
Subject: Re: [end points comm] OPES System
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.