RE: OPES protocol, pre-draft 01

On Tue, 25 Feb 2003, Oskar Batuner wrote:

> > > In the architecture draft we are always separating OPES flow from
> > > the metadata exchange. We state that metadata transfers are
> > > out-of-scope for the OPES architecture. Of cause this statement does
> > > not preclude using the same callout protocol - or any other - for
> > > the metadata transfer. But if we permit mixing OPES data and
> > > metadata (like preferences, etc.) on the same channel - well, this
> > > looks at least inconsistent.
> > I understand the intent -- keep OPES focused and small. Is there a
> > precise definition of "metadata" or "OPES flow" though? For example,
> > most will probably agree that service ID(s) should be attached to
> > <xaction-start> messages, but many will consider a service ID to be
> > METAdata because the application protocol does not carry those.
> >
> > Another example: transferring a static set of preferences and rules
> > should probably be out of OPES protocol scope. On the other hand,
> > sending transaction-specific rules that affect, say, service
> > application order may be in OPES scope. Same for specific user
> > preferences and/or credentials? It seems to me that metadata specific
> > to application transaction may be in scope and may be transmitted
> > in-band.
> Yes, these is why I'm asking this question. We may go both ways. In
> many cases it may be very natural to transfer in-band metadata
> related to the current processing context. But as soon as you allow
> in-band metadata transfer you may not set a clear border - what is
> specific to the transaction and what is not. If we are allowed to
> send user preferences when message to/from that user is processed -
> why not send to remember these preferences on callout processor? And
> if callout processor keeps user's data - why not to send it them
> just once, in advance?
We probably should not make all these choices because they are
application or even environment dependent. For example, if I have a
user population of 10,000 users but only 10 users can be active at a
time, it may not make sense to upload the entire user database to the
callout server, especially if the callout server [location] changes
with time. Some metadata transfers will always be out of OPES scope.
We should require support for only universally needed metathings (like
service IDs).

> Real decision is either yes (allow metadata transfer in-band) or no.
> Metadata transfer in a limited context is not a consistent
> architectural decision: all related protection measures mandated by
> the architecture MUST be implemented, but if they are - why to limit
> the context?
Exactly! IMO, there is no way we can avoid documenting/requiring
in-bound transmission of things other than application message octets.
The examples above illustrate that. Thus, metadata transfers must be
allowed (as a general architecture-level rule).

However, we should document/require metadata transmission on as-needed
basis. If later we notice a certain common pattern, then we may add a
general metadata transmission message/support to the protocol.
Otherwise, protocol extensions can be used for metadata transmissions
that we did not need or could not predict. Either way, it is OK to
violate the OPES architecture draft as long as our violations are
conscious and necessary. The architecture draft can be fixed later if
needed.


The original question was about requiring support for special
"control" channels. Those channels can be used for out-of-flow
transmission of "emergency" messages such as an abnormal transaction
end message. The same channel may [optionally] be used for metadata
transmissions, possibly unrelated to specific transactions. However,
since we do not have any specific need for such metadata transmissions,
I would not care about them for now. Perhaps those transmissions will
need their own channels; we will see.

For now, it seems like we should add support for emergency (priority)
channels (additional transport connections) as an optional
optimization feature. I will make a corresponding proposal and will
try to generalize the idea so that an OPES server can instruct callout
server to give certain transport connections a priority, to support
QoS features (e.g., application messages from Gold Members should be
processed before all other application messages).


Thank you,

Alex.