RE: [sca-assembly] ISSUE 5: Component type allows to specify wire targetson references: PROPOSAL

[Graham Charters <CHARTERS@uk.ibm.com>]

Hi Sanjay, 

I'm not Dave, or Mike, but I'd like
to chip in ;-) .  I think they've both covered most of the points
I would make, regarding easing adoption by making it quick to get started,
and the fact that a single person is performing multiple roles.  Regarding
your questions:

> Question: Why in the world do you need to generate
a componentType for
> this use case of 'directly deploying a fully configured implementation'?
> I thought you wanted to directly deploy a fully configured
> implementation because pointy brackets may hurt and bleed, right?
So
> just go ahead and deploy the fully configured implementation. Why
bother
> about generating a componentType (which would have pointy brackets)?

I think this comes down to how these
fully configured implementations get re-used and reconfigured in a pointy
brackets world.  Mike mentioned this in his response about not requiring
everything to be redeclared.

I think we have an opportunity here
to enable a broader community of developers, which can bring skills and
build assets to our SOA programming model.  If we don't make it a
smooth progression from the "quick-n-dirty" fully configured
world to the world of SCDL, then I think we'll be limiting the applicability
of SCA, and helping persuade the "quick-n-dirty" folks to choose
another technology.


Regards,

Graham.



Graham Charters PhD CEng MBCS CITP
SWG AB Projects
IBM United Kingdom Limited, MP 146, Hursley Park, Winchester, SO21 2JN,
UK
Tel:  (Ext) +44-1962-816527     (Int) 7-246527   (Fax)
+44-1962-818999
Internet: charters@uk.ibm.com


"Patil, Sanjay" <sanjay.patil@sap.com>
wrote on 13/03/2008 04:05:29:

> 
> Hi Dave, 
> 
> One question from my side while Mike is still sleeping ...
> 
> <Sanjay> As I said in my email below, the use case of 'fully
configured
>  implementation' does not require specifying binding/target on
> References
>  in the ComponentType. What you need is an ability for implementations
> to
>  include information that would otherwise be part of deployable
> composites,
>  and this issue belongs to the C&I specifications, IMO. </Sanjay>)
> <dab> If you had such an implementation and then generated a
> componentType
> from it, would it not look exactly as this proposal describes? </dab>
> 
> Question: Why in the world do you need to generate a componentType
for
> this use case of 'directly deploying a fully configured implementation'?
> I thought you wanted to directly deploy a fully configured
> implementation because pointy brackets may hurt and bleed, right?
So
> just go ahead and deploy the fully configured implementation. Why
bother
> about generating a componentType (which would have pointy brackets)?
> 
> -- Sanjay
> 
> > -----Original Message-----
> > From: David Booz [mailto:booz@us.ibm.com] 
> > Sent: Wednesday, Mar 12, 2008 20:26 PM
> > To: sca-assembly@lists.oasis-open.org
> > Subject: RE: [sca-assembly] ISSUE 5: Component type allows to
> > specify wire targets on references: PROPOSAL
> > 
> > some quick answers while Mike is sleeping.....<dab> like
this </dab>
> > 
> > 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
> > 
> > 
> >                  
                     
                     
> >              
> >              "Patil,
Sanjay"                  
               
> >              
> >              <sanjay.patil@sap
                     
         
> >              
> >              .com>  
                     
                   
> >           To 
> >                  
                     "Mike
Edwards"         
> >              
> >              03/12/2008 05:43
         
> > <mike_edwards@uk.ibm.com>, "OASIS   
> >              PM    
                   Assembly"
             
> >              
> >                  
                     
> > <sca-assembly@lists.oasis-open.org> 
> >                  
                     
                     
> >           cc 
> >                  
                     
                     
> >              
> >                  
                     
                     
> >      Subject 
> >                  
                     RE:
[sca-assembly] 
> > ISSUE 5:         
> >                  
                     Component
type allows 
> > to specify    
> >                  
                     wire
targets on 
> > references:         
> >                  
                     PROPOSAL
              
