Re: [sca-assembly] Fwd: Slides for issue 233

[Peter Niblett <peter_niblett@uk.ibm.com>]

Hi Ashok

Rather than attempting to interleave
responses, here are my comments on some of the questions raised by your
slides.

3. Yes we do need local channels.  Event
orientation is about more than global publish/subscribe, it's about designing
and using components that interface by producing or consuming events.  There
are some situations where the assembler wants to explicitly control who
consumes the events emitted by a given producer (even though the designer
of the producer has no idea where that might be, or what the consumer is
going to do with them). For example I might have a producer which emits
events every time I type in a password  - I would want to control
very carefully where those events go. It's a cleaner design if I can draw
an assembly diagram that shows the events going from my producer to my
permitted consumer(s), than using a domain level channel and relying on
access permissions on that channel being set up correctly. Also suppose
I have a very chatty or error-prone producer, and I wish to inset some
kind of active filter step in to filter/clean the events that it emits
before they go out for general consumption. The natural thing to do is
to put a component in line between the producer and the domain channel
that distributes the events.

To me these two examples also motivate
a requirement for direct wiring of producers to consumers (something I
bring up quite frequently). However the advantage that local channels have
here is that they provide an additional place where you can specify policies.

Do we need channel bindings?  I
see a channel as like a producer/consumer pair, so the answer is yes

4. My starting assumption here is that
a producer/consumer wire acts like a one-way reference/service wire, allowing
us to reuse the same policy mechanisms that exist for references/services.
 Because we don't at the moment permit direct producer->consumer
wiring, I have to go through a channel but that channel behaves like a
consumer and a producer.  Is there something wrong with this assumption?

There is a question here (related to
the issue that Anish has raised), which is whether there could be separate
policies for the consumer part of the channel from the producer part.

5..7 It would be useful to go through
all the policies defined at present (reliability, security, transactions)
to see if they make sense in event scenarios.. also whether there are any
additional ones we need in this (and other areas).  We have a list
of things that Anish may remember from WS-N days - for example the ability
to specify the number of events per second that you can accept.

8. Am I right in thinking this is giving
a producer or consumer the option of saying "don't care" in a
particular policy domain?

Regards

Peter Niblett
IBM Senior Technical Staff Member
Member of the IBM Academy of Technology
+44 1962 815055
+44 7825 657662 (mobile)




From:      
 ashok malhotra <ashok.malhotra@oracle.com>
To:      
 Eric Johnson <eric@tibco.com>
Cc:      
 OASIS SCA Assembly
<sca-assembly@lists.oasis-open.org>
Date:      
 18/09/2010 00:42
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: 
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.  

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.

• 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:  [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.

• 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.

• 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.

• What new policies should we be defining that are specific to eventing?

[AM] Good question!
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?

[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.

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.

-Eric.


On 09/16/2010 05:30 AM, ashok malhotra wrote: 
 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

---

Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU