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

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

Hi Mike,
 
Let me clarify the idea (sorry if I didn't do it well before),
binding.sca is always present, however it just doesn't implement the
intent SOAP (or JMS in the earlier use case)
 
So in case the assembler \ deployer  has not put any bindings and there
is SOAP intent, than the tooling \ deploy error  will say -- "Hey the
default binding.sca is not good, you need to put binding.ws".  
When the assembler fixes this, there will be both binding.ws &
binding.sca on both end of the wires , than the runtime according to the
current wiring algorithm will choose only binding.ws  as being the only
binding satisfying the intents.
 
The downside of such proposal is that in case there is some specific
intent -- SOAP, JMS, etc. the assembler \ deployer will need to put
binding.ws on both ends of the wire, but I think that's not that
frequent usecase.
 
The benefit is that by having binding.sca by default we can simplify
the most common use case  - quote - " where the component is top-level
(ie in the domain) and where some aspect of "external access" is
required.  The assembler wants to expose to the outisde world the web
service, however for any internal inter-domain wiring, the optimised
binding.sca can be used.
 
I.e. if the vendor binding.sca  can detect that let's say two components
are living on one and the same server, than it can just make a local
call between them as long as all policies are kept, there is no need to
post HTTP requests or to do any JMS messaging.

 
 
Best Regards
Peter
________________________________

From: Mike Edwards [mailto:mike_edwards@uk.ibm.com] 
Sent: Thursday, 29. November 2007 13:28
To: OASIS Assembly
Subject: RE: [sca-assembly] [NEW ISSUE] Wiring from a reference with no
binding to a service with a binding



Peter, 

<copying the list too - everyone needs to see this discussion> 

The most common case where a binding will have been applied to a
component service (or reference) is where the 
component is top-level (ie in the domain) and where some aspect of
"external access" is required.  It will not be 
uncommon for another component in the domain to also want to access the
service and it is much simpler to use 
binding.sca to make the connection.  (ie just set
@target="ComponentName/ServiceName"). 

The problem with the idea of "binding.sca is always present" is exactly
the one that you've outlined.  There are 
some cases where the requiements of the component implementation may
force the use of one binding - or 
of a subset of bindings.  A good example of where web service binding
would be needed is an implementation that uses the 
JAX-WS extended APIs for accessing SOAP headers.  SCA does not outlaw
this, but it does restrict the binding types 
that can be used. 

If you go down this road, let us assume that the requirement for a
particular binding is indicated by some intent 
- say @requires="SOAP".  Your suggestion is that if such an intent is
specified, then binding.sca is removed at 
that point and binding.ws is required to be specified.  So this implies
that "binding.sca is always present except 
when it isn't", which I don't find very satisfactory. 

There has been another criticism of the my idea of "coercing"
binding.sca to a specific binding type when the 
other end of a wire requires it.  This is in the case where a service is
declared as binding.sca and the reference 
using it specifies some specific binding like JMS or Web services.   

The argument in this case is that "coercion" of the service's
binding.sca to binding..jms for one client reference 
and then coercion of the same service to support binding.ws for another
client reference leads to multiple 
endpoints being created for the service.  This is valid, in the sense
that this would indeed imply multiple endpoints, 
but I've always bought off on the idea of binding.sca handling multiple
endpoints for a service offered via 
 binding.sca - for example, if there are local clients of the service,
I'm quite happy for those local clients to use 
direct calls to the target service, rather than going via some remoting
endpoint. 

So let's make my model clear: 

- binding.sca is only present on a service or a reference if: 
a) it is explicitly specified 
b) no binding is specified at all (ie then it is the default binding) 

- binding.sca is regarded as compatible for wiring purposes with any
other binding type, and the actual 
binding used is the binding type on the other end of the wire.  If both
ends of the wire are binding.sca then 
the runtime is free to choose the actual binding to use. 

