You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Simon Laws <si...@googlemail.com> on 2008/03/03 19:28:04 UTC
Re: Investigating assignment of endpoint information to the domain model was: Re: Domain/Contribution Repository was: Re: SCA contribution packaging schemes: was: SCA runtimes
On Thu, Feb 28, 2008 at 5:50 PM, Simon Laws <si...@googlemail.com>
wrote:
>
>
> On Tue, Feb 26, 2008 at 5:49 PM, Simon Laws <si...@googlemail.com>
> wrote:
>
> >
> >
> > On Tue, Feb 5, 2008 at 8:34 AM, Jean-Sebastien Delfino <
> > jsdelfino@apache.org> wrote:
> >
> > > Venkata Krishnan wrote:
> > > > It would also be good to have some sort of 'ping' function that
> > > could be
> > > > used to check if a service is receptive to requests. Infact I
> > > wonder if the
> > > > Workspace Admin should also be able to test this sort of a ping per
> > > > binding. Is this something that can go into the section (B) .. or
> > > is this
> > > > out of place ?
> > > >
> > >
> > > Good idea, I'd put it section (D). A node runtime needs to provide a
> > > way
> > > to monitor its status.
> > >
> > > --
> > > Jean-Sebastien
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> > > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> > >
> > > Hi Sebastien
> >
> > I see you have started to check in code related to steps A and B. I have
> > time this week to start helping on this and thought I would start looking at
> > the back end of B and moving into C but don't want to tread on you toes.
> >
> > I made some code to experiment with before I went on holiday so it's not
> > integrated with your code (it just uses the Workspace interface). What I was
> > starting to look at was resolving a domain level composite which includes
> > unresolved composites. I.e. I built a composite which includes the
> > deployable composites for a series of contributions and am learning about
> > resolution and re-resolution.
> >
> > I'm not doing anything about composite selection for deployment just
> > yet. That will come from the node model/gui/command line. I just want to
> > work out how we get the domain resolution going in this context.
> >
> > If you are not already doing this I'll carry on experimenting in my
> > sandbox for a little while longer and spawn of a separate thread to discuss.
> >
> > Simon
> >
> >
> > And here's the separate thread following on from [1]... I'm looking at
> what we can do with any endpoint information we have prior to the point at
> which a composite is deployed to a node. This is an alternative to
> (replacement for?) having the Tuscany runtime go and query for endpoint
> information after it has been started. I have been summarizing info here
> [2][3]. Looking at this I need to do something like...
>
> - associate composites with nodes/apply physical binding
> defaults/propagate physical addresses based on domain level wiring
>
> 1. Read in node model - which provides
> 1. Mapping of composite to node
> 2. Default configuration of bindings at that node, e.g. the
> root URL required for binding.ws
> 2. For each composite in the domain (I'm assuming I have access to
> the domain level composite model)
> 1. Find, from the node model, the node which will host the
> composite
> 2. for each service in the composite
> 1. If there are no bindings for the service
> 1. Create a default binding configured with the
> default URI from the node model
> 2. We maybe should only configure the URI if we
> know there is a remote reference.
> 2. else
> 1. find each binding in the service
> 1. Take the default binding configuration
> and apply it to the binding
> 2. What to do about URLs as they may be
> either
> 1. Unset
> 1. Apply algorithm from Assembly
> Spec 1.7.2
> 2. Set relatively
> 1. Apply algorithm from Assembly
> Spec 1.7.2
> 3. Set absolutely
> 1. Assume it is set correctly?
> 4. Set implicitly (from WSDL
> information)
> 1. Assume it is set correctly?
> 3. The above is similar to what goes
> during compositeConfiguration in the build phase
> 3. For each reference in the composite
> 1. Look for any targets that cannot be satisfied within
> the current node (need an interface to call through which scans the domain)
> 2. Find the service model for this target
> 3. Do policy and binding matching
> 4. For matching bindings ensure that the binding URL is
> unset and set with information from the target service
> 5. The above is also similar to what happens during the
> build phase
> 4. Domain Level Autowiring also needs to be taken into
> account
> 5. Wire by impl that uses domain wide references also need to
> be considered
>
> Referring to the builder code now is feels like 2.2 above is a new "model
> enhancement" step that could reuse (some of) the function in
> CompositeConfigurationBuilderImpl.configureComponents but with extra
> binding specific feature to ensure that URLs are set correctly.
>
> 2.3 looks very like CompositeWireBuilder.
>
> My quandry at the moment is that the process has a dependency on the node
> description so it doesn't fit in the builders where they are at the moment.
> It feels like we need a separate module. So comments about whether any of
> this makes sense and, if so, where I should put it are welcome.
>
> Simon
>
> [1] http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg28299.html
> [2]
> http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Contribution+Processing
> [3] http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Runtime+Phases
>
I have some code [1] for steps 1, 2.1 and 2.2 above and I want to move it
out of my sandbox to see how it fits. Two questions
A) I have a relatively stand alone algorithm [2] that populates service
binding URIs (similar to the CompositeConfigurationBuilder and I would like
to combine the two in the future) and am assuming for now that it will slot
into o.a.t.s.workspace.configuration.imp. Anyone not happy with that please
speak up.
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. As this is a result of a binding
configuration, based on binding, interfaces descritions, policy I have taken
the approach of creating a new extension point, BindingURICalculator [3],
which will hold this and probably other binding specific function related to
URI calculation. I want to check that there isn't somewhere else that people
think this function should live.
Am writing tests at the moment so you have time to comment before I do move
out of my sandbox.
Thanks
Simon
[1]
http://svn.apache.org/repos/asf/incubator/tuscany/sandbox/slaws/modules/domain-rework/
[2]
http://svn.apache.org/repos/asf/incubator/tuscany/sandbox/slaws/modules/domain-rework/src/main/java/org/apache/tuscany/sca/workspace/configuration/impl/NodeAssigner.java
[3]
http://svn.apache.org/repos/asf/incubator/tuscany/sandbox/slaws/modules/domain-rework/src/main/java/org/apache/tuscany/sca/binding/BindingURICalculator.java
Re: Investigating assignment of endpoint information to the domain
model was: Re: Domain/Contribution Repository was: Re: SCA contribution packaging
schemes: was: SCA runtimes
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Simon Laws wrote:
> On Wed, Mar 5, 2008 at 12:52 PM, Simon Laws <si...@googlemail.com>
> 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.
>>
>>
>>> 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: tuscany-dev-unsubscribe@ws.apache.org
>>> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>>
>>>
> So disregarding how we do binding specific URI processing at this build
> stage, which is still an issue IMO, I've checked in some new code in the
> CompositeConfigurationBuilderImpl that calculates service binding URIs. I've
> not hooked it up to anything yet so it's not running except through the
> JUnit test I added.
>
> I would like to use this code during the build phase proper so that we only
> have binding URI generation happening in one place. In due course I'll
> switch over to it.
+1 from me.
I'll also look at how we do the binding specific bits
> once we have agree here what needs to be done.
>
> Now to make it work with Sebastien's workspace code.
>
> Simon
>
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Investigating assignment of endpoint information to the domain model was: Re: Domain/Contribution Repository was: Re: SCA contribution packaging schemes: was: SCA runtimes
Posted by Simon Laws <si...@googlemail.com>.
On Wed, Mar 5, 2008 at 12:52 PM, Simon Laws <si...@googlemail.com>
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.
>
>
> >
> > 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: tuscany-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >
> >
>
So disregarding how we do binding specific URI processing at this build
stage, which is still an issue IMO, I've checked in some new code in the
CompositeConfigurationBuilderImpl that calculates service binding URIs. I've
not hooked it up to anything yet so it's not running except through the
JUnit test I added.
I would like to use this code during the build phase proper so that we only
have binding URI generation happening in one place. In due course I'll
switch over to it. I'll also look at how we do the binding specific bits
once we have agree here what needs to be done.
Now to make it work with Sebastien's workspace code.
Simon
Re: Investigating assignment of endpoint information to the domain
model was: Re: Domain/Contribution Repository was: Re: SCA contribution packaging
schemes: was: SCA runtimes
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Simon Laws wrote:
> On Wed, Mar 5, 2008 at 6:01 AM, Jean-Sebastien Delfino <js...@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
Re: Investigating assignment of endpoint information to the domain model was: Re: Domain/Contribution Repository was: Re: SCA contribution packaging schemes: was: SCA runtimes
Posted by Simon Laws <si...@googlemail.com>.
On Wed, Mar 5, 2008 at 6:01 AM, Jean-Sebastien Delfino <js...@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.
>
> 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: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
Re: Investigating assignment of endpoint information to the domain
model was: Re: Domain/Contribution Repository was: Re: SCA contribution packaging
schemes: was: SCA runtimes
Posted by Jean-Sebastien Delfino <js...@apache.org>.
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 <js...@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"/>
</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?
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Investigating assignment of endpoint information to the domain model was: Re: Domain/Contribution Repository was: Re: SCA contribution packaging schemes: was: SCA runtimes
Posted by Simon Laws <si...@googlemail.com>.
Thanks Sebastien, Hopefully some insight on the puzzle in line...
Simon
On Mon, Mar 3, 2008 at 9:57 PM, Jean-Sebastien Delfino <js...@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.
Re: Investigating assignment of endpoint information to the domain
model was: Re: Domain/Contribution Repository was: Re: SCA contribution packaging
schemes: was: SCA runtimes
Posted by Jean-Sebastien Delfino <js...@apache.org>.
I apologize in advance for the inline comment puzzle, but you had
started with a long email in the first place :)
Simon Laws wrote:
>>> And here's the separate thread following on from [1]... I'm looking at
>> what we can do with any endpoint information we have prior to the point at
>> which a composite is deployed to a node. This is an alternative to
>> (replacement for?) having the Tuscany runtime go and query for endpoint
>> information after it has been started. I have been summarizing info here
>> [2][3]. Looking at this I need to do something like...
>>
>> - associate composites with nodes/apply physical binding
>> defaults/propagate physical addresses based on domain level wiring
>>
>> 1. Read in node model - which provides
>> 1. Mapping of composite to node
>> 2. Default configuration of bindings at that node, e.g. the
>> root URL required for binding.ws
+1
>> 2. For each composite in the domain (I'm assuming I have access to
>> the domain level composite model)
>> 1. Find, from the node model, the node which will host the
>> composite
>> 2. for each service in the composite
>> 1. If there are no bindings for the service
>> 1. Create a default binding configured with the
>> default URI from the node model
Create a <binding.sca> configured with the URI found on the
<binding.sca> from the node configuration. Same as your else branch
"Take the default binding configuration and apply it to the binding".
>> 2. We maybe should only configure the URI if we
>> know there is a remote reference.
Maybe later :) I think that always configuring the URI for now is better
than starting to couple binding configuration with reference resolution.
>> 2. else
>> 1. find each binding in the service
>> 1. Take the default binding configuration
>> and apply it to the binding
+1
>> 2. What to do about URLs as they may be
>> either
>> 1. Unset
>> 1. Apply algorithm from Assembly
>> Spec 1.7.2
+1
>> 2. Set relatively
>> 1. Apply algorithm from Assembly
>>
Spec 1.7.2
+1
>> 3. Set absolutely
>> 1. Assume it is set correctly?
Yes
>> 4. Set implicitly (from WSDL
>> information)
>> 1. Assume it is set correctly?
>> 3. The above is similar to what goes
>> during compositeConfiguration in the build phase
+1
>> 3. For each reference in the composite
>> 1. Look for any targets that cannot be satisfied within
>> the current node (need an interface to call through which scans the domain)
>> 2. Find the service model for this target
>> 3. Do policy and binding matching
>> 4. For matching bindings ensure that the binding URL is
>> unset and set with information from the target service
>> 5. The above is also similar to what happens during the
>> build phase
>> 4. Domain Level Autowiring also needs to be taken into
>> account
>> 5. Wire by impl that uses domain wide references also need to
>> be considered
IMO (3), (4), (5) should be taken completely separately. Resolution of
references inside a node, across nodes, or when nodes provide default
binding configuration or not can just always work the same way:
a) find the target service inside the set of composites included in the
domain
b) configure the reference from the resolved service configuration.
>> Referring to the builder code now is feels like 2.2 above is a new "model
>> enhancement" step that could reuse (some of) the function in
>> CompositeConfigurationBuilderImpl.configureComponents but with extra
>> binding specific feature to ensure that URLs are set correctly.
Yes exactly.
>>
>> 2.3 looks very like CompositeWireBuilder.
Which should continue to work as-is :)
>>
>> My quandry at the moment is that the process has a dependency on the node
>> description so it doesn't fit in the builders where they are at the moment.
>> It feels like we need a separate module. So comments about whether any of
>> this makes sense and, if so, where I should put it are welcome.
>>
If that helps: The dependency on NodeImplementation is not really
necessary, as the only info you need is the list of Binding objects from
the node description.
Something like that should work:
configure(Composite composite, List<Binding> defaultBindings);
>>
>> [1] http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg28299.html
>> [2]
>> http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Contribution+Processing
>> [3] http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Runtime+Phases
>>
>
> I have some code [1] for steps 1, 2.1 and 2.2 above and I want to move it
> out of my sandbox to see how it fits. Two questions
>
> A) I have a relatively stand alone algorithm [2] that populates service
> binding URIs (similar to the CompositeConfigurationBuilder and I would like
> to combine the two in the future) and am assuming for now that it will slot
> into o.a.t.s.workspace.configuration.imp. Anyone not happy with that please
> speak up.
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.
>
> 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.
As this is a result of a binding
> configuration, based on binding, interfaces descritions, policy I have taken
> the approach of creating a new extension point, BindingURICalculator [3],
> which will hold this and probably other binding specific function related to
> URI calculation. I want to check that there isn't somewhere else that people
> think this function should live.
>
> Am writing tests at the moment so you have time to comment before I do move
> out of my sandbox.
>
+1 from me to continue this work in trunk.
>
> [1]
> http://svn.apache.org/repos/asf/incubator/tuscany/sandbox/slaws/modules/domain-rework/
> [2]
> http://svn.apache.org/repos/asf/incubator/tuscany/sandbox/slaws/modules/domain-rework/src/main/java/org/apache/tuscany/sca/workspace/configuration/impl/NodeAssigner.java
> [3]
> http://svn.apache.org/repos/asf/incubator/tuscany/sandbox/slaws/modules/domain-rework/src/main/java/org/apache/tuscany/sca/binding/BindingURICalculator.java
>
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org