OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

sca-assembly message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: ISSUE 26: SCA Composite Visibility



Folks,

I'd like to propose that we close this issue with "no action".

Let me explain my view.

This issue raises the question that SCA cannot enforce visibility constraints implied
by Composites.

I believe that SCA can and does do so in its own terms.  What SCA composite
visibility implies is that there is no way within the SCA language to gain access to
entities outside a composite.  This is simply true.

The sorts of things that are mentioned in the text of the issue as breaking this visibility
rule involve stepping out of SCA

- ie if an SCA service is made available via a web services binding (say), then it is available
on some Web servces endpoint (say http://foo.com/bar....).  Clearly, if that is referenced
directly, then it "breaks the visibility rules".  But to do so requires stepping outside SCA to
deliberately use some non-SCA technology.  (This is a bit like stepping from Java to native
code to access some "real" memory address - Java outlaws it, but ingenious means have
been devised to get around this for useful cases like direct byte buffers....)

- a different point was about the ability of some Java Component A to reach some Java
Component B through Java means.  I think that:

a) accessing the code library says nothing about accessing a service instance - the service
instance is running on some endpoint. I have no idea how some piece of Java code could
work this out on its own, unless it knows how the SCA runtime works (and even then access
may not be possible)

b) there is nothing that guarantees that it will work.  Consider a Java SCA runtime implemented
using OSGi.  Unless there is some specific instruction that the code bundle of A can use the code
bundle of B, the OSGi classloading mechanics won't let the access take place.


In reality an SCA runtime can CHOOSE to implement as much isolation as it desires.  Through a
variety of means, including the use of Security techniques, if necessary.  Whether it is a good idea
to do this depends on the kind of runtime and the need for strict isolation.

SCA gives the runtime the freedom to impose isolation, but does not require it to do so.


Yours,  Mike.

Strategist - Emerging Technologies, SCA & SDO.
Co Chair OASIS SCA Assembly TC.
IBM Hursley Park, Mail Point 146, Winchester, SO21 2JN, Great Britain.
Phone & FAX: +44-1962-818014    Mobile: +44-7802-467431  
Email:  mike_edwards@uk.ibm.com






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








[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]