Regarding Section 3.5 Support for Keep-Alive Mechanism
"The OPES callout protocol MUST provide an optional keep-alive mechanism
[...]"
Is this really a MUST?
As I understand the section the keep alive mechanism has to belong to
the OPES protocol not to the lower-level transport protocol.
So, a possible implementation would be that the data processor opens a
channel (let's say it is a TCP connection), keeps it open forever and
sends and receives protocol keep alive messages in absence of any real
transaction, so that both data processor and callout server will know
that the other peer is alive.
While this is a great idea and good for a SHOULD requirment, I do not
see why this is a MUST.
From other sections we can learn that we are looking for a real client
server protocol, in which only the data processor establishes the
channel and the callout server MUST be able to handle many different
channels from different data processors and so on.
Since HTTP is a good example for such a protocol in general, the callout
server is like an HTTP server and is typically not really concerned if
some clients fail and do not longer send requests for some time. When
all connections are closed, the server can free its resources.
On the other hand, the data processor is probably very much interested
in knowing that a callout server has a failure even in times when no
transaction has to be handled (in order to start some failover actions).
But for this task the protocol still does not stringently needs the
keep-alive mechanism but could also reuse the must-have parameter
negotiation messages from time to time to check a callout server's
availability.
Martin