On Tue, May 5, 2009 at 4:46 PM, Raymond Feng <[email protected]> wrote: > Hi, > > There are two factors: > > 1) The extensibility for wire formats and operation selectors. We can use > the extension point and extension pattern so that wire formats or operation > selectors can be plugged in. The extension point can look up the extensions > by QName. The extensions will provide the logic to configure the binding > invocation chain (or create a list of interceptors). > > 2) Wire formats or operation selectors may introduce interceptors to > implement the logic. These interceptors need to be added to the binding > invocation chain. Two different approaches can be used: > a. The binding provider is responsible for looking up the "provider > factory" from the wireformat/operationselector extension point, calling the > extensions to create one or more interceptors (or configure the binding > invocation chain), and adding them to the invocation chain. > b. The core runtime is responsible for querying the binding to get the wire > format and operation selector and interacting with the wire format and > operation selector extensions to configure the binding invocation chain. > This is useful only if the wire format or operation selector is general to > bindings. > > a and b is not exclusive. We can start with a. If a lot of duplicate codes > start to show up from different bindings, it will be a sign that b is > needed. >
Hi At the moment, with the JMS binding, we have 1) and 2)a. We chose 2)a. as the JMS binding creates a very binding specific configuration for the binding wire. The position of the wire format and operation selector are generic however. So I agree that if we feel that there is value in the future to moving this out into generic infrastructure code (the wire) we could look at it. Simon
