tuscany-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jean-Sebastien Delfino <jsdelf...@apache.org>
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 Wed, 05 Mar 2008 06:01:42 GMT
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 <jsdelfino@apache.org>
> 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.

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"/>

would in fact translate to:

<component name="CatalogComponent">
   <service name="Catalog" intents="myEncryptionIntent">
     <binding.ws uri="https://localhost:443/catalog"/>

assuming in this example that "myEncryptionIntent" is realized using 
HTTPS on port 443.

Is that the issue you're talking about?

To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org

View raw message