Thanks Sebastien, Hopefully some insight on the puzzle in line... Simon
On Mon, Mar 3, 2008 at 9:57 PM, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote: > I apologize in advance for the inline comment puzzle, but you had > started with a long email in the first place :) no problem at all. Thanks for you detailed response. snip... > I'm happy with workspace.configuration.impl. However applying default > binding configuration to bindings in a composition doesn't have much to > do with the workspace so I'd suggest to push it down to assembly, > possible if you use a signature like I suggested above. Ok I can do that. > > > > > B) The algorithm (A) that calculates service endpoints based on node > default > > binding configurations depends on knowing the protocol that a particular > > binding is configured to use. > > That part I don't get :) We could toy with the idea that SCA bindings > are not the right level of abstraction and that we need a transport > concept (or scheme or protocol, e.g. http) and the ability for multiple > bindings (e.g. ws, atom, json) to share the same transport... But that's > a whole different discussion IMO. > > Can we keep this simply on a binding basis? and have a node declare this: > > <component ...> > <implementation.node ...> > <service...> > <binding.ws uri="http://localhost:1234/services"/> > <binding.jsonrpc uri="http://localhost:1234/services"/> > <binding.atom uri="http://localhost:9999/services"/> > </component> > > Then the <binding.ws uri=...> declaration can provide the default config > for all binding.ws on that node, <binding.jsonrpc> for all binding.json, > <binding.atom> for all binding.atom etc. As you can see in this example, > different bindings could use different ports... so, trying to share a > common transport will probably be less functional if it forces the > bindings sharing that transport to share a single port. This is OK until you bring policy into the picture. A policy might affect the scheme a binding relies on so you may more realistically end up with.. <component ...> <implementation.node ...> <service...> <binding.ws uri="http://localhost:1234/services"/> <binding.ws uri="https://localhost:443/services<http://localhost:1234/services>"/> <binding.jsonrpc uri="http://localhost:1234/services"/> <binding.atom uri="http://localhost:9999/services"/> </component> And any particular, for example, binding.ws might required to be defaulted with "http://...";, "https://.."; or even not defaulted at all if it's going to use "jms:...". The issue with policies of course is that they are not, currently, applied until later on when the bindings are actually activated. So just looking at the model you can tell it has associated intents/policy but not what the implications are for the endpoint. We can ignore this in the first instance I guess and run with the restriction that you can't apply policy that affects the scheme to bindings inside the domain. But I'd be interested on you thoughts on the future solution none the less. You will notice from the code that I haven't actually done anything inside the bindings but just proposed that we will have to ask binding specific questions at some point during URL creation.
