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


After reading the thread, I'm confused about what the exact proposal is. 
Can someone point me to it. If it isn't present in a single place, can 
someone (possibly Peter) send a new proposal that has all the changes in it?

Thanks!

-Anish
--

David Booz wrote:
> 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>
> 
> 
> 
> 
> 
> 


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