[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]