[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]