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: Slides for issue 233

Hi Ashok,

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:
  • 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 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 itself.
    • 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
Now, to specific slides:

Slide 3:
  • 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?"
Slide 4:
  • 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 one.
  • 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.
  • 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 eventing?
Slide 5:
  • 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.
Slide 6:
  • 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?
Slide 7:
  • 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.
Slide 8:
  • 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.5000304@oracle.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: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php

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