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 6: usage of not promoted references


Thanks for putting this together. Few comments inlined below.

-Anish
--

Peshev, Peter wrote:
>  
> Just to make a summary - it seems the text & the proposal are accepted,
> and the only exception is what should happen in case there is reference
> with multiplicity 1..1 or 1..n , however it is not wired. Initially that
> was proposed as deployment error, however since both Dave & MR seems to
> prefer a runtime error during the first usage to the component, the
> proposal is updated to reflect their opinion.
> 
> Btw, I would assume the same behavior should happen in case the target
> of the reference is component, which is invalid. Since the same
> arguments can apply (the target component may come as later
> contribution), then there should be NO deployment error and the same
> runtime error during the first usage should happen.  
> @Dave &  Michael -- what's your opinion on this & do you think that we
> should add a text about that case in the proposal or that is another
> issue ?
> 
> PROPOSAL
> The following description should be added in section 1.6.2
>       References, after line 1387 (that line is after the paragraph that
>       explains attaching a binding to a reference and before the
> paragraph
>       explaining callback) :
> 
> 
> 
>        Promotion of references accessing endpoints via bindings is
>       suggested practice since it allows the assembler to change the

Why is this a suggested practice?
Promotion allows for higher-level composites to override things. 
Unpromoted references cannot be overridden. That is pretty much it. 
Whether one should promote or not depends on whether it is acceptable 
for the assembler of that composite to have higher-level composites 
override the wiring. Certain composites may not even be meant to be used 
recursive.

It is also not clear to me what the sentence is trying to say. I would 
just remove that sentence.

>       targets of the references or the specified bindings and encourages
>       component reuse, however  the lack of such promotion by itself
> MUST
>       NOT cause errors during deployment or runtime if the target of the
>       reference can be identified. The assembler is expected to
> guarantee
>       for an unpromoted reference with multiplicity 1..1 or 1..n that
> one

How about:
"An assembler MUST ensure that for a unpromoted reference with 
multiplicty ..."

>       of the following conditions holds : there is either internal wire
>       within the scope of the current  composite  or a binding that
>       identifies correctly either the component/service for a wire to an
>       endpoint  within the SCA domain or the accessible address of some
>       endpoint outside the SCA domain.  If the assembler does not
> provide
>       these conditions for a reference that has a multiplicity of 1..1
> or
>       1..n, then such an unresolved reference MUST generate a runtime
> error 
>       at latest during the first attempt to use the component.

What is lost in this is that: this is a deployment error when such a 
reference occurs nested within a deployable composite, it is a runtime 
error *only* when the top-level reference in a deployable composite 
meets those condition.

This is actually part of a general issue about how things are treated 
differently at the domain-level where the recursion tops-out (for 
example, what does a promotion at the domain-level mean?). So I would be 
ok with saying '... MUST generate an error, no later than the first 
attempt to use the component' and leaving this to a different issue.

>       If the assembler does not provide these conditions for a
>       reference that has a multiplicity with 0..1 or 0..n , then the
>       programming model MUST not generate deployment errors and the
>       reference's wiring state will be represented in accordance to the
>       implementation type in question (e.g. null, handle that throws
>       exceptions when accessed,  extensibility hooks, etc.).
> 
> 
> 
>       For example the following definitions MUST NOT generate deployment
>       error
> 
>       :
> 
>       <composite xmlns="http://www.osoa.org/xmlns/sca/1.0";
>       name="MyValueComposite">
>        <component name="MyValueServiceComponent">
>           <implementation.java
>       class="services.myvalue.MyValueServiceImpl"/>
>           <reference name="StockQuoteService">
>             <binding.ws uri=",http://www.sqs.com/StockQuoteService"/>
>           </reference>
>           <reference name="StockQuoteService2">
>             <binding.jms>
>                 <destination name="StockQuoteServiceQueue"/>
>                 <connectionFactory name="StockQuoteServiceQCF"/>
>             </binding.jms>
>           </reference>
>        </component>
>       <!-- no references and promotion on purpose -->
>       <composite>
> 
>       however the following definitions MUST generate one :
> 

