OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

sca-assembly message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [sca-assembly] ISSUE 6 - alternate proposal - Version 2 updated


A few minor comments like <scn>this</scn> below.

    Simon

Simon C. Nash, IBM Distinguished Engineer
Member of the IBM Academy of Technology
Tel. +44-1962-815156  Fax +44-1962-818999



Mike Edwards/UK/IBM@IBMGB 
20/11/2007 22:47

To
"OASIS Assembly" <sca-assembly@lists.oasis-open.org>
cc

Subject
RE: [sca-assembly] ISSUE 6 - alternate proposal - Version 2 updated







Folks, 

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


"Michael Rowley" <mrowley@bea.com> 
20/11/2007 21:03 


To
Mike Edwards/UK/IBM@IBMGB, "OASIS Assembly" 
<sca-assembly@lists.oasis-open.org> 
cc

Subject
RE: [sca-assembly] ISSUE 6 - alternate proposal - Version 2 updated








  
I like this.  I?ve include just a couple comments inline. 
  
Michael 
  



From: Mike Edwards [mailto:mike_edwards@uk.ibm.com] 
Sent: Monday, November 19, 2007 11:49 AM
To: OASIS Assembly
Subject: Re: [sca-assembly] ISSUE 6 - alternate proposal - Version 2 
updated 
  

I've updated the proposal to put in more text dealing with the error cases 
for multiplicity in 
section 3.0.1.1, to answer points raised in the discussion on the list. 


Introduce a new subsection into the specification, to follow line 330:

3.0.1 Specifying the Target Service(s) for a Reference

A reference may define one or more target services which satisfy the
reference.  The target service(s) may be defined in the following ways:


1) Through a value specified in the @target attribute of the reference
element

2) Through a target URI specified in the @uri attribute of a binding
element which is a child of the reference element

3) Through the setting of one or more values for binding-specific
attributes and/or child elements of a binding element which is a child 
of the reference element 

4) Through the specification of @autowire="true" for the reference (or
through inheritance of that value from the component or composite 
containing the reference)

5) Through the promotion of a component reference by a composite reference
of the composite containing the component (the target service is then 
identified by the configuration of the composite reference). 

Some combinations of these different methods are not allowed:

If @autowire="true" applies to the reference, the autowire procedure is 
only used to find a target service if no target is identified by any of 
the 
other ways listed above.  It is not an error if autowire="true" applies to 

a reference and a target is also defined through some other means.

If a reference has a value specified for one or more target services in 
its
@target attribute, the child binding elements, of that reference MUST NOT
<scn>Minor nit: remove the comma after "elements" in the line above.</scn>
identify target services using the @uri attribute or using binding 
specific 
attributes or elements. 
We should explicitly note that for 0..n references, it is not legal to mix 
targets specified using @Target and binding/@uri. 
<mje> I don't follow this comment - I think that the previous paragraph 
outlaws the mixing of @target 
and binding/@uri for all cases (at least, that is what I intended and it 
is how I read the paragraph). 
Why do we need to re-state the same thing for 0..n references? 
</mje> 


If a binding element has a value specified for a target service using its
@uri attribute, the binding element MUST NOT identify target services 
using 
binding specific attributes or elements.

It is possible that a particular binding type MAY require that the address
of a target service uses more than a simple URI.  In such cases, the @uri 
attribute MUST NOT be used to identify the target service - instead, 
binding 
specific attributes and/or child elements must be used.

Where the reference has a value specified in its @target attribute, all 
the
binding types identified by the child binding elements are available for 
use 
on each wire created implied by the @target attribute.


3.0.1.1 Multiplicity and the Valid Number of Target Services for a
Reference

For references with multiplicity 0..1 or 0..n, it is valid for the
reference to have no target service defined.

For references with multiplicity 0..1 or 1..1, it is an error for the
reference to have more than 1 target service defined.

For references with multiplicity 1..1 or 1..n, it is an error for the
reference to have no target service defined.

For references with multiplicity 0..n or 1..n, it is valid for the
reference to have 1 or more target services defined.

The assembler of a composite MUST ensure that references are properly
configured according to these rules. 
The assembler or the deployer of the composite, since the reference could 
be resolved by acts of the deployer. 
<mje>Agreed</mje>
<scn>I'm uncomfortable with using "assembler" (or "deployer") as the
conformance target of this RFC2119 "MUST" rule.  I'd rather use a
spec-defined artifact such as a reference.  With this change, the text
would read: References MUST be properly configured according to these
rules.</scn> 

