Re: [sca-bindings] question on priority of solving issue bindings02

[Anish Karmarkar <Anish.Karmarkar@oracle.com>]

Eric Johnson wrote:
> Hi Anish,
> 
> Anish Karmarkar wrote:
>> Eric Johnson wrote:
>>> Hi Tom,
>>>
>>> Tom Rutt wrote:
>>>> During the call on 4/2 we gave the following priority for resolving
>>>> bindings 2
>>>>
>>>> *Ashok:* BINDINGS-2 -- Top on nice-to-have pile
>>>>
>>>> I am a little confused.  I thought that Anish proposal was for an
>>>> optional
>>>> but normative protocol for use with the wsdl binding.
>>>>
>>>> If we do not have at least one normative way to do callbacks, how
>>>> can we say the wsdl binding of sca supports bidir interfaces?
>>> I'm confused by your question.  We don't necessarily have to have any
>>> normative ways to do it, so long as we, collectively as a TC, have
>>> each convinced ourselves that it is possible to have at least one.
>>>
>> I think this goes beyond just convincing ourselves that it is
>> possible. IIRC, we did agree on defining a normative but optional
>> protocol. Perhaps we are interpreting the term 'normative' in
>> different ways.
> I fully agree that we should be doing this, I was merely trying to
> explain why I go along with the assessment that it is "nice-to-have",
> rather than essential.

I agree as well if it relates to getting to PR.

>>> Is your question really whether:
>>>
>>>    1. It is sufficient to have an SCA runtime work with itself
>>>    2. Or whether we need interoperability with other possible SCA
>>> runtimes
>>>
>>> I think we all agree that #1 is required, but that doesn't need to
>>> indicate how it is achieved.
>> Right, SCA runtime vendors can figure out how to interoperate with
>> themselves ;-)
>> For that we already have binding.sca.
> There are many reasons for wanting to use SOAP over HTTP that have
> nothing to do with the endpoints, and everything to do with what happens
> in the middle.  So even if we only successfully do callbacks with
> ourselves, our customers may want that to happen via SOAP/HTTP.  So I
> don't think "binding.sca" is the same thing as binding.ws in this case.

But you can do SOAP/HTTP using binding.sca. binding.sca says use your 
secret sauce/secret handshake. There is nothing that says that the 
secret handshake can't be a well-know protocol.
Perhaps you mean that the customers would rather do this using 
binding.ws then some Tibco specific config/extension. I.e., it is not 
about interop or portability, it is the reuse of well-known config elements.

>>> For #2, it is useful, but probably not sufficient, to have also
>>> specified what is going into the resolution for bindings-2.  I say it
>>> probably isn't sufficient, only in that SOAP interoperability seems
>>> to have all sorts of corner cases.
>> What is it that is needed beyond the protocol, policy assertion and
>> wsdl extension (to indicate the callback contract)?
> Sorry, didn't mean to impugn the work you've done so far.  I was making
> vague nods to the difficulties of getting business-logic level
> compatibility to work, given the enormous number of pieces and leaky
> abstractions between two business endpoints.

I most certainly agree. In WS-I BP WG we used to say that we don't solve 
interop problems or make it easy to interop but that we increase the 
chances of interop if you follow the profile.

> 
>> BTW, I'm not worried about 2 SCA runtimes interoping, but defining
>> necessary and sufficient things for a non-SCA client to invoke a SCA
>> bidirectional interface. Of course if we solve that problem we would
>> have solved the issue of interop between 2 SCA runtimes.
> I believe I understand your perspective.  My perspective is just about 2
> SCA runtimes, though.  If it happens to work outside of that, how lucky
> we are.
> 
> -Eric.
>