Good questions! The purpose of the slides was to seed discussion
and they seem to have
succeeded in that :-) Some responses inline, most will need more
discussion next week.
All the best, Ashok
On 9/17/2010 2:01 PM, Eric Johnson wrote:
[AM] Yes, we need a set of framing slides.
Thanks for preparing the slides.
To move the conversation along somewhat I thought I should raise a
few points, and point out a few areas that I found potentially
confusing, so that we could spend more time at the face to face
dealing with substance, rather than confusion.
[AM] The policy framework attempts to cover both cases by either
allowing the binding to provide the capability or providing the
capability via explicit message policies.
To frame the discussion somewhat, I think it might be useful to
lay out some of the known capabilities of "eventing" systems. To
- Mediated vs. unmediated - JMS, for example, almost always
goes through a server (even if "in process"), whereas some
messaging systems "broadcast" at a lower network layer, and
the message doesn't go through any intermediate software
before arriving at the intended destination. And then there's
the odd possibility of overlaying on top of a point-to-point
communications system like SOAP/HTTP.
- Transport level capabilities and the overlap with message
- For example:
- Message integrity - can be handled by TLS applied to
conduits connecting to a mediating server, or it can be
handled by a signature carried in the message headers/body
- Reliability (at least once, exactly once, at most once) -
can be provided by the "transport" (JMS), or handled by a
retry protocol at the message level (WS-Reliable Messaging)
[AM] Do we want to do Policy matching or does the channel just
inherit the policies of the producer/consumer. It can be argued
that the producer just produces events and sets policies and if you
want the events you follow the producers policies. No negotiation,
Now, to specific slides:
- Routing capabilities - especially with mediated messaging
systems like JMS
Slide 3: [AM] This slide raises some questions about the
eventing model. It does not belong in the Policy slides. It's
just an aide memoire for me.
- In addition to asking about the default domain channel, I
think the question equally applies to *any* global domain
channel. If two separate contributions to an SCA domain set
policies on a global domain channel, what does that mean?
- I'm not sure I understand what you mean by "Do we need local
channels?" - is this a policy question, or an existence
question? If it is a policy question, I don't understand how
it relates to policy.
- I have the same question about your next question "Do we
need channel bindings?"
- You say "Should there [be] policy matching between producer
and channel and between channel and consumer?" I'm not sure I
understand the distinction between this question and the next
[AM] If we do Policy matching, do the matched policies between the
producers+channel have to be the same as the matched policies
between the channel and the consumer. You may think this is a
rhetorical question but I think it needs to be asked.
- The answer to "Should the matched policies be the same..."
- you're making a distinction I don't understand. If the
policies are matched, then how are they not the same? This
may be just my ignorance about policy. In any event, the very
point of decoupling producers and consumers is to separate
these questions. If a producer sends a message in a way that
satisfies "message integrity", then it should be the
consumer's choice to decide whether to check - on the same
network subnet, the consumer might not check. So the more
important question, in my mind, is "how can you tell when
policies set differently on consumers and producers are
compatible, when they don't have to intersect?"
- For example, I could set a non-repudiation intent on a
producer, and that might mean that the producer
independently registers its sent messages with a third party
system, and likewise, a consumer might register its
receipt. Only if they *both* set the property might they
actually coordinate as to which third party system.
[AM] We need to figure out which intents apply and which don't. For
example, you could argue that the transaction intents don't make
sense for events but I think we need to discuss this. The usescases
in the following slides are meant to help us answer this question.
- Your question: "Do all intents that apply to services..."
seems trivial - the answer is "no." The more interesting
question - which policies don't apply? Is there some way that
policy definition distinguishes which ones don't apply?
[AM] Good question!
- What new policies should we be defining that are specific to
- Authentication: presumably you mean that the producer puts
identity information in the message metadata/payload? To
refine slightly, the use-case here is that the consumer wants
to know the identity of the producer. Presumably, if
you have means to assure message integrity, then a token is
- There is a subset of use-cases where you want to know not
only who is issuing the event, but more importantly, who the
request is being issued on behalf of?
- Authorization: If the messaging system is mediated (JMS),
then a producer can be required to authenticate to even send a
message to a particular channel/topic/subject. This is a
producer side authentication, in addition to the consumer side
authentication that you ask about.
- There are two flavors of identity propagation, and I'm
having a hard time teasing them apart on this slide. There's
the identity of the machine that is producing the messages,
and then the producer might be sending messages on behalf of
some other identity. Both might need to be carried. Can we
tease these apart a little more?
- Why disable identity propagation? Are we really looking for
a confidentiality intent here?
- I don't know what you mean by "original identity".
- I'm confused by having a bullet point: "there may not be an
identity" under use cases about identity. How is this
different from disabling identity propagation?
- Security side of my brain flags that "encryption" and
"signing" are proxies for "confidentiality", and "integrity",
respectively, except that some notion of identity is probably
also implied here
[AM] The Policy framework assumes that both services and references
have policies and there is policy matching between them. But there
is another scenario. The reference says I have no preferences, I
will just follow the policy of the service. This happens quite a
lot when you a writing a web client to work with a Web service. The
counterpoint is -- Surely not ANY policy -- The reference needs to
set some limits, however broad, on what it can do. So some policy
negotiation is needed, however rudimentary.
- I have no idea what this means. Can you expand on it?
For eventing, the consumer and producer are disconnected and it does
not seem reasonable that the producer would change it's policies to
match what the consumer wants, so an option should be that the
producer dictates policy and the channel and consumer follow along.
This is not a wacky idea. This kind of broadcast protocol is quite
common. You can get RSS feeds for all kinds of news events, for
example. I can't say if this is in play for SCA but if it is, I
don't see how you can do any policy matching. You just do what the
producer tells you to.
I just had a wacky idea. Suppose my notion is to "broadcast" an
event. What if the way I broadcast it is to shove it into an Atom
feed, and let clients poll for it at their leisure? Obviously,
that doesn't scale to extremely large numbers of messages, but it
certainly could work for a certain level of broadcast. Is this a
use-case we want to support? Does it have any implications?
On 09/16/2010 05:30 AM, ashok malhotra wrote:
4C920DEF.email@example.com" type="cite"> I
prepared some slides to frame a discussion re. Assembly-233.
unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. Follow this link to all your TCs in OASIS at:
See attached. As you will see, this is more about asking the
questions rather than suggesting solutions.
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. Follow this link to all your TCs in OASIS at: