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: ISSUE 41: Conflicting domain-level <wire> deployments


Peter,

I admit that I was somewhat uncomfortable about my original proposal
that later wire deployments override older conflicting wire deployments.
Your comment that the older deployment should instead be updated instead
is a good one.

However, I would not do it by keying on the name of the composite.  I
would instead require that the original contribution be updated,
possibly by a call to the logical "updateDeploymentComposite" function.
Do you like that approach?

Michael

-----Original Message-----
From: Peshev, Peter [mailto:peter.peshev@sap.com] 
Sent: Wednesday, January 23, 2008 5:29 AM
To: Michael Rowley; OASIS Assembly
Subject: RE: ISSUE 41: Conflicting domain-level <wire> deployments

Hi Michael,

A couple of thoughts about the issue :

At least my interpretation is that the composite name in
sca-contribution should be a key to the runtime. The runtime could and
should determine by this key whether this contribution is a brand new or
an update of existing version.

I.e. suppose component1/ref1 has multiplicity 0..n ,
when I deploy  --
<composite name="WiringComposite"
                <wire source="component1/ref1"
target="component2/ref2"/>
</composite>

that should add new <wire> as a target for the reference, however when I
deploy much later another contribution :

<composite name="WiringComposite"
                <wire source="component1/ref1"
target="component3/ref3"/>
</composite>

that should NOT add but instead replace, since I have supplied newer
version of WiringComposite. How and when *replace* is done should be
according to spcific implementations (java issue-4 for example).


If I wanted to add a new wire that should be added, I could supply

<composite name="New_Name_Without_Conflict"
                <wire source="component1/ref1"
target="component3/ref3"/>
</composite>


The question of how such wires are removed -- well, I would assume that
there are two options 
 -- I would assume that each runtime would offer some mechanism of
undeployment, either via a management interface or via some proprietary
tooling. Section 10.4 hints on that. So that can be used as well to
remove the wire supplied as contribution.
 -- somewhat artificial, but the assembler could provide a new version
of the wire contribution, where the target is empty. I.e. by deploying :
<composite name="New_Name_Without_Conflict" <wire
source="component1/ref1" target=""/>  </composite>



About "Later wire deployments should override existing wire"
deployments for 0..1 or 1..1 references. ": 
If the initial wiring was supplied via a dedicated contribution with a
wire in it, than the mechanism above used for supplying new versions as
a contribution using the unique name can be used to change the target. 
The question arises as to what to do in case the initial wiring was
supplied via <reference target="...", > and someone deploys a
contribution with wire, or there is already existing wire, and someone
deploys a new contribution (not an update to the existing one). 
Just for simplicity that could be classified as an error. An update of
an existing configured contribution should not be done by deployment
from outside as another one but from a management model that a vendor
could expose. 


Btw, sorry if some of those were already discussed and rejected on the
F2F, it was hard for me to follow all the talks and it was pass midnight
here :).

Best Regards
Peter




-----Original Message-----
From: Scott Vorthmann [mailto:scottv@tibco.com]
Sent: Wednesday, 23. January 2008 02:56
To: Michael Rowley
Cc: OASIS Assembly
Subject: [LIKELY JUNK][sca-assembly] ISSUE 41: Conflicting domain-level
<wire> deployments


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

On Jan 22, 2008, at 4:43 PM, Michael Rowley wrote:

>
> RAISER: Michael Rowley
>
> TARGET: SCA Assembly Specification WD 2, section 6.4 Wire
>
> DESCRIPTION:
>
> If a component is deployed with a wire target, and then a later 
> deployment includes a <wire> for the same component reference, what 
> should happen?
>
> Is the answer different if the multiplicity is 0..1, 1..1 or 0..n?  
> If we treat 0..n so that new <wire> add targets for the reference, 
> is there any way to remove targets?
>
> What should happen for later conflicting <wire> deployments?
>
> PROPOSAL:
>
> (informally) Later wire deployments should override existing wire 
> deployments for 0..1 or 1..1 references.  For 0..n references, new 
> <wire target=""> elements are additive.  We should introduce a new 
> attribute <wire all_targets=""> which replaces the complete list of 
> targets for the @source.
>


---------------------------------------------------------------------
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]