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)?
(1b) makes much sense in many scenarios.
Let me describe a scenario that might be typical.
But I also have an example where it does not work. It will not be the normal
case, so please have a look whether support of that example is important.
0. My previous example of an earlier message was not so good. An OPES processor
will usually not offer HTTP/reqzest and HTTP/response profile at the same time.
Makes not much sense on a certain decision point.
1. A typical example would be a callout server with two services that work on
HTTP-responses. Service-1 needs the original HTTP request as meta data,
Service-2 does not. Selecting HTTP profile for the connection and needed
message parts for the transaction (combination 1b) works well here.
2. A not-so-typical example would be a callout server that works as a wrapping
engine and home for other 3rd party service plugins. That means that the
services are very different and support different OCP extensions (profiles).
Without knowing which service(s) will be selected within a connection, the
server cannot select the correct profile for the connection.
If example 2 is not important, we can choose combination (1b).
Else we may need to change something and I would start here:
Transaction above is synonymous with "service" or "service group"
Actually service groups are created and destroyed outside of transactions and a
single service ID can exist at any time.
Currently, playing a NO/NR dialog implies that the selected profile in the NR
message is selected and available featuer set switches (from OCP core to
selected OCP extension).
If we change this in a way that the agents negotiate the profile for a service
or service group (outside of a transaction) without switching to that profile
at the same time?
For example:
P: NO ({profile1},{profile1 featureX},{profile2})
Service: serviceA;
S: NR {profile2};
P: NO ({profile1},{profile1 featureX},{profile2})
Service: serviceB;
S: NR {profile1 featureX};
P: NO ({profile1},{profile1 featureX},{profile2})
Service-Group: 42;
S: NR {profile1 featureX};
P: SwitchProfile {profile1 featureX};
P: TS 1 42; // start with transaction for service group 42
How do you think about that?
Martin