> >              
> >                  
                     
                     
> >              
> >                  
                     
                     
> >              
> >                  
                     
                     
> >              
> >                  
                     
                     
> >              
> >                  
                     
                     
> >              
> >                  
                     
                     
> >              
> > 
> > 
> > 
> > 
> > comments/questions inline ...
> > 
> >  From: Mike Edwards [mailto:mike_edwards@uk.ibm.com]
> >  Sent: Wednesday, Mar 12, 2008 4:42 AM
> >  To: OASIS Assembly
> >  Subject: RE: [sca-assembly] ISSUE 5: Component type allows
> > to specify wire
> >  targets on references: PROPOSAL
> > 
> > 
> >  Folks,
> > 
> >  I'm finding it very hard to understand the logic behind
the proposals
> >  below.  They seem to complicate the SCA model for
no reason.
> > 
> >  The proposal that I favour I think is a very simple one,
> > that fits in well
> >  with the current structure of SCA and requires no new or
special
> >  constructs.  Basically, the model I see is one where
an 
> > implementation has
> >  a componentType.   The componentType represents
> >  the configurable aspects of the implementation - services,
> > references,
> >  properties and the implementation itself (in the sense
that
> >  intents and policies can be configured on the implementation).
> >  <Sanjay>
> >  I think there is a distinction to be drawn between the
> > configuration of
> >  Services/References and that of Properties. The declaration
of
> >  Services/References by an implementation is in terms of
business
> >  interfaces  (and intents, if necessary) and a typical
implementation
> >  developer would rather keep the code independent of the
> > binding/target
> >  used by the Services/References (isn't that  one of
the main value
> >  propositions of SCA!). In other words, all the configurable
> > aspects of
> >  Services/References are not within the purview of the implementation
> >  developer. OTOH, an implementation developer must understand
> > the entire
> >  structure of Properties, the range of possible values that
may be
> >  specified by the users of that implementation, etc.
> > 
> >  With the above distinction in mind, it would seem natural
for
> >  implementations to provide defaults for Properties, but
> > providing defaults
> >  for bindings/targets for Services/References in the 
> > implementations would
> >  be meddling with other roles (e.g. Deployer).
> >  </Sanjay>
> >  <dab> In general, I agree very strongly with your
> > distinction.  However,
> >  the proposal is specifically and explicitly setting that
> > aside to enable
> >  some use cases which are not part of the general usage.
 
> > This is about
> >  enabling early adopters who are a) technically advanced
(and 
> > therefore can
> >  also see that they are trampling on the distinction you
are 
> > making) and b)
> >  are trying to dig in and get something running quickly.
 Dogmatically
> >  forcing them into the general case will inhibit adoption.
 
