On Sat, 22 Feb 2003, Oskar Batuner wrote:
Here are some comments:
0. Introduction
draft-ietf-opes-protocol-reqs-03.txt defines the following
information flow:
data provider --(original application message)-->
-- [ OPES magic ] -->
--(produced application messages)--> data consumers
I think both protocol requirements and architecture support OPES
processing in bi-directional message flow, both for data consumer
requests and data producer responses. This means that this diagram
and subsequent association of incoming message with the data
producer and outgoing message with the data consumer should be
changed to reflect the bi-directional nature of the OPES flow.
Oskar,
You are right. I apparently misinterpreted the
"consumer/producer" terminology in the architecture draft.
Fortunately, the protocol itself requires no serious
adjustments because there are still application transactions, and
there are still application messages that belong to those
transactions. A couple of OPES messages names and definitions should
be changed to bring them in sync with the architecture terminology,
but these are cosmetic changes.
In other words, the proposed protocol does not depend on how
many application messages there are per application transaction or on
their "direction". Draft-01 implies there are usually at least two
application messages per application transaction (original and
produced). Draft-02 will remove that implication and will use
appropriate producer/consumer terminology from the architecture
draft..
OPES processor and callout server exchange messages. The
exchange is bi-directional. There is no clear client or
server role. There is no clear request/response message
category either.
I do not agree with that. Per OPES architecture processing is
initiating by rules that are triggered by some event in the OPES
flow (arrival of request or response). As a result of some rule
evaluation OPES processor can make a request to OPES application
(either in the same box or a callout server).
I agree with that :-).
This creates a clear client-server roles: OPES processor makes a
request and callout server produces response.
While I think this is not the only possible terminology (it may not be
enough to originate a transaction to be called a client), I do not
want to argue about this and will try to change the Introduction
wording according to your preferences. This terminology disagreement
does not change the protocol.
My original reasoning was to avoid "client" and "server" terms because
OPES processor and callout server exchange many messages in the
context of a single application transaction and those messages are not
pure request/response sequences. But we can still call OPES processor
a client; not a big deal.
OPES callout protocol should reflect these roles. Each transaction
is initiated by the client (OPES processor) and executed by the
server (callout server). There are certain message types that are
produced by the client and other (different) types produced by the
server. Protocol state transitions also should clearly reflect these
roles.
I agree with that. Keep-alive and maintenance messages may be
originated at the server, but this is minor. OPES transactions are
initiated by OPES processor and executed by the callout server.
For example each transaction starts from <xaction-start> message
from the transaction client
Yes.
and is terminated by <xaction-end> from the transaction server.
This restriction is unnecessary and cannot be derived from the
client-server model. It is perfectly normal for a client-server
protocol to allow either side to terminate the transaction. Usually,
the transaction will be terminated once one party signals the "end"
and the other side receives that signal. In some protocols (e.g.,
SSL/TLS) the end of a transaction is a much more complex event.
In OPES context, the client (OPES processor), may terminate the
transaction by sending a <xaction-end> message to the callout server.
The callout server might send that message first (probably only under
unusual conditions like overload). The two sides might even send
<xaction-end> concurrently!
Also, please note that OPES protocol has to deal with three kinds of
"end" messages:
- end-of-data from the data source
(does not imply that the work on the application message is
done)
- end-of-work for the application message
(implies end-of-data but does not imply that the work on the
application transaction is done)
- end-of-work for the application transaction
(implies end-of-data and end-of-message)
For the OPES architecture when processing is initiated by incoming
OPES processor messages (from producer or from consumer) OPES
processor is always a client. These roles may be different only for
metadata requests (e.g. callout server requests about consumer or
provider preferences). But again each transaction has client and
server.
I understand your desire to call OPES processor a client and callout
server a server in the context of an OPES transaction. I will adjust
predraft wording accordingly.
The question is: do we allow such requests in-band?
If I understand the question correctly, this is purely an OPES
connection management issue. We can, for example, mark some
connections "for management messages only" by sending a special
message on that connection once the connection is open by the OPES
processor. Does anybody have a preference/recommendation? Should
transaction-independent messages be isolated to their own OPES
transport connections? If yes, should this be a MAY for OPES processor
to decide or a MUST that all processors will follow?
My suggestion is that it make it a MAY. I do not see a reason to
mandate presence of control-only (out-of-band) connections, but I can
see a reason to have such connections for priority message handling.
Thank you,
Alex.