On Mon, 24 Feb 2003, Oskar Batuner wrote:
Here I'm looking at transaction boundaries that are defined by
<xaction-start> and <xaction-end>. You are right that in general
it is not necessary to limit the right to terminate transactions to
the server. But in the OPES case
... processing is initiated by incoming
OPES processor messages (from producer or from consumer) ...
In such context OPES server has no apparent reason to terminate
message processing - there are no possible events associated with
this transaction coming from the OPES flow. After initial message is
received and service is initiated only service application (in this
case callout server) knows that transaction processing is finished.
At least for the normal processing. There may be abnormal situations
(e.g. OPES data consumer has closed the connection) when OPES
processor becomes not interested in processing results and may wish
to stop request processing to avoid resource wasting.
Maybe we should have a special message for abnormal transaction
termination?
Abnormal termination is exactly what motivated me to allow
<xaction-end> messages to be sent by OPES processor. We could have a
special <xaction-abnormal-end> message, but
- the recipient (callout server) most likely does not
really care why the transaction is suddenly ended; the
reason field can be used for detailed logging/debugging
if desired
- the reason field(s) can already be used to indicate
the kind of termination through application-specific
status codes (normal, client errors, internal errors,
overload, etc.)
- there might be application protocols where "normal"
termination can be detected by OPES processor;
the notion of "normal termination" is, after all,
application [protocol] specific.
Overall, a more general <xaction-end> message seems to cause no
problems while having possibly desirable side-effects. Any objections?
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.
Alex.