> > I'm usually the
> >  one that cries "simplicity first" when we start
straying out 
> > of the 80%
> >  use cases.  FWIW, I think this case is worth enabling
because it will
> >  foster adoption of the technology. </dab>
> > 
> > 
> >  I see it as being a very simple idea that the configurable
> > aspects of an
> >  implementation may have default values for any of those
> >  aspects.
> >  <Sanjay> I disagree with this generalization. See
my 
> > previous comment.
> >  </Sanjay>
> > 
> >  - That value can apply to a Property by the property having
> > some value
> >  defined by the implementation.
> >  - For a service, the default value may be a specific binding
and a
> >  relative URI
> >  - For a reference, the default value may include a specific
> > binding and/or
> >  a specific target for the reference, (some URI)
> >  <Sanjay> By configuring a Property of an implementation,
you 
> > are effecting
> >  certain behavior/update that is confined to that 
> > implementation. OTOH, by
> >  configuring a Reference with target/binding value, you
are providing
> >  details which the implementation does not care about. </Sanjay>
> >  <dab> Agree, but this is about the implementor being
able to 
> > play all the
> >  roles in a quick and easy manner.  This is not about
a clean
> >  implementation, </dab>
> > 
> >  When an implementation is used within a component, then
the 
> > component can
> >  decide to configure any or all of the configurable
> >  aspects of the implementation.  This is true whether
or not there are
> >  default values for those aspects.  The component can
get
> >  exactly what it wants, for properties, for references and
> > for services
> >  (other than any intents, of course, which cannot be overridden).
> > 
> >  The neat thing about defaults, is that if the component
> > writer is OK with
> >  the defaults present in the implementation, then it cuts
down
> >  the work required to configure the component - the component
> > can simply
> >  use the default values.
> >  <Sanjay> You still need to check if the component
writer is 
> > OK with the
> >  defaults. That is not such a neat thing IMO. The component
> > writer now has
> >  to exercise extra caution in checking defaults for aspects
> > that he/she
> >  would not have expected.</Sanjay>
> >  <dab> It's the same person in this case. </dab>
> > 
> >  I see the "completely configured implementation"
as only an 
> > extreme case
> >  of these ideas - ie an implementation where all the
> >  configurable aspects have default values supplied, so that,
> > in effect *no*
> >  configuration is required from the using component
> >  in order for the component to work.
> >   <Sanjay> Don't you need to 'promote' the component
> > Services/References in
> >  order to make them visible at the SCA Domain level? <Sanjay>
> >  <dab> No, absolutely not....this is really an argument
for 
> > another day
> >  (and another thread) and I'll not go further here. </dab>
> > 
> >  This has the happy side effect of allowing a particular
use 
> > case to work
> >  very neatly.  This is the "zero effort deployment"
scenario,
> >  where an implementation artifact such as a Java class or
a 
> > PHP script can
> >  be given to a (suitable) runtime and that runtime can
> >  instantiate the implementation as a domain-level component
> > without the
> >  need for any further effort (ie no need to separately
> >  supply deployment metadata), since everything necessary
is 
> > defined in the
> >  implementation artifact.  The runtime would still
> >  in SCA terms be creating a deployment time composite for
that new
> >  component, but its contents are "trivial" in
the sense that
> >  all that is required is a component element with a name,
using the
> >  supplied implementation.
> >   <Sanjay> As I said in my email below, the use case
of 
> > 'fully configured
> >  implementation' does not require specifying binding/target
> > on References
> >  in the ComponentType. What you need is an ability for 
> > implementations to
> >  include information that would otherwise be part of 
> > deployable composites,
> >  and this issue belongs to the C&I specifications, IMO.
</Sanjay>)
> > <dab> If you had such an implementation and then generated
a 
> > componentType
> > from it, would it not look exactly as this proposal describes?
</dab>
> > 
> >  I note that no-one is required to build a runtime that
works 
> > this way.  A
> >  runtime can insist on the deployment of contributions
> >  that do contain composites.  On the other hand, I'd
prefer to see it
> >  possible to create a runtime that does not require such
> >  metadata.
> >  <Sanjay> I disagree. Supporting your proposal would
at the 
> > minimum require
> >  that a compliant assembly design time tool be aware of
> > defaults in the
> >  implementations/ComponentType-side-files. </Sanjay>
> >  <dab> l think we could make those elements optional
> > compliance points.
> >  </dab>
> > 
> >  Doing this in no way runs against the principles of SCA
- 
> > and requires no
> >  changes to the model either.  If a using component
> >  wants to use the same "fully configured implementation"
in a 
> > new way, it
> >  is free to do so by configuring the implementation in
> >  whatever way it chooses.  Simply supply a composite
with a component
> >  containing the necessary configuration data.
> >   <Sanjay> I would personally favor a simple model
where by - 
> > a> when a
> >  'fully configured implementation' is directly deployed,
 its 'full
> >  configuration' is utilized as intended, b> when a 'fully
configured
> >  implementation' is  used by a component (a corner
case), the 
> > deployment
> >  specific configuration coming from that implementation
is 
> > ignored (as it
> >  was really not intended for this case). </Sanjay>
> >  <dab> ah...a ray of light. This would make a fully
configued 
> > composite
> >  (which is an implementation) different from a fully configured
Java
> >  implementation. </dab>
> > 
> >  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
> > 
> >                  
                     
                     
> >              
> >  "Patil, Sanjay"          
                     
             
> >              
> >  <sanjay.patil@sap.com>        
                     
        
> >              
> >                  
                     
                     
> >              
> >                  
                     
                     
> >           To 
> >  11/03/2008 18:50            
    Mike Edwards/UK/IBM@IBMGB, 
