On Tue, 23 Dec 2003, Krishna Ramadas wrote:
I work for a wireless appliance company and we have been looking at
the drafts produced by this working committee. I am interested in
utilizing the framework created by OPES for implementing distributed
solutions.
First of all, thank you for sharing details about your use case and
asking for our opinions.
We would like HTTP billing records to be collected for HTTP
sessions. We would like the two boxes to exchange billing update
information, based upon HTTP transactions within the session. We
would like to utilize OCP to control the process of record exchange
between the two boxes.
Since you are saying (below) that the process does not involve
exchanging HTTP messages (just metadata about them), OCP is just a
candidate protocol to do the job. It will work, but I would try to
find a better fit before making the final selection.
There is no call-out/dispatcher relationship between the two boxes.
From my interpretation of the use case scenario, I need a
dispatcher/call-out relationship to apply the procedure specified in
the drafts: Is this a true assumption?
The primary purpose of OCP is to exchange application messages and
their meta information between two agents. The callout/dispatcher
relationship is mostly undefined and has little effect on OCP Core
design. Some OCP Core optimizations assume that the processor (agent1)
receives original application data from the previous application hop
and will eventually forward adapted application data to the next
application hop, after/while talking to the callout server (agent2).
It is OK, in principle, for agent2 to be an OPES processor as well. If
no application data is exchanged, then some OCP Core optimizations
will not be used. Thus, you might be able to find a smaller/simpler
than OCP protocol that will do the job.
Will/Can a use case extension be made for solution such as the one
that I have described above? We are trying to use OCP between two
OPES processors.
Interesting! Personally, I think that what you are trying to do should
be within OPES scope, even if the OPES Architecture document is too
rigid to imply that. IMO, any application message adaptation by an
intermediary is within OPES scope (with some use cases being less/more
"interesting" or "trivial" than others).
Again, OCP may or may not be the best protocol to use.
We plan to support in-line tracing, but HTTP adaptation will be
handled independently by the OPES entities (box-1 and box-2) along
the way. The OPES entities will only exchanging control records
related to usage and billing on a per session-transaction basis. The
OPES entities would also, independently, apply Policy
specifications.
Understood.
Can OPC be applied to a situation where traffic adaptation is not
controlled by the OPC protocol, but only the usage records are
exchanged over the OPC protocol?
OCP should work in such an environment but is not designed for it. The
question is whether you would be better off with a different protocol.
Are you looking at OCP simply because it is a part of the OPES
framework, or do you like some of the OCP properties? Have you
considered using other existing or custom-made protocols?
Can OPC be used only to signal sessions and transactions so that
usage records can be associated with them?
Yes, I believe so. You will need to define an OCP profile for that, of
course (just like HTTP Adaptations draft defines a profile for
adapting HTTP messages with OCP).
Please keep us posted on your progress in finding the right protocol
for your needs.
Alex.