RE: [sca-assembly] [NEW ISSUE] Wiring from a reference with no binding to a service with a binding

["Peshev, Peter" <peter.peshev@sap.com>]

+1 on all points

 

Btw, technically we are not debating not-accepted , since we already have an open issue for "always there"

 

 

---

From: Simon Holdsworth [mailto:simon_holdsworth@uk.ibm.com]
Sent: Wednesday, 28. November 2007 13:33
Cc: OASIS Assembly
Subject: Re: [sca-assembly] [NEW ISSUE] Wiring from a reference with no binding to a service with a binding

My 2c 

Firstly I agree with Mike that there are valid use cases, 
as he describes, where this is a problem, and the current rules don't allow for 
a consumable solution (so my vote goes with it being a valid issue). 

If you don't think we should debate issues 
that are not accepted, please avert your eyes now ;-) 

My preference is to treat the SCA binding as "always 
there" rather than "don't care".   

If I was allowed to wire from a reference with a non-SCA binding to a 
service with an SCA binding, and that meant that the non-SCA binding was used, 
then the SCA runtime has to somehow generate an implicit non-SCA service binding 
that matches the reference binding.  In the general case I don't think 
that's possible.  For JMS, for instance, just because I know how a 
reference is going to send a JMS message does not mean I can deduce how a 
service is going to receive that JMS message.   And what about a JCA 
binding?  Also the runtime that is dealing with the reference may just not 
support the given service binding. 

So I'd prefer it that in this case the SCA binding is used, unless there 
are intents present that require a specific binding, in which case the wire is 
not allowed.  I believe we should always be able to derive an implicit SCA 
binding for the other end of a wire.  I don't believe we can do that for 
non-SCA bindings. 

Regards, 
Simon 

Simon Holdsworth
STSM, SCA 
Bindings Architect; Master Inventor; OASIS SCA Bindings TC Chair
MP 211, IBM 
UK Labs, Hursley Park, Winchester SO21 2JN, UK
Tel +44-1962-815059 (Internal 
245059) Fax +44-1962-816898
Internet - Simon_Holdsworth@uk.ibm.com

Mike Edwards/UK/IBM@IBMGB

28/11/2007 10:20

To	"OASIS Assembly" <sca-assembly@lists.oasis-open.org>
cc
Subject	Re: [sca-assembly] [NEW ISSUE] Wiring from a reference with no binding to a service with a binding

Simon, 

You're perfectly entitled (as is anyone else) to take 
the view that a new issue is not valid for 
any reason.  That's the thinking behind the 
process whereby anyone can raise an issue but 
it has to go through a vote before it gets 
opened. 


Anyhow, to the merits of the current issue... 
let me try to provide some motivation 
for the issue, even though I'm not the raiser of the original 
issue, but I do see the thinking 
behind it. 

One 
of the ideas within SCA is the simplification of the assembly task - simplifying 
the connection 
of 
some reference to some service.  Binding.sca is one of the tools used to 
bring simplification. 
It basically says "look, I want to connect THIS to THAT and I don't 
particularly care how it is done 
- just make the connection and satisfy any intents 
I've specified" 

Dave Booz has always taken the view (which I agree with) that this is 
the 80% case when doing 
Assembly.  Only when you're really dealing with the "outside 
world" is there a strong need to 
get into concrete bindings and the associated 
specialized endpoint addresses and other 
paraphernalia. 

Now there are cases where you can end up with 
mixtures of bindings.  So, we may have at the 
domain level a component 
A with service S1 that needs to be available externally over the 
Web Services binding.  So 
S1 is configured that way.  Along comes component B with 
reference R1 - and the assembler 
decides to connect that reference to S1 as well. 

Currently, for R1, we would have to 
configure it with a Web Services binding, with an endpoint 
URL pointing to the web service endpoint 
of A/S1.  This is a lot more complex than simply 
stating @target="A/S1" on R1.  It 
is also harder to parse after the fact. 

So, that's the real world case, I think.  The 
argument is being made that it is a great simplification 
for the Assembler NOT to have to go deal 
with the complexities of the web service binding. 
Stating binding.sca and the SCA target 
address should be enough.  The SCA runtime can 
work out the rest - yes, it would 
probably use web services under the covers (at least, if the 
components lived on different 
machines). 

Another way of stating this might be to say "binding.sca is ALWAYS 
present", except that makes 
me uncomfortable for the cases where intents are used to force the 
use of particular bindings 
where the component code is written using binding-specific APIs. 
 I prefer to go along with the 
idea that it is possible for binding.sca to be 
"coerced" to the binding of the other end of the wire. 


So, I think the issue is based 
on: 

a) current 
spec is more complex than it needs to be 

b) there is a simpler apporach for the assembler - 
and the proposal states it 



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

Simon Nash/UK/IBM@IBMGB