> > "OASIS        
> >                  
                Assembly"
                  
> >              
> >                  
                
> > <sca-assembly@lists.oasis-open.org>      
> >                  
                     
                     
> >           cc 
> >                  
                     
                     
> >              
> >                  
                     
                     
> >      Subject 
> >                  
                RE: [sca-assembly]
ISSUE 5: 
> > Component    
> >                  
                type allows to
specify wire 
> > targets on   
> >                  
                references: PROPOSAL
       
> >              
> >                  
                     
                     
> >              
> >                  
                     
                     
> >              
> >                  
                     
                     
> >              
> >                  
                     
                     
> >              
> >                  
                     
                     
> >              
> >                  
                     
                     
> >              
> >                  
                     
                     
> >              
> > 
> > 
> > 
> > 
> > 
> > 
> >  I am guessing that the rationale behind the following 
> > proposal to close
> >  the Issue 5 with no-action is - to allow for direct deployment
of
> >  implementation artifacts without requiring creation of
any 
> > SCDL files,
> >  etc. Assuming that as the target use case ....
> > 
> >  I would like to note that supporting the above use case
does 
> > not depend
> >  upon inclusion of deployment specific configuration (e.g.
> > wire targets on
> >  references) in the ComponentType, since a simple solution
to 
> > meet the use
> >  case would be to embed the deployment specific configuration
> > directly in
> >  the implementation artifacts. Now an interesting question
to 
> > answer would
> >  be - Is there a language-neutral SCA construct to represent
> > the deployment
> >  specific configuration embedded in the implementation 
> > artifacts? Here are
> >  some of the possible answers IMO -
> > 
> >  a> None - there is no need to separately represent the
embedded
> >  configuration data as an SCA construct, since the goal
of 
> > the use case is
> >  to avoid creation of any SCDL files, etc.
> >  b> Composite  - Since the SCA model expects that
it is a 
> > Composite that
> >  gets deployed to an SCA domain, it logical follows that
the 
> > SCA construct
> >  to represent the deployment specific configuration embedded
in an
> >  implementation artifact would also be a Composite (and
not 
> > ComponentType)
> > 
> >  So if at all we wanted to have an SCA construct that reflects
the
> >  deployment specific configuration in a directly deployable
> > implementation,
> >  we should focus on defining a mapping between a Composite
and the
> >  implementation. Mapping of deployment specific configuration
> > embedded in
> >  implementation artifacts to ComponentType is not necessary,
> > and if allowed
> >  for whatever reasons, there are potential downsides as
> > documented in the
> >  issue text [1].
> > 
> >  In essence, I propose that we resolve Issue-5 by adopting
> > the proposal
> >  specified in the issue text, which says: Change the schema
> > so that wire
> >  targets cannot be specified.
> > 
> >  Thanks,
> >  Sanjay,
> > 
> > 
> >  [1] http://osoa.org/jira/browse/ASSEMBLY-5
> > 
> >  From: Mike Edwards [mailto:mike_edwards@uk.ibm.com]
> >  Sent: Tuesday, Feb 12, 2008 4:12 AM
> >  To: OASIS Assembly
> >  Subject: [sca-assembly] ISSUE 5: Component type allows
to 
> > specify wire
> >  targets on references: PROPOSAL
> > 
> > 
> >  Folks,
> > 
> >  PROPOSAL:  Close Issue 5 with no action.
> > 
> >  This permits the component type of a component to contain
> > wire targets on
> >  references.
> > 
> > 
> >  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
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > ---------------------------------------------------------------------
> > 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_workgr
> > oups.php 
> > 
> > 
> 
> ---------------------------------------------------------------------
> 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