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 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.
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 bombarding 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 agree 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 <>
To: OASIS Assembly <>
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
