Re: [sca-assembly] Fwd: Suggested text for Assembly 233

[Eric Johnson <eric@tibco.com>]

Hi Ashok,

On 9/29/11 12:06 AM, ashok malhotra wrote:

Eric, some questions inline

All the best, Ashok

On 9/28/2011 12:22 PM, Eric Johnson wrote:

Hi Ashok,

I guess I see four approaches:

1. All policy intents/policySets specified on producers/consumers/channels must match precisely. Well, maybe I'm oversimplifying it, but this seems to be the approach indicated by your email.
   
2. Policy intents/policySets set on producers/consumers/channels are independent. Each is treated as a separate policy enforcement point.

I don't understand this.  If the producer says Confidentiality and the Channel says NoConfidentiality
what happens?  Can the producer connect to that channel?

Why, sure, it can connect. Just that none of its messages will get through. You and I happen to believe that these two policy intents - based on their names - are contradictory, but asking a runtime to figure that out and prevent deployment might be quite tricky. That is, "intentFoo", and "intentBar" may or may not have any relationship to each other, and the only way you can actually find that out is by inspecting the actual policySets that satisfy those intents. And even upon inspection, it may still be opaque to a runtime.

1. Only allow policy intents/policySets on channels.

I considered this.  I think it's quite reasonable for the consumer to just use the Channel's policies.
But producers are autonomous and I think they will set policies without consideration of what channels
they are going to be connected to.  Perhaps you need to explain this a bit more.

OK, that's a useful discussion point upon which we agree. Producers must be able to assert policies that don't match the channel(s) they connect to. For example, if I have a "jms" policy on a channel, I shouldn't need or want to put that on a producer.

1. Punt on the problem.

I think we need to say something.  I'm happy to say as little as possible.

Well, sure. I was just thinking we'd say nothing normative.

Maybe we should have this conversation the other way around. What existing defined policy intents and policy sets do people actually think they want to apply to pub-sub situations? What do they hope those policies will acheive? And then maybe we can look at what should be in the model?

(hmmm - at the moment, OASIS is not responding, so I'm working from an older copy of the policy spec)

For example, of the following intents: serverAuthentication, clientAuthentication, authentication, mutualAuthentication, confidentiality, integrity, there are possibly only two that apply for pub-sub - namely "confidentiality", and "integrity". Both matter to the producer, but may be incidental or irrelevant to the consumer and the channel.

However, I can imagine a new intent, perhaps called "credential.token", or "SAML" that might be interesting to apply at a producer, to ensure that something like a SAML token gets applied to the outgoing message. That's tricky, though, insofar as actually determining the SAML token might be difficult to separate from business logic.

Reliability intents seem to make no sense. Likewise, transactions.

The miscellaneous intents of Chapter 10 don't seem all that important, although "JMS" & "EJB" might be useful to apply to a channel.

Anyone with *specifics* of how they think intents & policySets should be used, that they're willing to discuss? Otherwise, I vote the "punt" option.

-Eric.