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 95] "wiredByImpl" is an invalid attribute for aComposite Reference


See below <dab> </dab>

Dave Booz
STSM, BPM and SCA Architecture
Co-Chair OASIS SCA-Policy TC and SCA-J TC
"Distributed objects first, then world hunger"
Poughkeepsie, NY (845)-435-6093 or 8-295-6093
e-mail:booz@us.ibm.com

Inactive hide details for Anish Karmarkar ---12/08/2008 08:02:49 PM---David Booz wrote: > Hi Anish,Anish Karmarkar ---12/08/2008 08:02:49 PM---David Booz wrote: > Hi Anish,


From:

Anish Karmarkar <Anish.Karmarkar@oracle.com>

To:

sca-assembly@lists.oasis-open.org

Date:

12/08/2008 08:02 PM

Subject:

Re: [sca-assembly] [Issue 95] "wiredByImpl" is an invalid attribute for a Composite Reference





David Booz wrote:
> Hi Anish,
>
> You said:
>  >> A wiredByImpl reference can never be wired by a SCDL file
>  >>(regardless of where the origins of that reference are).
> I agree and this is critically important. Promotion is about making
> references visible for wiring. If a reference can never be wired by SCDL
> then what is the point of making it available for wiring? This is how I
> arrive at the conclusion that promotion and wiredByImpl are incompatible
> concepts.
>

SCA promotion isn't only about visibility. It is also about allowing
configuration changes. IIRC, Sanjay proposal regarding 'external
attachments only for policy/bindings,' which I *think* was accepted, is
to say that both external attachments and inlined policies/bindings are
allowed (although optional). If we had accepted the initial idea of
requiring external attachments for configuration changes, which I had
initially preferred but later abandoned given that it makes simple
things hard, then what you say would have been true.
<dab> I still think what I said is true. Primarily, promotion is about visibility, Visibility is what enables configurability. I am splitting hairs but in this case I think it's important. </dab>

As a side (not related to wiredByImpl), intents specified on either end
of the wire are applied on both ends. Is that true of policy sets? OR
are policy sets local to the end at which they are specified. The reason
I ask is, for a service with multiple bindings, can a reference be wired
to that service and policy sets specified on the reference end be used
to subset the possible bindings for the wire?
<dab> Policy Sets are local to the end where they are attached. What you are asking for is not possible with the Policy FW today. I think it should be part of enabling the fully dynamic use cases as I described below. </dab>

>  >> All one can do
>  >>wrt wiredByImpl ref is change policy/intent/bindings
> I do not agree. I don't believe that it is practical to think that
> policy can be attached to a wiredByImpl reference. The real use cases
> here are around complete dynamicity, and this would include policy. The
> component is in complete control of the configuration of the reference.
> I don't understand the point of a middle ground where some parts of a
> reference are dynamic, but others are not.
>

Ok, but the raison d'être for wiredByImpl was exactly that. If we have
complete dynamicy, what is the point of having that reference show up in
the componentType. IIUC, your position isn't about promotion. By
extension, I would be able to argue that one can't set policies or
intents on the atomic component reference with a wiredByImpl='true
either. I.e., get rid of wiredByImpl. Fundamentally, I don't see a
difference between a wiredByImpl component reference and a wiredByImpl
composite reference, in the context of this issue.

<dab> :-) </dab>

> In fact, I have always wondered why we needed this wiredByImpl concept
> at all. I would much prefer a model where the C&Is came up with APIs
> which enabled changes to the metadata, e.g. altering targets, altering
> policy, altering bindings. Then I could think about some marker metadata
> which indicated support/non-support for dynamicity. wiredByImpl would be
> a bad name for such a marker. I'm thinking on the fly here, but I think
> in this case, the static config we have today becomes a suggestion
> (maybe a default) for references that support dynamicity. And yes, there
> are several interesting problems to solve here, but I'd rather solve
> them or leave completely up to vendors to solve (for V1.1).
>

Ah, Ok, I'm beginning to see your line of thinking here.
If that (APIs) is the path we take, then I don't quite see why we would
list that reference in the CT (certainly not in v1.1). Such a reference
that is not wireable or configurable through assembly would not be a
concern of SCA. It would make sense to let vendors deal with it.

<dab> Yes. </dab>

But, I know BPEL folks had some useful scenarios that they wanted to
enable. Since I wasn't intimately involved in those discussions I'm
hoping that someone who understands those scenarios would pipe up.