For the error cases identified above, an error MUST be generated by the 
SCA
runtime before the reference is invoked by the component implementation. 
I would prefer that this error occur before the component that contains 
the reference is invoked.
<mje>Interesting point.  Depends on your runtime model.  If reference 
proxies don't change, 
then it may be valid to test before invocation.  If reference proxies do 
change ("smart proxy" 
concept) then it ain't so clear - especially for composite scoped 
components.  Think carefully 
about how a BPEL process would be handled in this respect.  Deployment 
acts can occur 
while such components are "running".  "Before the reference is invoked" 
was a deliberate 
attempt on my part to address this dynamic situation.  When the reference 
is invoked you 
should definitely know.... 

PS this calls more than ever for a runtime spec 
</mje> 

Some errors can be detected at deployment time.  For example, where a 
composite is used as a component implementation, wires and target services 

cannot be added to the composite after deployment.  As a result, for 
components which are part of the composite, both missing 
wires and wires with a non-existent target can be detected at deployment 
time through a scan of the contents of the composite.  In these cases, an 
error SHOULD be generated by the SCA runtime at deployment time. 

Other errors can only be checked at runtime.  Examples include cases of 
components deployed to the SCA Domain.  At the Domain level, the target of 

a wire, or even the wire itself, may form part of a separate deployed 
contribution and as a result these may be deployed after the original 
component is deployed.  In these cases, the SCA runtime MUST generate an 
error before the reference is invoked by the component implementation. 
Who would the error be reported to?  What would happen to the component 
that is currently running? 
<mje>Excellent question.  I don't have a clear answer.  One place might be 
some monitoring 
entity - but this then begs the question of a management model for the SCA 
runtime. 
(Another todo, in my opinion) 
Reporting the error to the component might be another possibility, but 
what the component 
would do about it is not clear to me. 
In any case, I dont want to try to answer this question in THIS proposal - 
I feel a new issue 
being born.... 
</mje> 

For the cases where it is valid for the reference to have no target 
service
specified, the component implementation language specification defines the 

programming model for interacting with an untargetted reference. 

Where a component reference is promoted by a composite reference, the
promotion is treated from a multiplicity perspective as providing 0 or 
more 
target services for the component reference, depending upon the further 
configuration of the composite reference.  These target services are in 
addition to any target services identified on the component reference 
itself, 
subject to the rules relating to multiplicity described in this section
<scn>Minor nit: missing period at the end of the above line.</scn>


----------------------------------------------------------------------

Replace lines 274 - 280 with the following:

"A reference may identify one or more target services which satisfy the
reference.  This can be done in a number of ways, which are fully 
described 
in section "3.0.1 Specifying the Target Service(s) for a Reference".

Replace lines 1424 - 1430 with the following: 

"A reference may identify one or more target services which satisfy the
reference.  This can be done in a number of ways, which are fully 
described 
in section "3.0.1 Specifying the Target Service(s) for a Reference".

Replace lines 2372 - 2383 with the following:

uri  - has the following semantic

The uri attribute can be omitted.

For the binding of a reference, the uri attribute defines the target URI 
of the reference.  This can be either the componentName/serviceName for 
a wire to an endpoint within the SCA domain, or the accessible address 
of some service endpoint either inside or outside the SCA domain (where 
the addressing scheme is defined by the type of the binding). 
I?m not sure about specifying ?componentName/serviceName? as a valid 
target for bindings.  I believe it would be better for these URI to be 
absolute, rather than relative, since if they were relative, it means that 
the target must be in SCA, in which case the @target attribute should have 
been used. 
Michael Rowley 
<mje>I don't agree with you here.  componentName/serviceName is always a 
fine description for some service within the SCA Domain, even if 
some binding like binding.ws is being used.  I don't see why @target has 
to be used, particularly if in x..n multiplicity cases, different targets 
REQUIRE different bindings.  Users are always free to give a URI which is 
binding specific, but why force them to do that when not necessary? 
</mje>


The circumstances under which the uri attribute can be used are
defined in section 3.0.1 Specifying the Target Service(s) for a 
Reference


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



  
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 












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








[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]