ISSUE-31: Wiring from a reference with no binding to a service with abinding

[Mike Edwards <mike_edwards@uk.ibm.com>]

Dave,

Comment inline.

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

David Booz <booz@us.ibm.com> wrote on 04/12/2007
15:07:11:

> Picking out only one part of your reply:
> 
> Dave said:
> > binding.sca will be declared as supporting a particular set of
intents
> > <dab> I assume this is done through the bindingTypes declaration
> > so that vendors can decide what intents they want their binding.sca
> > implementation
> >  to support.</dab>
> Mike said:
> I hadn't thought of it like that - I thought that the specifications
would
> simply lay down a list of supported intents.  However, I can
see the merits
> 
> of an approach like the one you describe.  The downside is that
binding.sca
> 
> would mean different things on different vendors runtimes.
> 
> I think this is fundamentally important. binding.sca is already not
> interoperable across vendors for very important reasons.  I see
no reason
> to constrain the intents that binding.sca supports, in the same way
that we
> should not constrain the intents supported by any other binding.  This
is
> an appropriate place for vendor freedom and for community/industry
> involvement over time to fine tune the important aspects of the standard.
> We're only on v1 right now.

My concern is not interoperability but rather portability.
 If binding.sca
supports different intents on different runtimes,
it will make composites
hard to port.

Flexibility is good until it starts to cause problems.

> 
>

---

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