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 !


Hi Peter,

Ok, good. It should also be possible for tools to detect such a SCDL
validation problem long before it gets to deployment.  I'd say this is
similar to a compile error.  Also don't forget about the @wiredByImpl would
would put another twist on when a reference is validly targetted.

On your second point, I see the distinction now.  I keep forgetting that
wires can be deployed which change an already deployed composite. I really
wish that wasn't possible, so I mentally block out that case. :-(


Dave Booz
STSM, SCA and WebSphere Architecture
Co-Chair OASIS SCA-Policy TC
"Distributed objects first, then world hunger"
Poughkeepsie, NY (845)-435-6093  or  8-295-6093
e-mail:booz@us.ibm.com
http://washome.austin.ibm.com/xwiki/bin/view/SCA2Team/WebHome


                                                                           
             "Peshev, Peter"                                               
             <peter.peshev@sap                                             
             .com>                                                      To 
                                       David Booz/Poughkeepsie/IBM@IBMUS,  
             11/15/2007 01:51          <sca-assembly@lists.oasis-open.org> 
             AM                                                         cc 
                                                                           
                                                                   Subject 
                                       RE: [sca-assembly] ISSUE 6 -        
                                       alternate proposal - Version 2 !    
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           




Hi Dave,

Answering in reverse order :

So you are suggesting the case of multiplicity 1..1 / 1..n and having no
target in case the wiring is NOT on the domain (i.e. no way to be
changed by another contribution) to be treated as SCDL validation error
in another section, and probably lead to error during deployment. That
makes a lot of sense to me.


Yes, there is distinction between
 -- the target service has not yet been deployed
 -- a reference indicates no target service, bit another contribution
can potentially deploy a wire that has source this reference.

I thought we could describe them together, since there are some
similarities   (In both of the cases we can say  that such a deployment
is valid, however until the reference is resolved the component cannot
be used. - "an error MUST be generated by the SCA runtime before the
reference is invoked by the component implementation." .)

However splitting the two cases in two different sections as you
suggested can be better.

Best Regards
Peter

-----Original Message-----
From: David Booz [mailto:booz@us.ibm.com]
Sent: Wednesday, 14. November 2007 21:49
To: sca-assembly@lists.oasis-open.org
Subject: RE: [sca-assembly] ISSUE 6 - alternate proposal - Version 2 !

Hi Peter,

I'll use your numbering to respond.

A) There is a difference between a reference which indicates a target
service(s) which has not yet been deployed vs a reference which
indicates
no target service(s).  The latter is described by the text that you
pointed
out in 1).  The former is an independent discussion that has to do with
when and how a specified target is resolved from the perspective of a
reference.  We should not confuse these two cases.  Autowire introduces
a
twist because it enables the latter to potentially behave like the
former
in that deployment of a composite _might_ produce a reference target.  I
think we would need another section to describe the behavior of the
former
case +/- autowire.

B) I would put this in the category of SCDL validation errors.  We
probably
need some text in section 6.5 [1] or a new section.

2) Agree, but what's the difference between this case and (B)?


[1] sca-assembly-draft-20070924.pdf

Dave Booz
STSM, SCA and WebSphere Architecture
Co-Chair OASIS SCA-Policy TC
"Distributed objects first, then world hunger"
Poughkeepsie, NY (845)-435-6093  or  8-295-6093
e-mail:booz@us.ibm.com
http://washome.austin.ibm.com/xwiki/bin/view/SCA2Team/WebHome




             "Peshev, Peter"

             <peter.peshev@sap

             .com>
To
                                       David
Booz/Poughkeepsie/IBM@IBMUS,
             11/14/2007 11:27
<sca-assembly@lists.oasis-open.org>
             AM
cc



Subject
                                       RE: [sca-assembly] ISSUE 6 -

                                       alternate proposal - Version 2 !

















Hi,

I also think that it's better to finish this one.
However just wanted to mention two points, which perhaps can be
addressed as separate issues later.


1) The sentences in the proposal are :

For references with multiplicity 1..1 or 1..n, it is an error for the
reference to have no target service defined.
....
For the error cases identified above, an error MUST be generated by the
SCA
runtime before the reference is invoked by the component implementation.





As discussed earlier in the mailing thread and posted by Mike E. and
Anish we may wish to distinguish two possible sub-cases

 A) The case when the problem could be fixed by another contribution
