On Wed, Mar 5, 2008 at 6:01 AM, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
> Simon Laws wrote: > > 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. > > > > Well, I think you're raising an interesting issue, but it seems to be > independent of any of this node business, more like a general issue with > the impact of policies on specified binding URIs. I agree that if the binding URI were completed based on the processing of the "build" phase then this conversation is independent of the default values provided by nodes. This is not currently the case AFAIUI. The policy model is built and matched at build phase but the policy sets are not applied until the binding runtime is created. For example, the Axis2ServiceProvider constructor is involved in setting the binding URI at the moment. So in having an extension I was proposing a new place where binding specific operations related to generating the URI could be housed independently of the processing that happens when the providers are created. In this way we would kick off this URL processing earlier on. > > If I understand correctly, and I'm taking the store tutorial Catalog > component as an example to illustrate the issue: > > <component name="CatalogServiceComponent"> > <service name="Catalog" intents="ns:myEncryptionIntent"> > <binding.ws uri="http://somehost:8080/catalog"/> > </service> > </component> > > would in fact translate to: > > <component name="CatalogComponent"> > <service name="Catalog" intents="myEncryptionIntent"> > <binding.ws uri="https://localhost:443/catalog"/> > </service> > </component> > > assuming in this example that "myEncryptionIntent" is realized using > HTTPS on port 443. > > Is that the issue you're talking about? Yes, that's the issue, i.e. the binding specific code that makes this so is not running during the build phase. I.e. the URI isn't resolved by having a value poked in from outside the binding, rather the implications of the policy set are processed by binding specific code and the URI results. Another, non-policy related, issue has also come to mind.... <component name="CatalogComponent"> <service name="Catalog" intents="myEncryptionIntent"> <binding.ws wsdlElement=" http://test#wsdl.port(CatalogService/CatalogPort)<http://test#wsdl.port%28CatalogService/CatalogPort%29>" /> </service> </component> Particularly where where the port location is relative. Again the code that applies WSDL details to the binding URI doesn't run until activation. > -- > Jean-Sebastien > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
