Subject: RE: NO messages

From: "Martin Stecher" <[email-masked]>
Date: Wed, 2 Jul 2003 11:23:16 +0200

> 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

---

From: Alex Rousskov <[email-masked]>
Date: Wed, 2 Jul 2003 09:39:31 -0600 (MDT)

On Wed, 2 Jul 2003, Martin Stecher wrote:

> 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.

OK. This probably depends on the processor implementation and how it
is integrated with the proxy.

> 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.
>

Example #2 is how some web services work today, I guess. So it may be
wise to support it. OPES adaptation is, by some definitions, a web
service.

> Actually service groups are created and destroyed outside of
> transactions and a single service ID can exist at any time.

I know, that is why I mentioned that some modifications to the
current negotiation and scoping mechanism would be required to tie
profiles and services.

> 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:

There are two ways to support what you want: better profile scope
management (your proposal above) and profile variables (similar to
current service group variables). The scope approach means that you
cannot have two concurrent transactions on the same connection using
different profiles (or, at least, it would look awkward if
SwitchProfile applies to the immediate TS only). The variable approach
allows for concurrent transactions with different profiles at the
increased risk of leaking variables and creating a DoS (allocating and
not destroying "a lot of" variables as a result of a bug or on
purpose).

I suggest that we use the "variable" approach:

	P: NO ( service-feature1, service-feature2, ... );
	S: NR service-feature2;
	P: TS 1 service-group-id2;

Where "service-feature" is the following structure:

	{ service-group-id service profile }

Where "service-group-id" is an "sg-id:" UNI that can be used in TS
messages if negotiation is successful. "Service" and "profile" are
structures describing callout service and profile information (they
are already defined in OCP).

If you accept the above, I would also suggest that sg-id parameter of
the Transaction Start (TS) message is made mandatory. This will allow
agents to negotiate acceptable services before they are used in any
transaction.

As you can see, both proposals are similar. The only big difference is
that the variable approach lacks the SwitchProfile message.

Note that the variable approach does not allow to select a particular
profile outside of the transaction scope. However, since OCP Core
requires that unknown messages are ignored, it is still possible to
customize exchange outside of transaction boundaries without losing
interoperability.

Will this approach work well, in your opinion?

Alex.