[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
Never mind.
Somehow missed the email at:
http://lists.oasis-open.org/archives/sca-assembly/200710/msg00116.html
-Anish
--
Anish Karmarkar wrote:
> 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]