OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

sca-bindings message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

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

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

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


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]