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
|