[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
Peshev, Peter wrote:
> 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)
Is that only at the domain level?
-Anish
--
> -- 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"/
> <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]