tuscany-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Simon Laws" <simonsl...@googlemail.com>
Subject Re: Investigating assignment of endpoint information to the domain model was: Re: Domain/Contribution Repository was: Re: SCA contribution packaging schemes: was: SCA runtimes
Date Mon, 03 Mar 2008 22:26:49 GMT
Thanks Sebastien, Hopefully some insight on the puzzle in line...


On Mon, Mar 3, 2008 at 9:57 PM, Jean-Sebastien Delfino <jsdelfino@apache.org>

> 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.


> 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 ...>
    <binding.ws uri="http://localhost:1234/services"/>

    <binding.jsonrpc uri="http://localhost:1234/services"/>
    <binding.atom uri="http://localhost:9999/services"/>

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.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message