Re: [sca-bindings] Issue 2 proposal v12

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

Simon Nash wrote:
> Anish Karmarkar wrote:
>> Simon Nash wrote:
>>> Anish Karmarkar wrote:
>>>> Attached.
>>>> I believe I included all the changes agreed to from last week.
>>>>
>>>> The only quibble that I have with the wordings is that it talks 
>>>> about 'binding on the reference-side'. Since this is expected to be 
>>>> used at the edges of the domain, it is preferable to not talk about 
>>>> 'references' but instead say something like 'binding on the 
>>>> client-side' or 'the invoker's binding'.
>>>>
>>> In SCA terms, it is a reference.  I think this wording is fine as is.
>>>
>>
>> It is fine if all we care about is SCA references/services using this 
>> protocol. This protocol is important not just to demonstrate that it 
>> is *possible* to do sca callbacks using WS-*, but that there is at 
>> least one interoperable/well-defined way to do this. The 
>> 'interoperable' part is important because (1) this is WS-*, where 
>> interoperability is quite important (unlike SCA where the focus is on 
>> portability), and (2) I expect this protocol to be used by non-SCA 
>> clients that want to invoke SCA services. If all the interacting 
>> parties are SCA references/services then vendors can do whatever they 
>> want. I expect that binding.sca would be used in such cases. The fact 
>> that binding.ws is being used to me means there is a need for interop 
>> with non-SCA clients.
>>
> Sorry, I overlooked this point.  However, I think that fixing it
> might need more than a one-word change.  For example, the section
> starts "An SCA runtime MAY implement...."  For a non-SCA client,
> there would be no SCA runtime involved on the client side.  Perhaps
> we could get this completed for the SCA reference and SCA service
> case, and then open another issue to extend it to non-SCA clients
> and non-SCA services (if we think the latter makes sense).
> 

The correct way IMHO would be to talk in terms of senders and receivers 
or service/client/invoker (which is how protocols are usually defined).

To beat a dead horse: we don't have anything other than SCA Runtime as 
conformance targets to use here. A separate independent spec makes a lot 
of sense for several reasons (which I have outlined before) including 
this one. I do want to enable a simple JAX-WS client (or any WS client) 
to be able to use this protocol.

Perhaps, as you suggest, a way forward is to leave this as is for now 
and raise a PR issue and deal with it there.

-Anish
--

>   Simon
> 
>>> I have some minor comments on the updated document.  Please see the
>>> attached document with these comments inline.
>>>
>>
>> Thanks. Made all the changes that were mentioned in your Word 
>> comments. Will send v13 in a separate email.
>>
>> -Anish
>> -- 
>>
>>>   Simon
>>>
>>>> -Anish
>>>> -- 
>>>>
>>>>
>>>> ------------------------------------------------------------------------ 
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe from this mail list, you must leave the OASIS TC that
>>>> generates this mail.  Follow this link to all your TCs in OASIS at:
>>>> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 
>>>
>>>
>>> ------------------------------------------------------------------------
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe from this mail list, you must leave the OASIS TC that
>>> generates this mail.  Follow this link to all your TCs in OASIS at:
>>> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 
>>
>>
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php