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.
To frame the discussion somewhat, I think it might be useful to lay
out some of the known capabilities of "eventing" systems. To wit:
Now, to specific slides:
- 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
- Transport level capabilities and the overlap with message
level capabilities. 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)
- Routing capabilities - especially with mediated messaging
systems like JMS
- 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
- 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
- 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
- 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.
- 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?
- 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 unnecessary.
- 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.
- I have no idea what this means. Can you expand on it?
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.
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: