[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
Looks good to me. Michael -----Original Message----- From: Peshev, Peter [mailto:peter.peshev@sap.com] Sent: Monday, October 29, 2007 3:57 AM To: David Booz; sca-assembly@lists.oasis-open.org Cc: Blohm, Henning; Martin Chapman; Michael Rowley Subject: RE: [sca-assembly] ISSUE 6: usage of not promoted references 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 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 runtime error at latest during the first attempt to use the component. 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> -----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>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]