I feel like the current design is too rigid. You are saying
that it is common for one callout server to support multiple HTTP
adaptations services. And different adaptation services require
different messages or message parts to be exchanged via OCP. Our
current design ties message parts that can be exchanged to one of the
two HTTP profiles. Thus, with the current scheme the only way to
support multiple services that require different parts is to have at
least one OCP connection for each service.
I had no problem if distinct connections per service worked.
But if at the beginning of a connection a NO message offers alternatives, the
callout server does not know which services will be selected later on and so
cannot make a decision.
A possible solution would be to have a single HTTP profile
(that defines what HTTP message parts _can_ be exchanged) and
separately negotiate what services need what parts. Often a service ID
would define the list of parts and no extra negotiation would be
required. Would that work better from your point of view?
That could work. Can you make a suggestion how this separate negotiation will
On Mon, 30 Jun 2003, Martin Stecher wrote:
If a callout server supports different services, for example URL
blocking and virus checking and if it allows the OPES processor to
select the service(s) for the OCP transactions, then it also needs
exchange this information in the profile negotiation.
For URL blocking the server is interested in the
http://iana.org/opes/ocp/HTTP/request profile and for virus checking
it will select the http://iana.org/opes/ocp/HTTP/response profile.
That implies that the NO message needs a services or sg-id
parameter, I think.
What do you think?