OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

sca-assembly message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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


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:
  1. disallow intents on consumers & producers
    1. Well, if that's too harsh, you allow them, but they're only advisory, resulting in alerts at deployment.
  2. Allow intents on consumers, producers, and channels to be independent of one another.
  3. 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


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]