From: Eric Johnson [mailto:eric@tibco.com]
Sent: 03 February 2011 17:48
To: Anish Karmarkar
Cc: OASIS Assembly
Subject: Re: [sca-assembly] Private or local channels
Hi Anish, Peter,
On 2/3/11 7:24 AM, Anish Karmarkar wrote:
On 2/1/2011 8:02 AM, Peter Niblett wrote:
I still see a requi!
rement
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.
We're back into really squish security territory. As soon as you open up a network connection, the activity might be "visible" to outside parties. I'm certain that we have to leave it up to implementations of SCA, and the assemblers of composities as to how rigorously they work to prevent exposure to the contents of messages, and likewise, how rigorously they work to prevent "outside" messages from being processed. In the end, it *can* be compromised, the relevant security question is whether it is the weakest link, or not.
Why is it necessary to restrict the visibility to, say, a
monitoring application that wants to provide a console to the admin?
Yes, as Anish points out, the fact that the messages might be visible outside SCA's confines might be a feature of some implementations, not a bug.
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.
I agree with Anish on this - if an SCA runtime uses its own JMS deployment, and we do testing via a domain contribution just contributed, I don't see how it is that some *other* non-SCA application is going to show up and start bombard!
ing the
SCA consumers with unexpected messages. If they do, your network has been compromised, and that probably invalidates the tests anyway.
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 ag!
ree with
this. But I don't want to mandate it.
As I think I've said on the call, that actually seems backwards to me. Binding to an existing JMS Topic seems like something you want to do in a very local manner, where you start migrating an existing application that uses JMS into the SCA world, and you do it piecemeal. You're not likely to want to expose a global domain channel bound to that topic, because that would affect the existing external application.
-Eric.
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 c!
ould 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 othe!
rwise
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