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: [sca-assembly] [NEW ISSUE] SCA Composite Visibility

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

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