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: RE: [sca-assembly] Issue 37 proposal



I had an action to propose an alternative resolution. Apologies I could
not act upon it earlier. However, I would like to response to this
thread and at least get the ideas in front of everybody ...

I do not understand why promotion in a deployable composite should be
treated differently. If promotion is used to reconfigure certain
services/references, I think this requirement is equally valid for a
deployable composite.

I think one of the tenets of the proposal in the email below is that -
all services/references of components in a deployable composite becomes
visible at the Domain level and no special declarations are necessary
for selecting  the particular component services/reference that need to
be made visible at the Domain level. I see a fundamental issue with this
approach. I think there should be a specific syntax/mechanism for
identifying which services/references become visible at the Domain
level, since not every component service/reference may have been
designed and deployed for Domain wide consumption. 

I think it is simpler to solve this problem by requiring that - only the
promoted services/references of the deployed composite are made visible
at the Domain level.  This semantics will also take care of Mike
Edward's use case, AFAICT. 

In essence, the proposal is to use the promotion mechanism for
reconfiguration as well as for controlling the Domain level exposure of
services/references.

Thoughts?
-- Sanjay

> -----Original Message-----
> From: Anish Karmarkar [mailto:Anish.Karmarkar@oracle.com] 
> Sent: Tuesday, May 20, 2008 1:04 AM
> To: OASIS Assembly
> Subject: [sca-assembly] Issue 37 proposal
> 
> Dave and I took an AI to send a proposal for issue 37. This 
> proposal is 
> based on what was outlined in previous calls. I haven't had time to 
> consult with Dave on this, so all errors are mine.
> 
> -----
> Deployable composites can contain promoted references and promoted 
> services. Promoting a service or a reference in the virtual 
> domain-level 
> composite has no meaning. When such deployable composites containing 
> promoted references and/or promoted services are deployed in 
> the domain 
> the SCA RUNTIME MUST ignore the promotions. The promoted services and 
> references are not part of the virtual domain-level composite.
> 
> Note that a deployable composite can contain composite properties, 
> components, include elements and wires, which when deployed to the 
> domain become part of the virtual domain-level composite.
> -----
> 
> -Anish
> --
> 
> ---------------------------------------------------------------------
> 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_workgr
> oups.php 
> 
> 


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