[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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----- 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]