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

["Blohm, Henning" <henning.blohm@sap.com>]

Mark,

  the boundary of visibility implied by a composite definition is w.r.t.
to SCA definitions, i.e. like not being able to address a service in
nested component that has not been promoted. That is a model restriction
but not something you can ensure (comprehensively) at runtime and hence
we should not require that.

Thanks,
 Henning

 

-----Original Message-----
From: Scott Vorthmann [mailto:scottv@tibco.com] 
Sent: Sonntag, 18. November 2007 07:37
To: OASIS Assembly
Cc: Mark Hapner
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