On Tue, 1 Jul 2003, Martin Stecher wrote:
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 look like?
It could be the same as service "negotiation" now. For services
that imply a particular set of parts, the service ID is
sufficient. For other services, the part names will be listed as
service parameters, just like they are listed as profile
parameters now.
OCP does not have a mechanism to negotiate services, but one can
reject a Transaction Start (TS) or Create Service Group (SGC)
message by closing the transaction or connection.
I am confused.
This seems that the processor has knowledge about the services'
needs. I knows that some services imply a particular set of parts
and that other services take those parts as parameters (maybe not
accepting these by closing transaction or connection).
If the processor knows already the details about needed parts it
definitely knows also the profile that the service prefers.
Yes. Parts are defined in the profile. One cannot know what parts are
without the profile. The reverse is not necessarily true: it is
possible to have a profile that does not define the exact set of
required parts, only the set of possible parts, leaving the final
choice up to the services/agents.
What sense do NO/NR message negotiation for profiles have then?
Indeed. If X is known a priory, there is no need to negotiate X! The
primary reason to have profile negotiation is to accommodate situations
when the processor or the callout server support more than one
profile. In that case, they have to agree on one profile to use. For
example, a processor may support HTTP and MIME profiles while the
server supports only MIME. They have to negotiate to find out.
The secondary reason for negotiation is to confirm assumptions. For
example, the processor may be configured to use HTTP profile and may
be told (also via a configuration file) that the callout server
supports HTTP profile. It may make sense to negotiate HTTP profile
anyway just to make sure that configuration [still] works before
exchanging any messages. This is simply to ease maintenance and
debugging.
My "services that imply a particular set of parts" phrase is
misleading because while a service may imply parts, the processor may
not be aware of that implication and may have to negotiate it. Like
you say below, the processor may only be given an opaque service ID.
I think that the OPES processor only has the service IDs that it
shall apply at a given execution point. The technical negotatiation
what and how data will be exchanged with the callout server for that
service should be done within OCP.
This is a typical scenario, yes.
I think that NO/NR negotiation for profiles plus wanted meta data is
good for that but it needs to be done per service. All what we need
is an optional service parameter for NO messages.
Let's assume that "application profile" defines OCP extensions,
including a set of valid message parts and data encodings.
Are you saying that an application profile (e.g., HTTP) should be
per-service rather than per-connection? If so, it would be difficult
to introduce profile-specific OCP messages outside of the OCP
transaction boundary (because outside of a transaction, the "current"
service is not known).
Which combination of options do you prefer:
1) Application profile is negotiated for connection
2) Application profile is negotiated for transaction
x
a) Exchanged message parts are negotiated for connection
b) Exchanged message parts are negotiated for transaction
Transaction above is synonymous with "service" or "service group". If
we select (1b) or (2b), we would need to adjust the specs so that
negotiations can be tied to a transaction/service.
(1a) does not allow for service-dependent parts
(2a) is not a valid combination
(1b) is my preference
(2b) makes OCP extensions that do not depend on a service difficult
Do you prefer (1b)?
Thanks,
Alex.