Based on the context, this is saying: MUST generate a deployment error. 
I suspect what you mean is '... definitions MUST generate an error'
Also, the examples do not say that they are deployment composites.


>       <composite xmlns="http://www.osoa.org/xmlns/sca/1.0";
>       name="MyValueComposite">
>        <component name="MyValueServiceComponent">
>           <implementation.java
>       class="services.myvalue.MyValueServiceImpl"/>
>           <reference name="UnwiredReference">
>                        <!-- the target cannot be determined, that should
> be
>       an
>       error-->
>             <binding.ws/>
>           </reference>
>        </component>
>       <!-- no references and promotion on purpose -->
>       <composite>
> 

Without an associated componentType (and therefore knowing ref 
cardinality) it is hard to see why this is an error.


> 
> -----Original Message-----
> From: David Booz [mailto:booz@us.ibm.com] 
> Sent: Saturday, 27. October 2007 00:18
> To: sca-assembly@lists.oasis-open.org
> Cc: Blohm, Henning; Martin Chapman; Michael Rowley
> Subject: RE: [sca-assembly] ISSUE 6: usage of not promoted references
> 
> I agree with Mike R's comments.
> 
> I don't think we should complicate multiplicity.  In my mind, your
> second
> and third cases are not distinct because they occur at different points
> in
> the lifecycle of the composite.  I think we should assert that it is
> just
> not possible to detect an error in these cases until the component
> owning
> the reference is started/initialized/dispatched (whatever word you want
> to
> use, they are all the same to me).  That is, I don't think we should
> attempt to support your 3rd point.
> 
> A batch deployment mechanism with special validation semantics sounds
> like
> an interesting vendor extension.  Since this kind of extended behavior
> effectively constrains what can be successfully deployed, it doesn't
> make
> the app incompatible with a vendor that doesn't do batch deploy +
> validation.
> 
> 
> 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
> 
> 
>  
> 
>              "Peshev, Peter"
> 
>              <peter.peshev@sap
> 
>              .com>
> To 
>                                        "Michael Rowley"
> <mrowley@bea.com>, 
>              10/24/2007 02:00          "Martin Chapman"
> 
>              PM?                       <martin.chapman@oracle.com>,
> 
>                                        "Blohm, Henning"
> 
>                                        <henning.blohm@sap.com>, "OASIS
> 
>                                        Assembly"
> 
>  
> <sca-assembly@lists.oasis-open.org> 
>  
> cc 
>  
> 
>  
> Subject 
>                                        RE: [sca-assembly] ISSUE 6: usage
> 
>                                        of not promoted references
> 
>  
> 
>  
> 
>  
> 
>  
> 
>  
> 
>  
> 
> 
> 
> 
> 
> Hi Michael,
> 
> Thanks very much for the clarification, now  I understood what you had
> in
> mind.>,
> 
> Do you think that would lead to a new option for multiplicity (maybe
> raised
> as another issue )  ?
> 
> Since it seems we are wanting to cover 3 scenarios in case the target is
> unavailable
> 
>  -- error during first use of the reference (the 0..1)
>  -- error during first instantiation of component  (what you are
> suggesting
> for 1..1 in order to solve the bulk deployment for cross-referenced
> components)
>  -- error during deployment    (1..1 in the current proposal, and what
> probably many people would expect.
> I.e. even if  such spec expert as you  thought for a moment this is the
> 1..1 meaning, than obviously the mortal guys (me & the assemblers)  may
> be
> thinking the same meaning as well :)
> 
> 
> Best Regards
> Peter
> 
> 
> From: Michael Rowley [mailto:mrowley@bea.com]
> Sent: Wednesday, 24. October 2007 20:32
> To: Peshev, Peter; Martin Chapman; Blohm, Henning; OASIS Assembly
> Subject: RE: [sca-assembly] ISSUE 6: usage of not promoted references
> 
> 
> 
> 
>       From: Peshev, Peter [mailto:peter.peshev@sap.com]
>       Sent: Wednesday, October 24, 2007 12:40 PM
>       To: Martin Chapman; Blohm, Henning; Michael Rowley; OASIS Assembly
>       Subject: RE: [sca-assembly] ISSUE 6: usage of not promoted
> references
> 
>       HI Michael,
> 
>       Since the old text got too much inlined and  I am usually confused
>       with that, I will try to summarize the opened sub-issues.
> 
> 
>       - you are saying
>       "Having 1..1 instead of 0..1 could mean that an error should be
>       generated at runtime, possibly at the first use of the component "
> 
>       That indeed contradicts the proposal, however I have formed the
>       proposal entirely based on your input to the issue on 5th of
> October,
>       where you have stated explicitly :
> 
>       "If the reference has a multiplicity of 1..1 or 1..n, then such an
>       unresolved reference should generate a deployment error."
> 
> You got me there.  I guess I didn't concentrate very closely before on
> deploy vs. runtime for this error.
> 
>       Maybe I have misunderstood you & the intention for 0..1, sorry for
>       that , but that only shows  that the issue is valid and it needs
>       clarification :).
> 
>       I personally believe that the initial suggestion based on your
> email
>       (deployment exception for unwired reference with 1..1) is better
> for
>       the assembler who is alarmed immediately of wiring problems at
>       deployment, instead of deferring them to the first runtime
>       invocation. Often applications are complex and the assembler would
>       have very hard time verifying each possible path of the business
>       logic (full cyclomatic complexity search) to check for such
> unwired
>       references and whether everything is working. That feature at
> least
>       to me seems more valuable than covering the use case of having A
>       wired to B via reference X with 1..1, B wired to A via reference Y
>       with 1..1, A is deployed as single contribution, afterwards B is
>       deployed as single contribution.
> 
>       In addition if we delay the exception at runtime in the 1..1 case,
> I
>       am still lost what exactly is the difference between 0..1 and
> 1..1.
>       In both cases we will allow deployment if there is no target for
> the
>       reference, in both cases there will be exception at runtime if the
>       target is still not available, and in both cases if there is
> target
>       the call will pass.
> 
> The difference is that in the 1..1 case the error will be raised on the
> first use of the component, not on the first use of that reference (that
> way you don't have to wait until the reference is used before getting
> your
> NullPointerException, or whatever it is).
> 
> I'd be OK with generating the error at deployment time if we invented
> some
> means of doing batch deployment - to tell the system not to do its
> checks
> until a group of related deployments are all complete.  However, writing
> up
> such a mechanism would be a bit more work.
> 
>       Back to some other raised issues and raised points:
> 
>        -  I have changed the first sentence in the way you have
> suggested,
>       also specified  that it's neither in runtime nor in deployment
> there
>       will be errors. Thanks for the suggestion
> 
> Great.
> 
>        - The MUST in the last sentence is not bringing enough
> information,
>       very good point.  I switched it to use "will be represented" and
>       added mentioning of the extensibility hooks.
> 
> I like that.
> 
> 
>       So here is the new
> 
> 
>       PROPOSAL :
> 
> I like the new proposal, except the fact that it creates a need for some
> kind of bulk deployment mechanism, as noted above.
> 
> Michael
> 
> 
> 
>       The following description should be added in section 1.6.2
>       References, after line 1387 (that line is after the paragraph that
>       explains attaching a binding to a reference and before the
> paragraph
>       explaining callback) :
> 
> 
> 
>        Promotion of references accessing endpoints via bindings is
>       suggested practice since it allows the assembler to change the
>       targets of the references or the specified bindings and encourages
>       component reuse, however  the lack of such promotion by itself
> MUST
>       NOT cause errors during deployment or runtime if the target of the
>       reference can be identified. The assembler is expected to
> guarantee
>       for an unpromoted reference with multiplicity 1..1 or 1..n that
> one
>       of the following conditions holds : there is either internal wire
>       within the scope of the current  composite  or a binding that
>       identifies correctly either the component/service for a wire to an
>       endpoint  within the SCA domain or the accessible address of some
>       endpoint outside the SCA domain.  If the assembler does not
> provide
>       these conditions for a reference that has a multiplicity of 1..1
> or
>       1..n, then such an unresolved reference MUST generate a deployment
>       error. If the assembler does not provide these conditions for a
>       reference that has a multiplicity with 0..1 or 0..n , then the
>       programming model MUST not generate deployment errors and the
>       reference's wiring state will be represented in accordance to the
>       implementation type in question (e.g. null, handle that throws
>       exceptions when accessed,  extensibility hooks, etc.).
> 
> 
> 
>       For example the following definitions MUST NOT generate deployment
>       error
> 
>       :
> 
>       <composite xmlns="http://www.osoa.org/xmlns/sca/1.0";
>       name="MyValueComposite">
>        <component name="MyValueServiceComponent">
>           <implementation.java
>       class="services.myvalue.MyValueServiceImpl"/>
>           <reference name="StockQuoteService">
>             <binding.ws uri=",http://www.sqs.com/StockQuoteService"/>
>           </reference>
>           <reference name="StockQuoteService2">
>             <binding.jms>
>                 <destination name="StockQuoteServiceQueue"/>
>                 <connectionFactory name="StockQuoteServiceQCF"/>
>             </binding.jms>
>           </reference>
>        </component>
>       <!-- no references and promotion on purpose -->
>       <composite>
> 
>       however the following definitions MUST generate one :
> 
>       <composite xmlns="http://www.osoa.org/xmlns/sca/1.0";
>       name="MyValueComposite">
>        <component name="MyValueServiceComponent">
>           <implementation.java
>       class="services.myvalue.MyValueServiceImpl"/>
>           <reference name="UnwiredReference">
>                        <!-- the target cannot be determined, that should
> be
>       an
>       error-->
>             <binding.ws/>
>           </reference>
>        </component>
>       <!-- no references and promotion on purpose -->
>       <composite>
> 
> 
>       Best Regards
>       Peter
> 
> 
>       From: Martin Chapman [mailto:martin.chapman@oracle.com]
>       Sent: Wednesday, 24. October 2007 19:24
>       To: Blohm, Henning; 'Michael Rowley'; 'OASIS Assembly'
>       Subject: RE: [sca-assembly] ISSUE 6: usage of not promoted
> references
>       do i smell some confromance targets here...what do we (abstractly)
>       install and to what, and where do we deploy it?
>        -----Original Message-----
>        From: Blohm, Henning [mailto:henning.blohm@sap.com]
>        Sent:, Wednesday, October 24, 2007 4:46 PM
>        To: Michael Rowley; OASIS Assembly
>        Subject: AW: [sca-assembly] ISSUE 6: usage of not promoted
>        references
>        Michael,
> 
>          on the deployment error issue. In SCA we seemed to use the term
>        deployment as "making available to process requests" and used the
>        additional term "installation" for getting something into the
>        system.
> 
>          Reading deployment as "making available to process requests" it
> is
>        very close to "use" in which case you and Peter seem to talk
> about
>        the same point in time.
> 
>          It could be best if the assembly spec would include some
> wording
>        to describe the exact meaning of "deploy" and "install". You
> agree?
> 
>        Thanks,
>          Henning
> 
> 
> 
> 
>        Von: Michael Rowley [mailto:mrowley@bea.com]
>        Gesendet: Mittwoch, 24. Oktober 2007 15:28
>        An: OASIS Assembly
>        Betreff: RE: [sca-assembly] ISSUE 6: usage of not promoted
>        references
>        [MR: inline]
> 
>              -----Original Message-----
>              From: Peshev, Peter [mailto:peter.peshev@sap.com]
>              Sent: Wednesday, October 24, 2007 3:26 AM
>              To: Michael Rowley; OASIS Assembly
>              Subject: RE: [sca-assembly] ISSUE 6: usage of not promoted
>              references
> 
>              HI Michael,
> 
>              Comments inline, I have pasted your issues with ">"
> 
>              >- First, "RECOMMENDED" and "NOT REQUIRED" are not a
> defined
>              keywords.
> 
>              PP : There is no ""RECOMMENDED" in this proposal. In
> addition
>              when
>              looking at http://www.ietf.org/rfc/rfc2119.txt  RECOMMENDED
>              and REQUIRED
>              are mentioned as key words.
> 
>        [MR: Good point on RECOMMENDED (I had originally written just
> "NOT
>        REQUIRED", but then belatedly (and incorrectly) added
> "RECOMMENDED"
>        when I happened to see it - apparently when I was looking too far
>        down in the email to the old proposal).  Regarding "NOT REQUIRED"
> -
>        yes "REQUIRED" is a keyword, and "MUST NOT" is also a key phrase,
>        but "NOT REQUIRED" is not.]
> 
> 
>                Anyway as per the notes of the OpenCSA
>              Steering Committee Minutes from  28 September  the keyword
>              SHOULD and
>              its synonym RECOMMENDED are supposed to be avoided, and
> only
>              the rest of
>              the keywords remain to be used. However being a developer I
>              don't claim
>              any competence in speac creation, so maybe you are right.
> 
> 
> 
>              > In particular, the bit that says that "an implementation
>              which does
>              not include a particular option MUST be prepared to
>              interoperate with
>              ...".  What does that mean when the "implementation" is the
>              assembler?
> 
>              PP :  At least my understanding of the keyword usage is
> that
>              they should
>              be used whenever there is requirement towards the SCA
> Runtime
>              (i.e. the
>              vendors that will implement the spec), and not to be used
> for
>              any users
>              of the spec -- assembler, deployer, etc. That's what was
>              supposed to be
>              in the proposal, If something is not done in that way, I
> will
>              be glad to
>              fix.
> 
>              if the first sentence is not clear enough, maybe we can
> adapt
>              it to :
> 
>              Promotion of references accessing endpoints via bindings is
>              common
>              practice since it allows the assembler to change the
> targets
>              of the
>              references or the specified bindings and encourages
> component
>              reuse,:
>              however the lack of such promotion MUST NOT cause error in
> SCA
>              Runtime-s
>              .
> 
>        [MR: I think it is worthwhile to say that promotion is
> recommended
>        (lowercase).  I think it is very valuable for the specification
> to
>        include directives and suggestions to our various human roles.
>        Changing the MUST NOT to be on the runtime seems better, but
> perhaps
>        it should be on deployment, as in "lack of promotion MUST NOT
> cause
>        an error during deployment."]
> 
> 
>              >- I suspect that we should not REQUIRE that a deployment
>              error be
>              generated for unwired 1..1 references.  Consider what would
>              happen if
>              someone developed deployable composites A and B (each from
>              different
>              contributions) with the intention of wiring at least one of
>              the
>              components from A to something in B and wiring at least one
>              component in
>              B to something in A.  There would be no legal ordering of
> the
>              deployments, as the first deployment would always fail.
> 
>              PP :  Yes, it will be an error.  In that case the assembler
>              should use
>              0..1 if he wants to deploy the first component and after
> some
>              time the
>              other. Isn't this exactly what 0..1 was intended for ?
>              Otherwise what is
>              the difference between 0..1 and 1..1 ?
> 
>        [MR: Having 1..1 instead of 0..1 could mean that an error should
> be
>        generated at runtime, possibly at the first use of the component
>        that includes that reference, rather than at deployment time.  It
>        would be unfortunate for someone to have to declare a reference
> that
>        is really required as 0..1 just to get around deployment order
>        issues.]
> 
> 
>              >- The last MUST, which is on the programming model, says:
>              "MUST
>              represent the reference's wiring state in accordance to the
>              implementation type in question".  Presumably Peter meant
> to
>              include the
>              words "as invalid" after the word "state".  However, even
> with
>              this
>              modification I don't like the requirement.  SCA is intended
> to
>              be an
>              integration technology, which means that it needs to be
> able
>              to
>              accommodate a wide variety of implementation types.  Some
> of
>              these
>              implementation types will use programming models where
>              external services
>              can be used, but some kind of default behavior occurs if
> one
>              isn't
>              (think of extensibility hooks).  Such a programming model
>              should be able
>              to represent these as references to SCA, in spite of the
> fact
>              that they
>              don't follow the admonition that unwired references be
>              presented as
>              nulls.
> 
> 
>              PP : The wording "according to the implementation type in
>              question" was
>              supposed to cover the "wide variety of implementation
> types"
>              that you
>              are speaking. If you prefer some other wording I would be
> glad
>              to
>              include. Maybe mentioning explicitly extensibility hooks
> if
>              you
>              consider them so important :
> 
>              ... MUST NOT generate deployment errors and MUST represent
> the
>              reference's wiring state in accordance to the
> implementation
>              type in
>              question (e.g. null,
>              handle that throws exceptions when accessed, extensibility
>              hooks, etc.).
> 
>        [MR: I was reacting against this on the assumption, apparently
>        incorrect, that the words "as invalid" had been removed
>        accidentally, since the current sentence doesn't seem to make any
>        sense.  I read the current wording as saying "the programming
> model
>        MUST represent the reference however it wants."  What kind of a
>        requirement is that?]]
> 
>        Michael
> 
> 
>              Best Regards
>              Peter
> 
>              ________________________________
> 
>              From: Michael Rowley [mailto:mrowley@bea.com]
>              Sent: Tuesday, 23. October 2007 20:54
>              To: Peshev, Peter; OASIS Assembly
>              Subject: RE: [sca-assembly] ISSUE 6: usage of not promoted
>              references
> 
> 
> 
> 
> 
>              I'll comment on the RFC 2119 usage, which I had hoped to
>              avoid, but I we,
>              have to address it at some point, so we might as well start
>              with this
>              proposal.
> 
> 
> 
>              - First, "RECOMMENDED" and "NOT REQUIRED" are not a defined
>              keywords.
>              If we changed it to use the closest defined keyword ("MAY")
> it
>              might be
>              something like "The assembler MAY promote references...",
> but
>              that would,
>              be odd, given the definition of MAY according to 2119:.
> 
> 
> 
>              5. MAY   This word, or the adjective "OPTIONAL", mean that
> an
>              item is
>                 truly optional.  One vendor may choose to include the
> item
>              because a
>                 particular marketplace requires it or because the vendor
>              feels that
>                 it enhances the product while another vendor may omit
> the
>              same item.
>                 An implementation which does not include a particular
>              option MUST be
>                 prepared to interoperate with another implementation
> which
>              does
>                 include the option, though perhaps with reduced
>              functionality. In the,
>                 same vein an implementation which does include a
> particular
>              option
>                 MUST be prepared to interoperate with another
>              implementation which
>                 does not include the option (except, of course, for the
>              feature the
>                 option provides.)
> 
> 
> 
>              In particular, the bit that says that "an implementation
> which
>              does not
>              include a particular option MUST be prepared to
> interoperate
>              with ...".
>              What does that mean when the "implementation" is the
>              assembler?
> 
> 
> 
>              - I suspect that we should not REQUIRE that a deployment
> error
>              be
>              generated for unwired 1..1 references.  Consider what would
>              happen if
>              someone developed deployable composites A and B (each from
>              different
>              contributions) with the intention of wiring at least one of
>              the
>              components from A to something in B and wiring at least one
>              component in,
>              B to something in A.  There would be no legal ordering of
> the
>              deployments, as the first deployment would always fail.
> 
> 
> 
>              - The last MUST, which is on the programming model, says:
>              "MUST
>              represent the reference's wiring state in accordance to the
>              implementation type in question".  Presumably Peter meant
> to
>              include the,
>              words "as invalid" after the word "state".  However, even
> with
>              this
>              modification I don't like the requirement.  SCA is intended
> to
>              be an
>              integration technology, which means that it needs to be
> able
>              to
>              accommodate a wide variety of implementation types.  Some
> of
>              these
>              implementation types will use programming models where
>              external services,
>              can be used, but some kind of default behavior occurs if
> one
>              isn't
>              (think of extensibility hooks).  Such a programming model
>              should be able,
>              to represent these as references to SCA, in spite of the
> fact
>              that they
>              don't follow the admonition that unwired references be
>              presented as
>              nulls.
> 
> 
> 
>              Michael
> 
> 
> 
> 
> 
>              -----Original Message-----
>              From: Peshev, Peter [mailto:peter.peshev@sap.com]
>              Sent: Tuesday, October 23, 2007 12:31 PM
>              To: OASIS Assembly
>              Subject: RE: [sca-assembly] ISSUE 6: usage of not promoted
>              references
> 
> 
> 
> 
> 
>               Once again, replacing the funny idea of :
> 
> 
> 
>              "reference with reference 1..1 or 1..n"
> 
> 
> 
>              with the intended wording. Otherwise everything is the
> same.
>              Sorry :(
> 
> 
> 
> 
> 
> 
> 
>              PROPOSAL :
> 
> 
> 
>              The following description should be added in section 1.6.2
>              References,
> 
>              after line 1387 (that line is after the paragraph that
>              explains
> 
>              attaching a binding to a reference and before the paragraph
>              explaining
> 
>              callback) :
> 
> 
> 
>              Promotion of references accessing endpoints via bindings is
>              common
> 
>              practice since it allows the assembler to change the
> targets
>              of the
> 
>              references or the specified bindings and encourages
> component
>              reuse,
> 
>              however it is NOT REQUIRED. The assembler is expected to
>              guarantee for
> 
>              an unpromoted reference with multiplicity 1..1 or 1..n that
>              one of the
> 
>              following conditions holds : there is either internal wire
>              within the
> 
>              scope of the current  composite  or a binding that
> identifies
>              correctly
> 
>              either the component/service for a wire to an endpoint
> within
>              the SCA
> 
>              domain or the accessible address of some endpoint outside
> the
>              SCA
> 
>              domain.  If the assembler does not provide these conditions
>              for a
> 
>              reference that has a multiplicity of 1..1 or 1..n, then
> such
>              an
> 
>              unresolved reference MUST generate a deployment error. If
> the
>              assembler
> 
>              does not provide these conditions for a reference that has
> a
> 
>              multiplicity with 0..1 or 0..n , then the programming model
>              MUST not
> 
>              generate deployment errors and MUST represent the
> reference's
>              wiring
> 
>              state in accordance to the implementation type in question
>              (e.g. null,
> 
>              handle that throws exceptions when accessed, etc.).
> 
> 
> 
> 
> 
>              For example the following definitions MUST NOT generate
>              deployment error,
> 
>              :
> 
> 
> 
>              <composite xmlns="http://www.osoa.org/xmlns/sca/1.0";
> 
>              name="MyValueComposite">
> 
>               <component name="MyValueServiceComponent">
> 
>                  <implementation.java
>              class="services.myvalue.MyValueServiceImpl"/>
> 
>                  <reference name="StockQuoteService">.
> 
>                    <binding.ws
> uri="http://www.sqs.com/StockQuoteService"/>
> 
>                  </reference>
> 
>                  <reference name="StockQuoteService2">
> 
>                    <binding.jms>
> 
>                        <destination name="StockQuoteServiceQueue"/>
> 
>                        <connectionFactory name="StockQuoteServiceQCF"/>
> 
>                    </binding.jms>
> 
>                  </reference>
> 
>               </component>
> 
>              <!-- no references and promotion on purpose -->
> 
>              <composite>
> 
> 
> 
>              however the following definitions MUST generate one :
> 
> 
> 
>              <composite xmlns="http://www.osoa.org/xmlns/sca/1.0";
> 
>              name="MyValueComposite">
> 
>               <component name="MyValueServiceComponent">
> 
>                  <implementation.java
>              class="services.myvalue.MyValueServiceImpl"/>
> 
>                  <reference name="UnwiredReference">
> 
>                               <!-- the target cannot be determined, that
>              should be an,
> 
>              error-->
> 
>                    <binding.ws/>
> 
>                  </reference>
> 
>               </component>
> 
>              <!-- no references and promotion on purpose -->
> 
>              <composite>
> 
> 
> 
> 
> 
> 
> 
> ---------------------------------------------------------------------
> 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]