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] [Issue 2] Inlined proposal v2


Anish Karmarkar wrote:
> Eric Johnson wrote:
>> Hi Anish,
>>
>> Anish Karmarkar wrote:
>>> Simon Nash wrote:
>>>> Anish,
>>>> As currently written, the conformance section requires that
>>>> implementations claiming support for the SCA Web Services
>>>> Callback Protocol MUST support both the "regular" flavor
>>>> defined in section 5 and the WS-MC flavor defined in section
>>>> 5.1.  I thought the intention was to give these two flavors
>>>> equal status and allow implementations to support either or
>>>> both of them.
>>>>
>>>
>>> I had thought otherwise. I.e., a runtime is required to support both. 
>>> A particular service/composite gets to choose whether it wants to use 
>>> polling or host a listener. I don't feel strongly about this, but we 
>>> should discuss as to what we would like.
>> I side with Simon here.  In the scenario where I support callbacks, I 
>> can have lots of reasons for not supporting callbacks via a polling 
>> mechanism.  To wit:
>>
>>     * Security
>>     * Latency
>>     * Bandwidth consumption
>>
>> There are other, far better ways to send messages asynchronously (JMS, 
>> SMTP, XMPP), and mandating that any implementation that supports the 
>> direct callback mechanism must also support the polling callback flies 
>> in the face of this simple technical observation.  Why would we want 
>> to mandate the use of an inferior approach?
>>
> 
> All of those actually are a form of polling as far as the client is 
> concerned with a central server in between a la WS-Polling 
> (http://www.w3.org/Submission/ws-polling/) with the third party mailbox, 
> just not polling as defined by this specific protocol. WS-Polling was a 
> precurser to WS-MC. But that is beside the point.
> 
> In any case, I did not intent to mean that this approach is mandated for 
> services that use bidirectional interfaces and binding.ws. If the words 
> don't say that then we need to fix it. But what I meant was that a 
> *runtime* that claims conformance to this feature support it. As an 
> assembler you get to choose which mechanism you want for a particular 
> service which would be advertised via the WS-MC and SCA callback policy 
> assertions.
> 
> Do you think that there needs to be two optional conformance points for 
> runtimes? One for sca callback with listener and another for sca 
> callback with ws-mc ?
> 
This sounds like the right approach to me.  The second of these
could be a delta to the first, as it's hard to imagine a runtime
that supports the second without also supporting the first.
In this case the conformance points would be:
  a) All of chapter 5 except for section 5.1
  b) All of chapter 5

   Simon

> -Anish
> -- 
> 
> 
> 




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