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 Fri, 07 Mar 2008 04:26:49 GMT
Simon Laws wrote:
> On Wed, Mar 5, 2008 at 6:01 AM, Jean-Sebastien Delfino <jsdelfino@apache.org>
> 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 <
>> 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.
> 
> 
> 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.
> 

OK (taking the policy processing aside), you're right that the 
determination of the binding URI should not be done at all in the 
Axis2ServiceProvider.

I would suggest the following:

- Recognize that this is a manifestation of a bigger issue (and the code 
in Axis2ServiceProvider a hack to work around it). There is no extension 
point for build-time processing of models at the moment. We have plug 
points for read(), resolve() but nothing for build().

- Add a build(<T> model) method to ArtifactProcessor<T>.

- Invoke that method from CompositeBuilder() or one the related classes 
in the builder package.

- Move the code responsible for the determination of the URI of a 
binding to ArtifactProcessor.read(), resolve(), build() or a combination 
of these as most convenient.

- Review the current policy processing and make sure that policies are 
processed in the right stages, I won't discuss this here as I believe 
that there's another discussion on policy applications currently going 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.

OK, so we need to move the policy processing code to the proper 
composite build stage, and make sure that the build code that will 
determine the binding URI - for example in ArtifactProcessor.build() or 
another similar extension point - is able to at the policies attached to 
the binding.

However, IMO this still has nothing to do with the node configuration. 
Node configuration can be used to provide default values, before the 
build process kicks in, like if the application developer had written 
these default values in the <binding> in the composite file himself.

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

Yes, same issue here, this code should run at model build time.

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


-- 
Jean-Sebastien

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


Mime
View raw message