binding.sca will be declared as supporting a particular set of intents 
if a reference or service uses intents not supported by binding.sca then
it is an error if binding.sca is used 
for that service/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 



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

28/11/2007 13:28 

	
To
	Mike Edwards/UK/IBM@IBMGB 
cc
	
Subject
	RE: [sca-assembly] [NEW ISSUE] Wiring from a reference with no
binding to a service with a binding

	




Hi Mike, 
  
Your mail leads to a  very good way to allow always binding.sca without
any side effects. 
  
In case a particular binding is mandated  by having JMS intent, than the
binding.sca will simply not implement that specific intent, and the
tooling \  deployment will say : 
   "Hey, that's not valid wiring, you have JMS intent, you should put
explicitly binding.jms on both ends of the wire) 
  
  
I am lacking your expertise and business vision, but I assume such
"hardcoded JMS" should be rare, so the nuisance for declaring
binding.jms on both end of the wires is not that big problem. 
Btw, I think at the moment that implementation.java offers no way for a
developer to gain access to the underlying binding specific objects (
JMS connection, JMS session, etc.) , so such use case (I would break
without JMS) is more theoretical. 
  
In addition I would imagine that an assembler would put a binding mainly
to expose something to the outside world and configure the exposure, and
as long as all policies are specified it's ok to have binding.sca to be
present by default for inter-domain usage. 
  
  
What do you think ? 
  
  
  
Best Regards 
Peter 

________________________________


From: Mike Edwards [mailto:mike_edwards@uk.ibm.com] 
Sent: Wednesday, 28. November 2007 13:17
To: Peshev, Peter
Subject: RE: [sca-assembly] [NEW ISSUE] Wiring from a reference with no
binding to a service with a binding


Peter, 

Thank you for pointing this out. 

I agree that these issues are closely related. 

I suggest that we should consider a single proposal to deal with both
issues. 

The question of whether "binding.sca is always present" is not quite the
same 
as "binding.sca is always compatible with any other binding type when
matching 
the two ends of a wire". 

My distinction was mentioned in my previous note  earlier this morning -

the use of a particular binding may be mandated (eg through intents)
since the 
component involved uses specific APIs that can only deal with that
binding 
(eg envisage existing code that uses the JMS APIs).  In that case, the
only 
binding that can be used for the wire is really the specified binding.


My thinking is that binding.sca on one end of the wire is regarded as
compatible 
with the mandated binding on the other end of the wire - and that the
mandated 
binding is what gets used.   

This is a bit different from the concept that binding.sca is always
present on both 
ends of the wire.  In that case, it would be possible for the SCA
runtime to use a 
binding other than the mandated one - and this would be an error.  I
think it is 
likely to be more consistent to say that the binding.sca can be matched
with 
(any) other binding type when doing wire compatibility. 

However, I realize that the distinction between the two cases is pretty
small. 


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> 

28/11/2007 10:30 

	

To
	Mike Edwards/UK/IBM@IBMGB, "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


	





Hi, 
 
when looking at the description, it seems that this is closely connected
(maybe even classified as duplicate) to the already raised ASSEMBLY-1
(http://www.osoa.org/jira/browse/ASSEMBLY-1
<http://www.osoa.org/jira/browse/ASSEMBLY-1> ),  which has the following
description : 
 
It is not clear whether presence of binding.sca can always be assumed
for internal wires, specifically when standard bindings are associated
with either end of that internal wire 
 
 
Although the suggested proposal in ASSEMBLY-1 (adding binding.sca
implicitly to each service/reference  and thus satisfying the wiring
algorithm requirements for the case "reference with no binding to a
service with a binding")  seems to be different than the currently
suggested proposal (changing the algorithm). 
 
 
 
Best Regards 
Peter 

________________________________


From: Mike Edwards [mailto:mike_edwards@uk.ibm.com] 
Sent: Tuesday, 27. November 2007 17:43
To: OASIS Assembly
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 










________________________________





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