Re: [sca-assembly] ISSUE 26: SCA Composite Visibility

[David Booz <booz@us.ibm.com>]

Mark,

I have one clarification question.  Can you expand on what you mean by
library encapsulation as referred to here:

> Java provides class and library encapsulation. From what I can
> tell, SCA Java does not directly use library encapsulation so it
> must implement SCA composite visibility with class encapsulation.
> This means that SCA Java must implement nested composite visibility
> over the top of a flat Java class encapsulation model. The result
> is that when an SCA composite is used directly from Java it appears
> as a flat composition of Java classes rather than a nested
> composition.


thanks

Dave Booz
STSM, SCA and WebSphere Architecture
Co-Chair OASIS SCA-Policy TC
"Distributed objects first, then world hunger"
Poughkeepsie, NY (845)-435-6093  or  8-295-6093
e-mail:booz@us.ibm.com
http://washome.austin.ibm.com/xwiki/bin/view/SCA2Team/WebHome


                                                                           
             Scott Vorthmann                                               
             <scottv@tibco.com                                             
             >                                                          To 
                                       OASIS Assembly                      
             11/18/2007 01:36          <sca-assembly@lists.oasis-open.org> 
             AM                                                         cc 
                                       Mark Hapner <Mark.Hapner@Sun.COM>   
                                                                   Subject 
                                       [sca-assembly] ISSUE 26: SCA        
                                       Composite Visibility                
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           





http://www.osoa.org/jira/browse/ASSEMBLY-26

On Nov 17, 2007, at 3:06 AM, Mark Hapner wrote:

> resend with the proper subject header
>
> Section 1.6.5 states ...
>
> 'When a composite is used as a component implementation, it defines
> a boundary of visibility. Components within the composite cannot be
> referenced directly by the using component. The using component can
> only connect wires to the services and references of the used
> composite and set values for any properties of the composite. The
> internal construction of the composite is invisible to the using
> component.'
>
> The implication of this statement is that this visibility semantic
> is actually implemented in the deployed application.
>
> Section 1.10.1 states ...
>
> 'A single SCA domain defines the boundary of visibility for all SCA
> mechanisms. For example, SCA wires can only be used to connect
> components within a single SCA domain.'
>
> This statement implies that composite visibility rules apply across
> a Domain including across Composites that span endpoints within the
> Domain.
>
> On the surface these semantics seem consistent; however, they
> conflict with the realities of the technologies that SCA components
> are implemented with.
>
> SCA Visibility Issues
> ------------------
> Visibility is a fundamental composition semantic of Java, BPEL, C+
> +, JMS Queues, network endpoints, PHP, etc. When an SCA component
> and composite is built with these, it is very difficult for SCA to
> impose visibility semantics that go beyond those of the
> implementation technology.
>
> Java provides class and library encapsulation. From what I can
> tell, SCA Java does not directly use library encapsulation so it
> must implement SCA composite visibility with class encapsulation.
> This means that SCA Java must implement nested composite visibility
> over the top of a flat Java class encapsulation model. The result
> is that when an SCA composite is used directly from Java it appears
> as a flat composition of Java classes rather than a nested
> composition.
>
> The same is true for SCA composites that wire network endpoints
> within an SCA Domain. It is difficult to encapsulate an endpoint -
> once its on the net it is broadly visible. There is little an SCA
> environment can do to impose visibility constraints on endpoints.
> Here again, SCA composite nesting is not implementable and the
> result is a flat model of endpoints within an SCA Domain.
>
> Ditto for other technologies ...
>
> Potential Resolution
> --------------------
> It is very difficult to adequately enforce visibility constraints
> that only appear in SCA metadata. To enforce them would imply a
> depth of SCA intrusion into implementation and runtime that goes
> beyond SCA's role as a means to converge the semantics of
> composition. SCA works best when its metadata helps knit components
> together. It gets off track when it attempts to introduce
> composition semantics that can't be implemented by its constituent
> technologies.
>
> It would be helpful if this issue could be added to the TC agenda
> so that its impact on the assembly architecture and the
> implementations of this architecture could be better understood.
>
> -- Mark
>


---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  You may a link to this group and all your TCs in
OASIS
at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php