I may have found a simple and even elegant solution to the current
mess with the "application message" definition and related issues. The
clue was already in the draft but was disguised by poor presentation.
Your comments and questions helped to factor it out.
I will be making specific changes to the draft, but I want to share
the outline with the list, to give early comments/objections a
chance to be reflected in the next draft release. Here is the outline.
0. The core of the problem is in overloading of
the term "application". The solution is in
specifying exactly which "application" we are
talking about and specifying the relationships
between different "application" terms.
1. The are three applications in OPES/OCP environment
(see diagram at the bottom of this message):
- "input application" is specified by the
application protocol that OPES processor
is using to communicate with the previous
application hop ("processor input")
- "output application" is specified by the
application protocol that OPES processor
is using to communicate with the next
application hop ("processor output")
- "OCP application" is specified by the
application protocol that is negotiated
between OPES processor and the callout
server (they may support several protocols
and will have to pick one to use).
Usually, input application is the same as output
application. Often, input application is the same as
OCP application.
2. OCP is concerned with OCP application messages only. OCP
agents MUST obey OCP application requirements when
exchanging OCP application messages (embedded in OCP
messages). OCP places no restrictions on processor input or
output and has no requirements concerning the relationship
between OCP application messages and processor input or
output. Such restrictions and requirements may exist for
OPES processors, but are outside of OCP scope.
3. Meta-data may be used by OCP agents to relay information
about input and output applications, including information
about connections and message boundaries.
In other words, let OPES processor worry about its application input
and output. OPES processor negotiates with the callout server what OCP
application they should use and then handles necessary conversions, if
any. Naturally, the processor should not negotiate OCP applications
that it cannot convert input application to or output application from.
OCP application could be HTTP. Or it could be something like
"transfer-encoded HTTP message body with content-type and
transfer-encoding passed via meta-data". Etc...
Comments?
Thanks,
Alex.
previous application hop
------------------------
|
(processor input)
|
V
+---------+ +-------+
| OPES | <== (OCP application) ==> |callout|
|processor| |server |
+---------+ +-------+
|
(processor output)
|
V
--------------------
next application hop
legend:
=== communications using OCP
--- communications using other application protocols