On Thu, 10 Apr 2003, The Purple Streak, Hilarie Orman wrote:
Maybe I misunderstood the purpose of app-messages, but I don't see
how to use the app-message-* directives to allow more than one
"response" from the callout server.
This is achieved by responding with several all-message-start
messages, all with distinct am-ids.
The OPES processor does app-message-start
for am-id, X, then some data, then app-message-end am-id=X,
yes
and the callout server will respond with app-message-start am-id=X
no, am-id=y1
and sometime later app-message-end am-id=X.
no, app-message-end xid am-id=y1
In addition to that, it can respond with more (at _any_ time after
receiving app-message-start am-id=x):
app-message-start xid am-id=y2
app-message-start xid am-id=y3
...
app-message-start xid am-id=y4
...
app-message-end xid am-id=y3
app-message-end xid am-id=y2
...
app-message-end xid am-id=y4
or whatever (interleaved in any way). It is important that there is no
[documented] relation between original and adapted flows. Usually, the
original application message is adapted according to requested
services, but other things might happen as well (errors, service ID
expansion, or whatever).
How can the callout server send another version of the data it
received from the OPES processor and relate it to am-id=X?
It does not need to relate to am-id=x because that is what transaction
ID (xid) is for. By definition, OCP transactions encapsulate
processing of the original application message (am-id=x). Technically,
we do not even need am-id parameter for original data flow.
Does this clarify?
Also, look at the new "adapted flow" figure in the draft (and related
figures). It also shows how multiple adapted application messages
within one transaction are possible. Can the figure be improved to
make the above more apparent?
Thanks,
Alex.