[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [sca-assembly] ISSUE 26: SCA Composite Visibility
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]