(i.e. the target will be on a domain level). In that subcase we may
defer the exception to the first usage of the component. (Michael R. has
suggested as well thinking about batch deployment)
 B) The case when a missing reference target simply cannot be fixed by
another contribution. (i.e. non-promoted reference / use of Composite as
a component implementation). In that subcase it's safe to say there is
MUST for exception during deploy time


2) The proposal is very detailed and descriptive (much better than I
would have hoped to do it myself).
It is speaking about  - lack of target  \ having target via (@target
attribute, etc.).

Just to make the spec bulletproof, we may also cover the somewhat
obvious case what should happen if there is specified target but it is
wrong (
(invalid component\service name in the @target attribute, there is
@autowire but no suitable implementation, etc.)

Maybe we can have wording "in case the target can not be identified,
then  the deploy\runtime behavior  will be the same as if there is no
target specified."

Another possibility would be to craft the term "valid target".


Best Regards
Peter


-----Original Message-----
From: David Booz [mailto:booz@us.ibm.com]
Sent: Tuesday, 13. November 2007 18:11
To: sca-assembly@lists.oasis-open.org
Subject: Re: [sca-assembly] ISSUE 6 - alternate proposal - Version 2 !

It looks good to me.  As far as I can tell, it has the same technical
points that I wanted to cover, with the additional dimension of autowire
included.  I think that's good.  Your proposal is more verbose, but
sometimes that can be beneficial.

I spotted one typo in the following; delete one of "created" or
"implied".
I prefer created.

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.


Final comment in passing. We need to take a look at the Wires section
(6.4
currently) and align it with this new text also.  But that's going to be
alot more work that might be better done under a seperate issue.  This
one
is starting to get large and we aren't really changing anything, just
clarifying.


Dave Booz
STSM, SCA and WebSphere Architecture
Co-Chair OASIS SCA-Policy TC
"Distributed objects first, then world hunger"
Poughkeepsie, NY (845)-435-6093  or  8-295-6093
e-mail:booz@us.ibm.com
http://washome.austin.ibm.com/xwiki/bin/view/SCA2Team/WebHome




             Mike Edwards

             <mike_edwards@uk.

             ibm.com>
To
                                       "OASIS Assembly"

             11/13/2007 09:27
<sca-assembly@lists.oasis-open.org>
             AM
cc



Subject
                                       Re: [sca-assembly] ISSUE 6 -

                                       alternate proposal - Version 2 !


















Dave,

I've been pondering this some more and I think there is a need to go
further than your proposal text.

The main issue here is to define what it means for a reference to have
one
or more target services configured, either through wiring or through
promotion:

a) Wiring through promotion by a composite reference element
b) Wiring through the use of value of @target on the enclosing reference
element
c) Identification of a target service through the @uri attribute on the
binding element
d) Identification of a target service through binding-specific
attributes
and child elements, as defined in
the specification for the specific binding
e) autowire


....and that is the order of precedence....


In order to deal with all this, I think that we must 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 identify target services using the @uri
attribute or using binding specific attributes or elements.

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.

For the error cases identified above, an error MUST be generated by the
SCA
runtime before the reference is invoked
by the component implementation.

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


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

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

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











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



----- Message from "Mike Edwards" <mike_edwards@uk.ibm.com> on Tue, 30
Oct
2007 16:01:17 +0100 -----


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



  Subject: RE: [sca-assembly] ISSUE 6: usage of not promoted references






Folks,

I think that there is still a problem here that has not been tackled.

I think that it is all down to the usage intended for the composite.  I
believe that there are 2 cases
and that they are distinct:

