On 21:29 24/02/03, Alex Rousskov said:
On Sun, 23 Feb 2003, jfcm wrote:
> How do we zap and abort the transactions?
I assume you are talking about the situation where user request must
stop at the OPES processor or the callout server due to
rules/policies/etc.
No. The question was about parallel command pipe or not.
My response was to try to see if we can have a consistent
response. Obviously triggering a command should probably
go the same way as aborting it.
The idea of a piped protocol being accepted, you must
zap the pipe if you want to abort. This means a priority
somewhere in the processus. Either in the pipe with a
zapper swallowing the data. Or a prioritized command
pipe ordering to clear the four buffers.
Then there is the message telling the server to abort and
and ack to the requester.
The predraft document describes how a callout server can abort an
application transaction. The technique is based on changing the source
and destination addresses: the source address becomes the address of
the callout server. The destination address becomes the address of the
application client (it has to even point to the same application
connection if application protocol requires that). When OPES processor
receives a <message-start> OPES message with such addresses, it would
start responding to the original client request instead of forwarding
the request to the server.
I am not sure I grasp all the implications in all the cases.
I need to make a .. model. And fully understand. The
real problem is also that I do not always figure out what
can be the osurce, the destination the processor, the
server, the client, the producer :-)
As you know, Hilarie Orman (and probably others), objected to giving
callout servers ability to change source and destination addresses.
This objection would need to be resolved by either convincing
opponents that there are no good reasons to prohibit such a change OR
adding new OCP mechanisms to allow callout servers to tell OPES
processor:
"you expected me to modify the request to be forwarded, but I
am telling you to abort forwarding and respond with the
following message instead"
This is to abord forwarding. I was talking about command pipe,
hence abordting the service, not necessarilythe forwarding. This
is another option to add.
Note that in the current proposal, the semantics is somewhat different
(abort is not an exceptional condition in the predraft):
"you expected me to modify the application message; here is
a modified version; forward it [back to the client]"
idem? However simpler.
The real issue is that at minimum there are four flows
involved user/dispatcher/service/dispatcher/organizer in my own words
instead of one. Following all the possiblities calls for an
Excell spreadshit.
jfc