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 Eric:
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:
4C93D717.5090801@tibco.com" type="cite"> 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.
[AM] Yes, we need a set of framing slides. 
4C93D717.5090801@tibco.com" type="cite">
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. 
[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.
4C93D717.5090801@tibco.com" type="cite">
  • 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)
4C93D717.5090801@tibco.com" type="cite">
  • Routing capabilities - especially with mediated messaging systems like JMS
Now, to specific slides:

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?"
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.
[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, no matching.
4C93D717.5090801@tibco.com" type="cite">
  • 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] 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.
4C93D717.5090801@tibco.com" type="cite">
  • 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] 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.
4C93D717.5090801@tibco.com" type="cite">
  • What new policies should we be defining that are specific to eventing?
[AM] Good question!
4C93D717.5090801@tibco.com" type="cite">
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?
4C93D717.5090801@tibco.com" type="cite">
  • 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
4C93D717.5090801@tibco.com" type="cite">
Slide 8:
  • I have no idea what this means.  Can you expand on it?
[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.

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.
4C93D717.5090801@tibco.com" type="cite">

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?
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.
4C93D717.5090801@tibco.com" type="cite">
-Eric.


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
--------------------------------------------------------------------- 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]