Re: [sca-assembly] Private or local channels

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

Hi Anish

I can see that an implementation might
want to add extra capabilities to a channel and this could include the
monitoring function that you mention, so yes we shouldn't forbid this.
It's the ingress of events that worries me more.

You say you agree that events sent to
a "private channel"  shouldn't be visible to SCA components
outside that composite.. but if one accepts that private channels can produce
events that came from outside the SCA assembly, then you can get precisely
this happening.  Suppose I have two composites, each with their own
private channel.. if they happen to bound to the same JMS topic (or two
topics that appear to be different but in fact are wired together by the
JMS provider) then events published and either composite are going to show
up in the other.  This was what made me feel uncomfortable, as it
seems to undermine the idea of encapsulation that I thought composites
were supposed to provide. I also think there's some value in having an
assembly model that prescribes the event flows that can occur, so that
someone can reason with an instance of the model and use it to build operational
monitoring, as well as making deployment and other optimizations. If there
are other flows going on that aren't explicitly deducible from the model
then that isn't going to be possible.

My "testing" concern was based
on the idea that the two composites I mentioned were from different vendors,
and were being treated as black boxes by the person assembling them to
make the higher level composite.
In a separate thread, Mike Edwards has
suggested that the author of each low level composite can avoid this by
not binding the private channels to a JMS topic - indeed if the author
is a third party making a reusable component, they won't know the user's
JMS topic structure anyway (and to support this we would have to introduce
a topic indirection like there is in JEE). So maybe there isn't a real
issue here, except for the name "private channel". I guess I
could live with calling it a "local channel" and having private
channels being a special use case, where you don't bind it to anything
external.

However, I am still a bit puzzled as
to why you would want to bind one of these local channels in the first
place, given that there other ways of doing it and it would seem better
to me to specify bindings to external sources or events at the exterior
of a black box composite rather than inside it .  You say that my
option 2 "binding a producer or a consumer to a JMS Topic" is
not permitted by the current draft. Where does it say this? I searched
the new clean draft for occurrences of jms, and didn't find any restriction
on the use of JMS bindings on producers or consumers.

By the way, my search showed me we still
have a reference to multiple bindings on a channel and the use of a URI
to disambiguate them - see line 3875

Regards

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




From:      
 Anish Karmarkar <Anish.Karmarkar@oracle.com>
To:      
 OASIS Assembly <sca-assembly@lists.oasis-open.org>
Date:      
 03/02/2011 15:26
Subject:    
   Re: [sca-assembly]
Private or local channels

---

On 2/1/2011 8:02 AM, Peter Niblett wrote:
> I still see a requirement for scoping the exchange of events so that
it
> stays encapsulated within a composite.

I agree that the events cannot be visible to *SCA* components outside 
that composite, in that SCA domain. But I think our disagreement is wrt
visibility to non-SCA things.
Why is it necessary to restrict the visibility to, say, a monitoring 
application that wants to provide a console to the admin?

> It has hard to develop and test
> such a composite if there's a risk that its internal components can
get
> bombarded with events from who knows where once it is deployed. That
was
> my understanding for why we had private channels in the first place.
>

I don't see why this is hard to develop or test.
It is still under your control as to who gets visibility. Either because
you are in control of deployment of even non-SCA things or through the
use of some security mechanism.
WRT testing, why would you care who else sees the events, or even who 
else sends additional events. I would think that for our testing we 
would just have to make sure that all events that were sent by SCA 
components are delivered to all the consumers with the 'right' 
filters/connections.

> There are other ways in which you can reference a genuine external
JMS
> topic
>
> 1. Reference a global channel bound to the JMS topic (global channels
> seem a much better fit for something that is external to the whole
> assembly)

I tend to agree with this. But I don't want to mandate it.

> 2. Bind the producer or consumer directly to the JMS topic

We don't allow that in the current draft.

> 3. Promote the producer or consumer to the composite level, and bind
> that to the JMS topic.
>

We don't allow that in the current draft, but of course this is another
issue that has been filed.

> Of course I could get the functionality I want from private channels
in
> another way if I were allowed to wire producers directly to consumers.
>
> Peter Niblett
> IBM Senior Technical Staff Member
> Member of the IBM Academy of Technology
> +44 1962 815055
> +44 7825 657662 (mobile)
>
>
>
>
> From: Anish Karmarkar <Anish.Karmarkar@oracle.com>
> To: OASIS Assembly <sca-assembly@lists.oasis-open.org>
> Date: 01/02/2011 15:02
> Subject: [sca-assembly] Private or local channels
> ------------------------------------------------------------------------
>
>
>
> During last week's call Peter and I had a little bit of back on forth
in
> the chat regarding private/local channels. I would like to start a
> discussion on it on the ML before I file an issue (or not, depending
on
> the outcome of the discussion).
>
> Peter has pointed out that line 2815 of our spec says:
>
> "Channels within a composite used as an implementation are private
to
> the components within that composite. These private channels can only
be
> the targets for producers existing within the same composite as the
> channel. Private channels can only be sources for consumers existing
> withing the same composite as the channel. An SCA runtime MAY support
> the use of private channels "
>
> Peter's interpretation of this is that composite channels are not
> visible to components outside the composite *and* to anyone outside
of
> the SCA-world. I have a different interpretation of this. I don't
think
> our spec should talk about what things outside of SCA do or don't
do. We
> should allow for enough freedom wrt the technology use to implement
the
> channels. It could be an in-memory channel that is true invisible
to
> anyone outside the process or a JMS topic, which would have visibility
> outside of SCA. We currently allow bindings on a composite channel;
that
> to me indicates that we intended to allow such variability. If folks
> agree with my interpretation, I think we should change the wordings
to
> replace 'private' with 'local', so as not the give an incorrect impression.
>
> Comments?
>
> -Anish
> --
>
> ---------------------------------------------------------------------
> 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/
>
>
>
>
>
>

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