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">

<implementation.java class="services.myvalue.MyValueServiceImpl"/>

<binding.ws uri="http://www.sqs.com/StockQuoteService"/>

</reference>

<binding.jms>

</binding.jms>

</reference>

</component>

however the following definitions MUST generate one :

<composite xmlns="http://www.osoa.org/xmlns/sca/1.0"

name="MyValueComposite">

<implementation.java class="services.myvalue.MyValueServiceImpl"/>

<!-- the target cannot be determined, that should be an

error-->

<binding.ws/>

</reference>

</component>

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