> FWIW, I have similar concerns over autoWire, which is why I fought so
> hard to make it optional. If we could twist autowilre into something that
> included query strings (so that policy matching could be included) and
> also allowed for arbitrary metadata tags on services (and references)
> that the query strings could use, then I might be happier. I'd see this
> as the metadata driven form of the completely dynamic case driven by API
> that I talked about above. But right now, we're in this damp, swampy
> middle ground, half way down the dynamicity slope.
>

How about twisting autowire out of existence from the spec?  ;-)
... and requiring explicit targets/wires
<dab> I can't go quite that far yet, and besides autowire is a tangent to the main discussion. I only brought it up to illustrate the broader picture in my head. </dab>

> Well, I feel better now that I've vented a bit.
>
> Dave Booz
> STSM, BPM and SCA Architecture
> Co-Chair OASIS SCA-Policy TC and SCA-J TC
> "Distributed objects first, then world hunger"
> Poughkeepsie, NY (845)-435-6093 or 8-295-6093
> e-mail:booz@us.ibm.com
>
> Inactive hide details for Anish Karmarkar ---12/02/2008 06:52:56
> PM---Dave, I'm not sure I understand why you say:Anish Karmarkar
> ---12/02/2008 06:52:56 PM---Dave, I'm not sure I understand why you say:
>
>
> From:
> Anish Karmarkar <Anish.Karmarkar@oracle.com>
>
> To:
> sca-assembly@lists.oasis-open.org
>
> Date:
> 12/02/2008 06:52 PM
>
> Subject:
> Re: [sca-assembly] [Issue 95] "wiredByImpl" is an invalid attribute for
> a Composite Reference
>
> ------------------------------------------------------------------------
>
>
>
> Dave,
>
> I'm not sure I understand why you say:
> "... promotion as a concept is incompatible
> with wiredByImpl which clearly wants the wiring configuration to be
>  managed by the component implementation."
>
> I suspect I'm probably not getting it. Here is how I see it:
> Promotion is essentially an act of setting the CT associated with
> composite. A wiredByImpl reference can never be wired by a SCDL file
> (regardless of where the origins of that reference are). All one can do
> wrt wiredByImpl ref is change policy/intent/bindings -- this is true
> regardless of whether is it present in a atomic component or not.
>
> I do think that we need to say that a promoted wiredByImpl must be
> explicitly mark as such (I suppose we could default it) -- in effect the
> CT associated with the composite must show wiredByImpl='true'.
>
> -Anish
> --
>
> David Booz wrote:
>  > Another way to go here is to consider that the act of promotion is a
>  > conscious act of creating public visibility for the purposes of
>  > configuration. In this sense, promotion as a concept is incompatible
>  > with wiredByImpl which clearly wants the wiring configuration to be
>  > managed by the component implementation. Therefore, we could decide that
>  > wiredByImpl + promotion is an error. I don't recall, did we discuss this
>  > on the call? Perhaps we did and too much of Mom's cooking has dulled my
>  > memory.
>  >
>  > Dave Booz
>  > STSM, BPM and SCA Architecture
>  > Co-Chair OASIS SCA-Policy TC and SCA-J TC
>  > "Distributed objects first, then world hunger"
>  > Poughkeepsie, NY (845)-435-6093 or 8-295-6093
>  > e-mail:booz@us.ibm.com
>  >
>  > Inactive hide details for Simon Nash ---11/30/2008 07:01:35 PM---Anish,
>  > I agree with your comments about the meaning of wiredBySimon Nash
>  > ---11/30/2008 07:01:35 PM---Anish, I agree with your comments about the
>  > meaning of wiredByImpl on a
>  >
>  >
>  > From:
>  > Simon Nash <oasis@cjnash.com>
>  >
>  > To:
>  > OASIS Assembly <sca-assembly@lists.oasis-open.org>
>  >
>  > Date:
>  > 11/30/2008 07:01 PM
>  >
>  > Subject:
>  > Re: [sca-assembly] [Issue 95] "wiredByImpl" is an invalid attribute for
>  > a Composite Reference
>  >
>  > ------------------------------------------------------------------------
>  >
>  >
>  >
>  > Anish,
>  > I agree with your comments about the meaning of wiredByImpl on a
>  > composite reference.  This is the point I was trying to make
>  > (albeit not very successfully) on the call.
>  >
>  > Regarding 0..0, I don't think this is the same as wiredByImpl.
>  > I think a wiredByImpl reference could be 0..1, 1..1, 0..n or 1..n.
>  >
>  > If it is 1..n or 0..n, it's represented by an array in a Java
>  > component implementation; otherwise it's represented by a scalar.
>  >
>  > If it is 0..1 or 0..n, the implementation is allowed to wire it but
>  > is not obliged to do so; otherwise, the implementation must wire it.
>  >
>  >   Simon
>  >
>  > Anish Karmarkar wrote:
>  >  > Mike,
>  >  >
>  >  > Apologies for misunderstanding your proposal on the call today.
>  >  > Unfortunately, line numbers on a 2007 .doc file don't mean a whole lot
>  >  > to me.
>  >  >
>  >  > IIUIC, what you are proposing is to get rid of the attribute
> wiredByImpl
>  >  > on a composite reference, while retaining the ability to promote a
>  >  > component reference that has wiredByImpl='true'.
>  >  >
>  >  > If this is correct, I think this is problematic. Without the
>  >  > wiredByImpl='true', the componentType associated with the
> composite will
>  >  > not contain information about the fact that the reference cannot be
>  >  > wired. Higher-level composites won't know the cardinality associated
>  >  > with the reference (which is 0..0) and therefore will be free to wire
>  >  > it. Unless, the spec says that wiredByImpl='true' automatically
> becomes
>  >  > part of the CT associated with the composite by the virtue of the fact
>  >  > that the underlying component reference has wiredByImpl='true'. We
> allow
>  >  > narrowing of constraints when promoting. A 0..0 cannot be narrowed any
>  >  > further, so wireByImpl='true' is indeed ripe for defaulting in such
>  > cases.
>  >  >
>  >  > But as it stands I don't think there is any inconsistency in the spec
>  >  > (other than the fact that it does not say that you cannot change the
>  >  > value of wiredByImpl when promoting).
>  >  >
>  >  > Currently, wiredByImpl says:
>  >  > "wiredByImpl : boolean (0..1) - a boolean value, "false" by default,
>  >  > which indicates that the implementation wires this reference
>  >  > dynamically.  If set to "true" it indicates that the target of the
>  >  > reference is set at runtime by the implementation code (eg by the code
>  >  > obtaining an endpoint reference by some means and setting this as the
>  >  > target of the reference through the use of programming interfaces
>  >  > defined by the relevant Client and Implementation specification).  If
>  >  > "true" is set, then the reference should not be wired statically
> within
>  >  > a composite, but left unwired."
>  >  >
>  >  > Which seems right to me. There is implementation code associated
> with a
>  >  > composite reference: it is the code associated with the corresponding
>  >  > promoted component reference (however levels deep).
>  >  >
>  >  > OTOH, the existence of wiredByImpl when we already have the
> multiplicity
>  >  > attribute (on both component reference as well as composite reference)
>  >  > always seemed a little strange to me. wiredByImpl is really saying
>  >  > multiplicity of 0..0, why not then just say exactly that. I know this
>  >  > was discussed during the OSOA days, but I don't recall why
> addition of a
>  >  > new attribute was chosen over 0..0.
>  >  >
>  >  > I'll be bold and make a proposal to remove wiredByImpl altogether and
>  >  > use 0..0 on the multiplicity attribute instead (with the usual
> narrowing
>  >  > rules for promotion).
>  >  >
>  >  > I'm hoping that, if there was a good argument for choosing wiredByImpl
>  >  > over 0..0 in OSOA, someone will bring it up here.
>  >  >
>  >  > Comments?
>  >  >
>  >  > -Anish
>  >  > --
>  >  >
>  >  > Mike Edwards wrote:
>  >  >>
>  >  >> Raiser:                Mike Edwards
>  >  >>
>  >  >> Target:                Assembly spec:
>  > sca-assembly-1.1-spec-cd01-rev3.doc
>  >  >>
>  >  >> Description:
>  >  >>
>  >  >> The current spec has the attribute @wiredByImpl as an attribute of a
>  >  >> Composite reference element.
>  >  >> This cannot be valid, since there @wiredByImpl=true implies that the
>  >  >> composite itself will act to wire
>  >  >> the reference at runtime.  However, this can never happen since there
>  >  >> is no active code in the
>  >  >> composite which could do this.
>  >  >>
>  >  >> It is valid for a reference on a component within the composite to
>  >  >> have @wiredByImpl on one of its
>  >  >> references, but this applies to wiring of the component reference -
>  >  >> and NOT to wiring of any
>  >  >> promotion of that reference.
>  >  >>
>  >  >> Proposal:
>  >  >>
>  >  >> Remove @wiredByImpl from <reference/> within a <composite/>.
>  >  >>
>  >  >> Specifically:
>  >  >>
>  >  >> Line 1337 - remove  wiredByImpl="xs:boolean"?
>  >  >>
>  >  >> Lines 1399 - 1405 - remove
>  >  >>
>  >  >> Lines 3825 - 3826 - remove
>  >  >>
>  >  >> Lines 3971 - 4006 - replace with:
>  >  >>
>  >  >>     <complexType name="ComponentReference">
>  >  >>
>  >  >>             <complexContent>
>  >  >>
>  >  >>                             <sequence>
>  >  >>
>  >  >>                                     <element ref="sca:interface"
>  >  >> minOccurs="0" maxOccurs="1" />
>  >  >>
>  >  >>                                     <element name="operation"
>  >  >> type="sca:Operation" minOccurs="0"
>  >  >>
>  >  >>                                             maxOccurs="unbounded" />
>  >  >>
>  >  >>                                     <element ref="sca:binding" />
>  >  >>
>  >  >>                                     <element ref="sca:callback"
>  >  >> minOccurs="0" maxOccurs="1" />
>  >  >>
>  >  >>                                     <any namespace="##other"
>  >  >> processContents="lax" minOccurs="0"
>  >  >>
>  >  >>                                             maxOccurs="unbounded" />
>  >  >>
>  >  >>                             </sequence>
>  >  >>
>  >  >>                             <attribute name="name" type="NCName"
>  >  >> use="required" />
>  >  >>
>  >  >>                   <attribute name="autowire" type="boolean"
>  >  >> use="optional" />
>  >  >>
>  >  >>                             <attribute name="wiredByImpl"
>  >  >> type="boolean" use="optional"
>  >  >>
>  >  >>                         default="false"/>
>  >  >>
>  >  >>                             <attribute name="target"
>  >  >> type="sca:listOfAnyURIs" use="optional"/>
>  >  >>
>  >  >>                             <attribute name="multiplicity"
>  >  >> type="sca:Multiplicity"
>  >  >>
>  >  >>                                     use="optional" default="1..1" />
>  >  >>
>  >  >>                             <attribute name="requires"
>  >  >> type="sca:listOfQNames" use="optional"/>
>  >  >>
>  >  >>                         <attribute name="policySets"
>  >  >> type="sca:listOfQNames"
>  >  >>
>  >  >>                                 use="optional"/>
>  >  >>
>  >  >>                             <anyAttribute namespace="##other"
>  >  >> processContents="lax" />
>  >  >>
>  >  >>             </complexContent>
>  >  >>
>  >  >>     </complexType>
>  >  >>
>  >  >>
>  >  >> Yours,  Mike.
>  >  >>
>  >  >> Strategist - Emerging Technologies, SCA & SDO.
>  >  >> Co Chair OASIS SCA Assembly TC.
>  >  >> IBM Hursley Park, Mail Point 146, Winchester, SO21 2JN, Great
> Britain.
>  >  >> Phone & FAX: +44-1962-818014    Mobile: +44-7802-467431  Email:  
>  >  >> mike_edwards@uk.ibm.com
>  >  >>
>  >  >>
>  >  >>
> ------------------------------------------------------------------------
>  >  >>
>  >  >> /
>  >  >> /
>  >  >>
>  >  >> /Unless stated otherwise above:
>  >  >> IBM United Kingdom Limited - Registered in England and Wales with
>  >  >> number 741598.
>  >  >> Registered office: PO Box 41, North Harbour, Portsmouth,
> Hampshire PO6
>  >  >> 3AU/
>  >  >>
>  >  >>
>  >  >>
>  >  >>
>  >  >>
>  >  >>
>  >  >
>  >  > ---------------------------------------------------------------------
>  >  > To unsubscribe from this mail list, you must leave the OASIS TC that
>  >  > generates this mail.  Follow this link to all your TCs in OASIS at:
>  >  >
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>  >  >
>  >  >
>  >
>  >
>  >
>  > ---------------------------------------------------------------------
>  > To unsubscribe from this mail list, you must leave the OASIS TC that
>  > generates this mail.  Follow this link to all your TCs in OASIS at:
>  >
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 
>  >
>  >
>  >
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS at:
>
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 
>
>
>

---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to 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]