[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
I was thinking that “deployment”
corresponded (roughly) to the “addToDomainComposite” conceptual
function, although I suppose some deployment errors could be caught earlier,
such as at contribution time. I suspect it is better to use the word “contribute”
over “install”, since we already have the concept of contributions,
so it fits better. Michael From: Blohm,
Henning [mailto:henning.blohm@sap.com] 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. 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] [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]