28/11/2007 08:35

To	"OASIS Assembly" <sca-assembly@lists.oasis-open.org>
cc
Subject	Re: [sca-assembly] [NEW ISSUE] Wiring from a reference with no binding to a service with a binding

This issue raises a general point 
about what justification is needed in 
order to open an issue.

In 
general an issue should say that something is wrong and describe what 
the 
problem is.  It may also give a proposal for a change to resolve the 
problem.  The "something is wrong" could be an error or inconsistency 
in 
the spec, or it could be a real world use case that the spec does not 
address adequately.  I don't think an issue should be raised based on 
an 
opinion that says "I don't like spec rule X and I prefer rule Y 
instead."

With this issue I don't see any clear description of what is 
wrong with 
the current spec rules.  The spec appears to be clear and 
consistent as it 
stands.  All I see is an assertion that the rule in 
the current spec 
imposes an "unreasonable requirement".

Why is this 
spec rule unreasonable?  What real world use case has a 
problem because 
of this rule?  IMO the rule is fine as it stands, and no 
change is 
needed.  However, I'm prepared to be educated on this, and if 
the rule 
is causing a problem, then we we should look at the problem and 
see what 
spec change needs to be made to resolve the problem.  The 
solution 
could be the one proposed, or there could be a different 
solution. 
 Without a clear problem statement and use case to drive the 
discussion, the debate will come down to one person's technical opinion 
against another's, which is unlikely to be productive.

  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 
27/11/2007 
15:42

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

Subject
[sca-assembly] 
[NEW ISSUE] Wiring from a reference with no binding to a 
service with a 
binding







<This issue is transferred from the 
SCA Policy TC where it was dubbed 
POLICY-34> 

RAISER  Michael 
Rowley (original) 

TARGET:  SCA Assembly Specification 

DESCRIPTION: 

The algorithm in the policy spec says that it is 
_not_ possible to wire 
from a reference that does not declare a binding 
(i.e. uses binding.sca) 
to a service that declares one or more bindings. 
However, I think this 
should be possible. 

It is an unreasonable 
requirement to say that a service with a binding can 
only be the target of a 
reference that has that same binding. The default 
binding (binding.sca) 
should be treated as the "I don't care" binding, and 
should work with any 
binding available within the domain. Or, more 
precisely, any binding that 
can satisfy the required intents. 

Section 4.8.1 of  the Policy 
frmework spec states: 

The wiring compatibility algorithm below 
determines the compatibility of a 
wire by a pairwise choice of a binding 
instance and the corresponding 
policySets on each side of the wire. 

This should be changed to the following: 

If either side of a 
wire does not specify a binding (or explicitly 
specifies binding.sca) the 
wire is considered to be valid for the purposes 
of policy processing. If 
both sides of the wire use binding.sca then the 
policies will be determined 
by the union of the required intents of both 
sides (policy sets aren't used 
with binding.sca). Otherwise, the bindings 
and policies used for the wire 
will be determined by adding the intents 
that are required by the 
binding.sca end of the wire to the other end of 
the wire and then following 
the section 4.10 algorithm in the Polcy 
Framework. 

If neither side 
of the wire uses binding.sca, then the wiring compatibilty 
algorithm below 
is used for determining compatibility. Note that there may 
be many binding 
instances present at each side of the wire. This algorithm 
determines the 
compatibility of a wire by a pairwise choice of a binding 
instance and the 
corresponding policySets on each side of the wire. 

PROPOSAL: 

The 
following should be added to the Wires section of the Assembly 
specification: 

If either end of a wire does not specify a binding 
(or explicitly 
specifies binding.sca) the wire is regarded as valid. 
 In other words, 
binding.sca is regarded as being compatible with 
any other type of binding.  Where other types of binding are applied to 
each end of a wire, compatibility of the two bindings is determined by the 
specifications for the two bindings 
involved, allied to the intent and 
policies attached at each end.  In 
general, a wire which has two 
different binding types at each end (non 
binding.sca) is likely not to be 
valid. 

If both ends of the wire use binding.sca then the policies will 
be 
determined by the union of the required intents of both ends (policy sets 
aren't used with binding.sca). 
Otherwise, where one end of the wire uses 
binding.sca, the bindings and 
policies used for the wire will be determined 
by adding the intents that 
are required by the binding.sca end of the wire 
to the other end of the 
wire and then following the algorithm defined in the 
Policy Framework 
specification section 4.10. 

If neither end of the 
wire uses binding.sca, then the wiring compatibilty 
algorithm described in 
section 4.10 of the Policy Framework specification 
is used for determining 
compatibility. Note that there may be many binding 
instances present at each 
side of the wire. This algorithm determines the 
compatibility of a wire by a 
pairwise choice of a binding instance and the 
corresponding policySets on 
each side of the wire. 


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

---

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