Hi Ashok,
I guess I see four approaches:
- 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.
- Policy intents/policySets set on producers/consumers/channels
are independent. Each is treated as a separate policy
enforcement point.
- Only allow policy intents/policySets on channels.
- Punt on the problem.
Straw poll - which approach do others favor (ranking them is
probably useful)?
Or, if you don't like the straw poll as stated, then perhaps suggest
additional options/alternate options?
-Eric.
On 9/28/11 5:07 PM, ashok malhotra wrote:
Hi Eric:
There is not going to be a SCA Policy 1.2 and we need to say
something about Policy
on events. My goal was to propose something that we could get
quick agreement on.
Thus, the proposal mirrors Policy processing on Services and
References in the hope
that this would resonate with the TC and we could get quick
agreement.
I'm not opposed to considering alternative/simpler Policy models
for events but I would
like to avoid a protracted discussion.
All the best, Ashok
On 9/27/2011 11:52 AM, Eric Johnson wrote:
Hi
Ashok,
Thanks for taking a first stab at this.
My recollection from the F2F back in 2010 is a little fuzzy, but
doesn't seem to quite line up with what is proposed here. So
either we need a little more detail, or perhaps we explicitly
note what isn't covered.
The trouble as we discussed it back at the F2F, is that use
cases for channels potentially lead one to desire three
enforcement points.
Policies can be enforced "when produced" - for example, an
"integrity" policy results in a message being signed.
Policies can be enforced "by the channel" - for example,
"confidentiality" might be enforced by JMS by way of making the
JMS communications encrypted to/from the JMS server.
Policies can be enforced "when consumed" - for example,
"non-repudiation" policy applied at a consumer might discard all
messages that do not have the signature of a non-repudiation
agent.
Especially when using global domain channels (GDC), the approach
of "everything must match" feels like it will fail for important
use cases. I don't think you want to constrain consumers of a
channel to exactly match the policies of a GDC. For example, a
logging service which works as a partner to an actual service
might listen on a channel for all events, and not care whether
they're encrypted, signed, or using "jms", whereas some business
logic component may care deeply.
Further, there are some intents that the consumer and producer
may not care about, but that get assigned to the channel, such
as "jms", or "SOAP".
Additional challenges - that we discussed back @ the F2F, there
are two or three kinds of pub/sub systems:
- hub-and-spoke
- broadcast
- point-to-point (if you want to count that)
How you think about policies may vary amongst these different
approaches.
Further, when you throw bindings into the mix, presumably one of
the points for doing so is to expose the "channel" to the
outside world for connectivity to existing systems. The moment
you do that, you no longer control how messages are being
produced. And if you're binding to something like a broadcast
system (TIBCO's Rendevous, or FTL), then there's no enforcement
at the channel either - your only enforcement point is upon
receipt.
It feels like we have two approaches we can take:
- disallow intents on consumers & producers
- Well, if that's too harsh, you allow them, but they're
only advisory, resulting in alerts at deployment.
- Allow intents on consumers, producers, and channels to be
independent of one another.
- Completely punt on what policies mean.
(For Car
Talk fans, that last entry is the third half of the list)
If nothing else, I wanted to write up the above to materialize
what I recollect of our discussions from way back when.
Comments?
-Eric.
On 9/27/11 7:23 PM, ashok malhotra wrote:
The attached file contains
wording for Assembly-233 in the form of a new section to
be added to the SCA Assembly 1.2 spec close to where
Producers, Consumers and Channels are discussed.
All the best, Ashok
---------------------------------------------------------------------
To unsubscribe, e-mail: sca-assembly-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: sca-assembly-help@lists.oasis-open.org
|