Re: [sca-assembly] Private or local channels

[Anish Karmarkar <Anish.Karmarkar@oracle.com>]

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