[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
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. 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 . >- 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 ? >- 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.). 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> -----Original Message----- From: Peshev, Peter [mailto:peter.peshev@sap.com] Sent: Tuesday, 23. October 2007 19:23 To: OASIS Assembly Subject: RE: [sca-assembly] ISSUE 6: usage of not promoted references Hi, as discussed on the call, here is the result of the action item to craft a new proposal according to previous week discussions. I left the RFC2119 words capitalized, I personally believe that all proposals should be done in that way and that clearly shows what is expected from the SCA and from the assembler \ developer etc. Being a non-native speaker it's somewhat hard to create precise wording and long texts, so please if there are any issues with word choice or further improvement, I think it would be better to exchange on the mailing list instead of online making a chain of amendments. 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 reference 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> Best Regards Peter Peshev ________________________________ From: Mike Edwards [mailto:mike_edwards@uk.ibm.com] Sent: Friday, 12. October 2007 12:05 To: OASIS Assembly Subject: RE: [sca-assembly] ISSUE 6: usage of not promoted references Peter, That looks good. I'll put it onto the agenda for next week's call. Yours, Mike. Strategist - Emerging Technologies, SCA & SDO. Co Chair OASIS SCA Assembly TC. IBM Hursley Park, Mail Point 146, Winchester, SO21 2JN, Great Britain. Phone & FAX: +44-1962-818014 Mobile: +44-7802-467431 Email: mike_edwards@uk.ibm.com "Peshev, Peter" <peter.peshev@sap.com> 11/10/2007 19:41 To "Michael Rowley" <mrowley@bea.com>, Mike Edwards/UK/IBM@IBMGB, <sca-assembly@lists.oasis-open.org> cc Subject RE: [sca-assembly] ISSUE 6: usage of not promoted references Hi Mike & Michael, thanks very much for the clarification. I agree that the samples and perhaps the whole issue may differ from the general development \ assembly practice, but after all the document is intended as well for implementers of the spec so IMO it's good to describe clearly what should be supported and what should not. In that case I would like to update the issue with the following proposal : 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 RECOMMENDED 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. An unpromoted reference that is operational MUST have 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 those conditions are not provided in any way, then the programming model MUST represent the reference as invalid (null, handle that throws exceptions when accessed, or some equivalent for the implementation type in question). If the reference has a multiplicity of 1..1 or 1..n, then such an unresolved reference MUST generate a deployment error. For example the following definition is legal : <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 definition is not : <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> ________________________________ From: Michael Rowley [mailto:mrowley@bea.com] Sent: Wednesday, 10. October 2007 21:25 To: Mike Edwards; sca-assembly@lists.oasis-open.org Subject: RE: [sca-assembly] ISSUE 6: usage of not promoted references +1 on all points. Michael ________________________________ From: Mike Edwards [mailto:mike_edwards@uk.ibm.com] Sent: Wednesday, October 10, 2007 1:32 PM To: sca-assembly@lists.oasis-open.org Subject: RE: [sca-assembly] ISSUE 6: usage of not promoted references Peter, Let me try - I think Michael Rowley was correct in what he said, but perhaps I can put it differently to help clarify... Comments as <mje>...</mje> Yours, Mike. Strategist - Emerging Technologies, SCA & SDO. Co Chair OASIS SCA Assembly TC. IBM Hursley Park, Mail Point 146, Winchester, SO21 2JN, Great Britain. Phone & FAX: +44-1962-818014 Mobile: +44-7802-467431 Email: mike_edwards@uk.ibm.com "Peshev, Peter" <peter.peshev@sap.com> 10/10/2007 14:41 To "Michael Rowley" <mrowley@bea.com>, "Martin Chapman" <martin.chapman@oracle.com>, <sca-assembly@lists.oasis-open.org> cc Subject RE: [sca-assembly] ISSUE 6: usage of not promoted references Hi Michael, Can you please make some clarifications for your first paragraph (sorry, being non-native speaker leads to some problems understanding more complex sentences:) - you are saying that it is legal for unpromoted reference to have URI "designating a target service" or internal wire in the reference, but you are not explicitly saying whether it is legal to supply the accessible address of some endpoint outside the SCA domain. In other words having in mind the following definition <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> should both references be OK and behave accordingly when invoked from the component code, even though the second doesn't even have URI ? <mje> It is less a question of whether the reference has a URI, more a question of whether the binding has a specified endpoint. For some bindings, it is possible to identify a target endpoint without using a URI. I think that is what you have done in the example above for the StockQuoteService2 reference which has a JMS binding applied. with a target identified by a Queue name. I think that both of the references in the example above do identify endpoints. Both will be valid references in the case where they sit inside a composite which does not promote them.</mje> How about when MyValueComposite is used as implementation.composite as in : <composite name="Wrapper"> <component name="MyValueServiceComponent"> <implementation.composite name="foo:MyValueComposite"/> </component> </composite> Should the external calls to JMS / WS will operate when being invoked without the assembler knowledge, or the pattern is - "promote everything to the domain and wire from there" ? <mje>The component you give in the first snippet, if it is contained in MyValueComposite, but MyValueComposite does not promote either of the references, then both references will be operational, targetting the endpoints as defined within the references. Neither of the two references will form part of the componentType of the MyValueComposite and what this means is that: a) It is not possible to configure the MyValueComposite in any way that will change the endpoints targetted by the two references b) It is not visible to an assembler that the MyValueComposite has these two references to external services (unless the assembler cracks open the MyValueComposite and inspects its contents.</mje> <mje> Whether it is good practice to construct composites in this way is another matter altogether. I argue that it is not good practice, since it is not possible to re-use the composite without also using the services targetted by the references - if the assembler wanted to change those target services, then the assembler would have to crack open the composite and make changes - implying a modified copy rather than re-use.</mje> Btw, when reading several times the assembly spec trying to figure out whether that should work I discovered the following sentence lone 2309 : [the uri attribute is] required for references defined in composites contributed to SCA domains. <mje>This is a whole different issue - this indicates that a reference contributed to the Domain can't be reconfigured by anything, so it can only have a meaning if it carries configuration for a target service...</mje> That seems to be target for another issue, since it's possible for a binding to uniquely define extenal target not by the URI but by some other means, like in the second reference sample. Should I raise another issue or I am missing something ? Best Regards Peter Best Regards Peter -----Original Message----- From: Michael Rowley [mailto:mrowley@bea.com] Sent: Friday, 5. October 2007 16:56 To: Martin Chapman; sca-assembly@lists.oasis-open.org Subject: RE: [sca-assembly] ISSUE 6: usage of not promoted references I believe that an unpromoted binding must have a URI (or EPR) designating a target service, or the reference itself must be internally wired. If a target service is not provided in any way, then the programming model should represent the reference as null (or some equivalent for the language in question). If the reference has a multiplicity of 1..1 or 1..n, then such an unresolved reference should generate a deployment error. If the binding does designate a target, then if the reference is not promoted, then neither the target nor the binding can be overridden. If the reference is promoted, then either can be overridden. But in both cases, the reference is operational. I agree this could be clarified, probably in the binding section. Michael -----Original Message----- From: Martin Chapman [mailto:martin.chapman@oracle.com] Sent: Friday, October 05, 2007 6:40 AM To: sca-assembly@lists.oasis-open.org Subject: [sca-assembly] ISSUE 6: usage of not promoted references http://www.osoa.org/jira/browse/ASSEMBLY-6 >-----Original Message----- >From: Peshev, Peter [mailto:peter.peshev@sap.com] >Sent: Friday, October 05, 2007 7:58 AM >To: sca-assembly@lists.oasis-open.org >Subject: [sca-assembly] NEW ISSUE: usage of not promoted references > > >TARGET: SCA Assembly Specification > >DESCRIPTION: If a component X has a reference with a binding >attached to it (ws.binding or jms.binding) and with no target >in SCA terms, and that component is used in a composite >however the reference is NOT listed as promoted. Is the >reference still operational and what should happen if the >component code invokes it ? > >That describes the common use case when a component is calling >non-SCA world and that component needs to be used in an >assembly. Does the assembler needs to promote a reference all >the way up to the domain or he/she can leave it as it is ? > >PROPOSAL: Clarify the issue, and add a separate section in the >spec with examples how components calling non-SCA code via >standard bindings can be used in assembly. > > > ________________________________ Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU ________________________________ Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. You may a link to this group and all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. You may a link to this group and all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]