a) Use of a composite as a component implementation.
b) Use of a composite for inclusion into the Domain (ie where the
composite's contents become part of the Domain).

I leave out the case of a composite being included into another
composite -
the rules for that case are actually then
simply applied to the containing composite....


Case A.  Use of Composite as a component implementation

In this case, there is nothing that will ever occur that can change or
add
to the wiring within the composite.
If it is not complete at the time the composite is used as an
implementation, then it never will be complete and
there is an error.  The error can be generated as soon as the using
component is deployed.

Case B.  Use of a composite for inclusion into the Domain.

This is VERY different for the simple reason that either some wire
targets
may get added to the Domain later
than the composite, or that the wires themselves may be added to the
Domain
later than the composite.

There can be no error up until the moment that someone tries to invoke
the
service(s) provided by a component
whose references are not wired - and only then for cases where the
multiplicity is 1..1 or 1..n.

We may have to look much harder at some of the dynamic aspects of Case B
before we can give proper words
to the spec.



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>

29/10/2007 07:57 To
"David Booz" <booz@us.ibm.com>, <sca-assembly@lists.oasis-open.org>
cc
"Blohm, Henning" <henning.blohm@sap.com>, "Martin Chapman"
<martin.chapman@oracle.com>, "Michael Rowley" <mrowley@bea.com>
Subject
RE: [sca-assembly] ISSUE 6: usage of not promoted references







Just to make a summary - it seems the text & the proposal are accepted,
and the only exception is what should happen in case there is reference
with multiplicity 1..1 or 1..n , however it is not wired. Initially that
was proposed as deployment error, however since both Dave & MR seems to
prefer a runtime error during the first usage to the component, the
proposal is updated to reflect their opinion.

Btw, I would assume the same behavior should happen in case the target
of the reference is component, which is invalid. Since the same
arguments can apply (the target component may come as later
contribution), then there should be NO deployment error and the same
runtime error during the first usage should happen.
@Dave &  Michael -- what's your opinion on this & do you think that we
should add a text about that case in the proposal or that is another
issue ?

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
     suggested 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 by itself
MUST
     NOT cause errors during deployment or runtime if the target of the
     reference can be identified. 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 runtime
error
     at latest during the first attempt to use the component.
     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 the
     reference's wiring state will be represented in accordance to the
     implementation type in question (e.g. null, handle that throws
     exceptions when accessed,  extensibility hooks, 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, thatshouldbean
error-->
           <binding.ws/>
         </reference>
      </component>
     <!-- no references and promotion on purpose -->
     <composite>


-----Original Message-----
From: David Booz [mailto:booz@us.ibm.com]
Sent: Saturday, 27. October 2007 00:18
To: sca-assembly@lists.oasis-open.org
Cc: Blohm, Henning; Martin Chapman; Michael Rowley
Subject: RE: [sca-assembly] ISSUE 6: usage of not promoted references

I agree with Mike R's comments.

I don't think we should complicate multiplicity.  In my mind, your
second
and third cases are not distinct because they occur at different points
in
the lifecycle of the composite.  I think we should assert that it is
just
not possible to detect an error in these cases until the component
owning
the reference is started/initialized/dispatched (whatever word you want
to
use, they are all the same to me).  That is, I don't think we should
attempt to support your 3rd point.

A batch deployment mechanism with special validation semantics sounds
like
an interesting vendor extension.  Since this kind of extended behavior
effectively constrains what can be successfully deployed, it doesn't
make
the app incompatible with a vendor that doesn't do batch deploy +
validation.


Dave Booz
STSM, SCA and WebSphere Architecture
Co-Chair OASIS SCA-Policy TC
"Distributed objects first, then world hunger"
Poughkeepsie, NY (845)-435-6093  or  8-295-6093
e-mail:booz@us.ibm.com
http://washome.austin.ibm.com/xwiki/bin/view/SCA2Team/WebHome




            "Peshev, Peter"

            <peter.peshev@sap

            .com>
To
                                      "Michael Rowley"
<mrowley@bea.com>,
            10/24/2007 02:00          "Martin Chapman"

            PM?                       <martin.chapman@oracle.com>,

                                      "Blohm, Henning"

                                      <henning.blohm@sap.com>, "OASIS

                                      Assembly"


<sca-assembly@lists.oasis-open.org>

cc



Subject
                                      RE: [sca-assembly] ISSUE 6: usage

                                      of not promoted references

















Hi Michael,

Thanks very much for the clarification, now  I understood what you had
in
mind.>,

Do you think that would lead to a new option for multiplicity (maybe
raised
as another issue )  ?

Since it seems we are wanting to cover 3 scenarios in case the target is
unavailable

-- error during first use of the reference (the 0..1)
-- error during first instantiation of component  (what you are
suggesting
for 1..1 in order to solve the bulk deployment for cross-referenced
components)
-- error during deployment    (1..1 in the current proposal, and what
probably many people would expect.
I.e. even if  such spec expert as you  thought for a moment this is the
1..1 meaning, than obviously the mortal guys (me & the assemblers)  may
be
thinking the same meaning as well :)


Best Regards
Peter


From: Michael Rowley [mailto:mrowley@bea.com]
Sent: Wednesday, 24. October 2007 20:32
To: Peshev, Peter; Martin Chapman; Blohm, Henning; OASIS Assembly
Subject: RE: [sca-assembly] ISSUE 6: usage of not promoted references




     From: Peshev, Peter [mailto:peter.peshev@sap.com]
     Sent: Wednesday, October 24, 2007 12:40 PM
     To: Martin Chapman; Blohm, Henning; Michael Rowley; OASIS Assembly
     Subject: RE: [sca-assembly] ISSUE 6: usage of not promoted
references

     HI Michael,

     Since the old text got too much inlined and  I am usually confused
     with that, I will try to summarize the opened sub-issues.


     - you are saying
     "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 indeed contradicts the proposal, however I have formed the
     proposal entirely based on your input to the issue on 5th of
October,
     where you have stated explicitly :

     "If the reference has a multiplicity of 1..1 or 1..n, then such an
     unresolved reference should generate a deployment error."

You got me there.  I guess I didn't concentrate very closely before on
deploy vs. runtime for this error.

     Maybe I have misunderstood you & the intention for 0..1, sorry for
     that , but that only shows  that the issue is valid and it needs
     clarification :).

     I personally believe that the initial suggestion based on your
email
     (deployment exception for unwired reference with 1..1) is better
for
     the assembler who is alarmed immediately of wiring problems at
     deployment, instead of deferring them to the first runtime
     invocation. Often applications are complex and the assembler would
     have very hard time verifying each possible path of the business
     logic (full cyclomatic complexity search) to check for such
unwired
     references and whether everything is working. That feature at
least
     to me seems more valuable than covering the use case of having A
     wired to B via reference X with 1..1, B wired to A via reference Y
     with 1..1, A is deployed as single contribution, afterwards B is
     deployed as single contribution.

     In addition if we delay the exception at runtime in the 1..1 case,
I
     am still lost what exactly is the difference between 0..1 and
1..1.
     In both cases we will allow deployment if there is no target for
the
     reference, in both cases there will be exception at runtime if the
     target is still not available, and in both cases if there is
target
     the call will pass.

The difference is that in the 1..1 case the error will be raised on the
first use of the component, not on the first use of that reference (that
way you don't have to wait until the reference is used before getting
your
NullPointerException, or whatever it is).

I'd be OK with generating the error at deployment time if we invented
some
means of doing batch deployment - to tell the system not to do its
checks
until a group of related deployments are all complete.  However, writing
up
such a mechanism would be a bit more work.

     Back to some other raised issues and raised points:

      -  I have changed the first sentence in the way you have
suggested,
     also specified  that it's neither in runtime nor in deployment
there
     will be errors. Thanks for the suggestion

Great.

      - The MUST in the last sentence is not bringing enough
information,
     very good point.  I switched it to use "will be represented" and
     added mentioning of the extensibility hooks.

I like that.


     So here is the new


     PROPOSAL :

I like the new proposal, except the fact that it creates a need for some
kind of bulk deployment mechanism, as noted above.

Michael



     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
     suggested 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 by itself
MUST
     NOT cause errors during deployment or runtime if the target of the
     reference can be identified. 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 the
     reference's wiring state will be represented in accordance to the
     implementation type in question (e.g. null, handle that throws
     exceptions when accessed,  extensibility hooks, 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, thatshouldbean
error-->
           <binding.ws/>
         </reference>
      </component>
     <!-- no references and promotion on purpose -->
     <composite>


     Best Regards
     Peter


     From: Martin Chapman [mailto:martin.chapman@oracle.com]
     Sent: Wednesday, 24. October 2007 19:24
     To: Blohm, Henning; 'Michael Rowley'; 'OASIS Assembly'
     Subject: RE: [sca-assembly] ISSUE 6: usage of not promoted
references
     do i smell some confromance targets here...what do we (abstractly)
     install and to what, and where do we deploy it?
      -----Original Message-----
      From: Blohm, Henning [mailto:henning.blohm@sap.com]
      Sent:, Wednesday, October 24, 2007 4:46 PM
      To: Michael Rowley; OASIS Assembly
      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-----
            From: Peshev, Peter [mailto:peter.peshev@sap.com]
            Sent: Wednesday, October 24, 2007 3:26 AM
            To: Michael Rowley; OASIS Assembly
            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.

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







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






________________________________





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





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