You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Lou Amodeo <lo...@gmail.com> on 2008/01/21 19:55:18 UTC
Request to propogate the value of a references target= attribute on its associated bindings model object
This is a request to propogate the value of a references target= attribute
as a first class attribute on its associated bindings model object.
This request is based on a requirement to provide support to implement a
late-endpoint resolution capability for service references when a reference
specifies the target= attribute. This value in conjunction with a domain
wide services registry allows the binding invokers to use the value
specified for <reference target="" as a key to perform a service lookup to
obtain the services endpoint URI dynamically during the invocation of the
service rather than during compositie startup. The primary benefits of this
approach are to provide a degree of location transparency for services and
remove the requirement of the client from knowing the services endpoint at
installation time. This would only apply to clients that are running in the
same domain as the services they reference.
Re: Request to propogate the value of a references target= attribute
on its associated bindings model object
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Lou Amodeo wrote:
> This is a request to propogate the value of a references target= attribute
> as a first class attribute on its associated bindings model object.
> This request is based on a requirement to provide support to implement a
> late-endpoint resolution capability for service references when a reference
> specifies the target= attribute. This value in conjunction with a domain
> wide services registry allows the binding invokers to use the value
> specified for <reference target="" as a key to perform a service lookup to
> obtain the services endpoint URI dynamically during the invocation of the
> service rather than during compositie startup. The primary benefits of this
> approach are to provide a degree of location transparency for services and
> remove the requirement of the client from knowing the services endpoint at
> installation time. This would only apply to clients that are running in the
> same domain as the services they reference.
>
After reading the whole thread I'm confused and would like to walk
through a simple scenario with two composites A and B, A containing
component references to components in B.
Here are the steps I'm thinking about for A and B:
A1. contribution A is installed in the domain.
A2. deployable composite A is selected for deployment.
A3. policy sets are configured and applied to elements of A.
A4. A's references and dependencies are validated and satisfied.
A5. composite A is deployed to SCA machine 1.
A6. components in composite A are started.
A7. a reference wired to a component in B is invoked.
B1. contribution B is installed in the domain.
B2. deployable composite B is selected for deployment.
B3. policy sets are configured and applied to elements of A.
B4. B's references and dependencies are validated and satisfied.
B5. composite B is deployed to SCA machine 2.
B6. components in composite B are started.
B7. a reference wired to a component in B is invoked.
By SCA machine I mean a logical processor responsible for instantiating
components and executing their implementations (a server, a process, a
node, a webapp, or whatever applies to your particular architecture).
Would it be possible to describe the timing of the A steps function of
the B steps, for example
A1 < B1
A2 < B1
A3 < B1
A4 > B5?
etc?
That will help me understand your requirement and what you're expecting
of the various configuration and resolution steps.
Thanks!
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Request to propogate the value of a references target= attribute on its associated bindings model object
Posted by Simon Laws <si...@googlemail.com>.
Some more comments inline ....
>
> Lets see if I can articulate this a little better. My thinking is that
> taget= represents a binding independent way to resolve an endpoint. It
> doesnt necessarily specify the contents of the effective URI that is
> used to address an endpoint.
+1
> In the context of a WS binding for instance it
> doesnt specify the value or any part of the value of the actual URL used
> to
> invoke the service. The binding URI attribute does represent all of or a
> part of the URI used to invoke a service.
The binding URI should (according to lines 2305-2307 of the assembly spec)
define the target URI of the reference (either the component/service for a
wire to an endpoint within the SCA domain or the accessible address of some
endpoint outside the SCA domain)
I think we are bending this a bit when we try and wire a remote binding,
e,g, binding.ws, inside the domain and add the full URL information to the
reference binding uri. Maybe need another look.
> The use case I have in mind is the
> ability to use target= to specify a logical representation of a URI that
> can
> be used by all binding types as a "key" to lookup / resolve the binding's
> specific physical endpoint to be used to invoke the service. In the case
> of
> binding.ws for example I envision a mapping as follows :
>
> target = "C1/S1" binding.ws URI = "http://<someServer>/<someService>"
>
We have a mapping very similar to this in the domain code currently
> binding.jms URI = some binding appropriate URI
>
> binding.sca URI = some binding appropriate URI
>
> In this instance only a logical value of C1/S1 needs to be specified on
> the
> reference target=. Each service can then register itself and all
> appropriate
> binding specific URI's.
>
> The reference can then simply specify which binding type to use and the
> logical target name of C1/S1 and the binding can then "resolve" the target
> to the binding specific URI.
>
> The binding however needs to know the value of target= to know 1) when
> this
> logical to physical name resolution needs to occur and 2) what key to use
> to
> perform the lookup.
>
>
There is no doubt that this mapping should take place. So it comes down to
whether the binding implementation should be responsible for initiating this
mapping or if the mapping should take place in order that the bindings are
fully configured when they are created. There are two reasons I might use to
justify initiating this mapping in the binding.
1. To handle changes in the SCA model during runtime, e.g. someone adds or
modifies a wire and you need a component reference to take account of this.
I think there is debate in OASIS at the moment about what the shape of this
capability should be. While I can't predict what the result of the Oasis
discussion will be I can say that Tuscany set off looking at this but there
are many complications, not least that references need to be matched with
services taking into account available bindings, interface descriptions and
policy intents so a much more capable domain level query is required to
effect this mapping properly.
2. To handle service resilience issues, e.g. you know which service you want
to talk to and have chosen a binding at the domain level but you want to
take account of a service being moved deliberately or failing and being
restarted.
The question here is whether it is the responsibility of Tuscany to manage
this, e.g. The responsibility could be devolved to the system administrator
who could be expected to deploy services into some kind of cluster if there
is a requirement to provide a level of abstraction between the URL that a
reference targets and the location of a given service.
Are there scenarios that I'm missing here?
I'm really trying to understand what, on the face of it, is a very simple
request (to provide more information in the binding model) as it has
implication for where Tuscany users see the boundary of responsibility for
an SCA application running in Tuscany.
Regards
Simon
Re: Request to propogate the value of a references target= attribute on its associated bindings model object
Posted by Lou Amodeo <lo...@gmail.com>.
Thanks for all the responses and good discussion.
Lets see if I can articulate this a little better. My thinking is that
taget= represents a binding independent way to resolve an endpoint. It
doesnt necessarily specify the contents of the effective URI that is
used to address an endpoint. In the context of a WS binding for instance it
doesnt specify the value or any part of the value of the actual URL used to
invoke the service. The binding URI attribute does represent all of or a
part of the URI used to invoke a service. The use case I have in mind is the
ability to use target= to specify a logical representation of a URI that can
be used by all binding types as a "key" to lookup / resolve the binding's
specific physical endpoint to be used to invoke the service. In the case of
binding.ws for example I envision a mapping as follows :
target = "C1/S1" binding.ws URI = "http://<someServer>/<someService>"
binding.jms URI = some binding appropriate URI
binding.sca URI = some binding appropriate URI
In this instance only a logical value of C1/S1 needs to be specified on the
reference target=. Each service can then register itself and all appropriate
binding specific URI's.
The reference can then simply specify which binding type to use and the
logical target name of C1/S1 and the binding can then "resolve" the target
to the binding specific URI.
The binding however needs to know the value of target= to know 1) when this
logical to physical name resolution needs to occur and 2) what key to use to
perform the lookup.
On 1/31/08, Simon Laws <si...@googlemail.com> wrote:
>
> snip...
>
> >
> > >>The value from the reference target is currently set to the target
> when
> > > the reference is matched to a target service.
> > >
> > I don't quite follow the above. Are you saying that the service URI
> > is copied into the reference binding URI at the matching stage? Is this
> > the fully resolved absolute service URI rather than the relative URI
> > that a client target attribute would specify?
> >
>
> Yes. It's the binding uri that the component service holds. For a local
> SCA
> binding this will be the same as the target name that the user entered
> into
> the composite file except where the shortened form of the service name is
> used.
>
> In the case where a remote binding is in use it should be the fully
> resolved
> URI. The domain does this for us at the moment at run time. As I said
> earlier in this thread there is a case for changing this calculation to
> happen at deployment time so instead of the domain providing updates to
> nodes telling the node when service URIs change the deployment stage would
> be expected to provide a fully resolved composite at the point at which
> the
> composite is started. The result would though be the same in that the
> binding URI would correctly represent the endpoint details of the
> referenced
> service. The point in time at which that information is know though is
> different.
>
> Simon
>
Re: Request to propogate the value of a references target= attribute on its associated bindings model object
Posted by Simon Laws <si...@googlemail.com>.
snip...
>
> >>The value from the reference target is currently set to the target when
> > the reference is matched to a target service.
> >
> I don't quite follow the above. Are you saying that the service URI
> is copied into the reference binding URI at the matching stage? Is this
> the fully resolved absolute service URI rather than the relative URI
> that a client target attribute would specify?
>
Yes. It's the binding uri that the component service holds. For a local SCA
binding this will be the same as the target name that the user entered into
the composite file except where the shortened form of the service name is
used.
In the case where a remote binding is in use it should be the fully resolved
URI. The domain does this for us at the moment at run time. As I said
earlier in this thread there is a case for changing this calculation to
happen at deployment time so instead of the domain providing updates to
nodes telling the node when service URIs change the deployment stage would
be expected to provide a fully resolved composite at the point at which the
composite is started. The result would though be the same in that the
binding URI would correctly represent the endpoint details of the referenced
service. The point in time at which that information is know though is
different.
Simon
Re: Request to propogate the value of a references target= attribute
on its associated bindings model object
Posted by Simon Nash <na...@hursley.ibm.com>.
One question inline.
Simon
Simon Laws wrote:
> On Jan 30, 2008 8:06 PM, Simon Nash <na...@hursley.ibm.com> wrote:
>
> (cut)
>
>>The value from the reference target is currently set to the target when
> the reference is matched to a target service.
>
I don't quite follow the above. Are you saying that the service URI
is copied into the reference binding URI at the matching stage? Is this
the fully resolved absolute service URI rather than the relative URI
that a client target attribute would specify?
Simon
> I guess that could be brought
> forward and have the target copied into the reference binding URI prior to
> the matching stage. It will only help though if, at deployment time, you
> are preprocessing the SCA composites to match reference binding to service
> binding and choose the binding you expect to be active at runtime. Otherwise
> the runtime won't know which binding invoker to choose.
>
> Is this the direction you are thinking of?
>
> Simon
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Request to propogate the value of a references target= attribute on its associated bindings model object
Posted by Simon Laws <si...@googlemail.com>.
On Jan 30, 2008 8:06 PM, Simon Nash <na...@hursley.ibm.com> wrote:
> See inline.
>
> Simon
>
> Lou Amodeo wrote:
>
> > By deferring the endpoint resolution until the point of invocation it
> > reduces the window of opportunity for the reference to lookup the
> endpoint
> > prior to the service being started. It also always services to change
> > endpoints (reregister) without the need for recycle the client.
> >
> > Getting back to the original request, rather than decide on a
> > specific implementation, I was looking for an adjustment in the model.
> At
> > the root of this is the ability of a binding element such as binding.wsto
> > be able to see the attributes of its parent the reference element.
> > Of which target is an attribute.
> >
> In general elements don't know about their parent, only about their
> children. They only know about their parent or its attributes if the
> parent has passed that information down to them. Maybe others can
> explain the reason for this.
>
> The reference target is supposed to be exactly equivalent to the
> binding URI. (It's not legal to specify both.) If the value from
> the reference target were set into the binding URI, would that give
> you what you need?
>
> Simon
> >
> >
> >
> > On 1/30/08, Simon Nash <na...@hursley.ibm.com> wrote:
> >
> >>
> >>Simon Laws wrote:
> >>
> >>
> >>>On Jan 21, 2008 6:55 PM, Lou Amodeo <lo...@gmail.com> wrote:
> >>>
> >>>
> >>>
> >>>>This is a request to propogate the value of a references target=
> >>
> >>attribute
> >>
> >>>>as a first class attribute on its associated bindings model object.
> >>>>This request is based on a requirement to provide support to implement
> a
> >>>>late-endpoint resolution capability for service references when a
> >>>>reference
> >>>>specifies the target= attribute. This value in conjunction with a
> domain
> >>>>wide services registry allows the binding invokers to use the value
> >>>>specified for <reference target="" as a key to perform a service
> lookup
> >>
> >>to
> >>
> >>>>obtain the services endpoint URI dynamically during the invocation of
> >>
> >>the
> >>
> >>>>service rather than during compositie startup. The primary benefits of
> >>>>this
> >>>>approach are to provide a degree of location transparency for services
> >>
> >>and
> >>
> >>>>remove the requirement of the client from knowing the services
> endpoint
> >>
> >>at
> >>
> >>>>installation time. This would only apply to clients that are running
> in
> >>>>the
> >>>>same domain as the services they reference.
> >>>>
> >>>
> >>>
> >>>Hi Lou
> >>>
> >>>This is interesting as I've been thinking about this myself. We
> >>
> >>currently
> >>
> >>>take this approach in the Tuscany code base so let me give a bit a of a
> >>>review of that and we can then discuss what is required.
> >>>
> >>>In the Tuscany code we have a 'Domain' service which acts as the
> >>>manager/registry of all of the 'Nodes' that in turn run composites.
> >>>
> >>>Our domain level wiring support started out life in the default binding
> >>>only, I.e. you could only wire between remote components using
> 'target='
> >>
> >>if
> >>
> >>>the reference also used the default binding. The default binding has
> >>
> >>some
> >>
> >>>code in it that used the binding URI, which by default contains
> >>
> >>information
> >>
> >>>from target=, to ask the domain registry what the physical URI of the
> >>
> >>target
> >>
> >>>service is.
> >>>
> >>>Now to extend this support across different types of binding we started
> >>
> >>to
> >>
> >>>look at this in a slightly different way. Rather than embedding code in
> >>
> >>each
> >>
> >>>different type of binding we added some code at the Domain level that
> >>
> >>looks
> >>
> >>>across the whole domain model and matches references with services.
> >>
> >>Where a
> >>
> >>>match is found the reference URI is completed with URI information from
> >>
> >>the
> >>
> >>>service. The intention with this domain level processing is that we can
> >>
> >>more
> >>
> >>>easily handle binding selection, policy matching and autowiring at the
> >>>domain level. The result of this processing is an amended composite
> that
> >>
> >>can
> >>
> >>>be sent to the node for execution.
> >>>
> >>>This all sounds great but its starting to get a little complicated.
> This
> >>
> >>is
> >>
> >>>because we are doing the processing dynamically. When a composite is
> >>
> >>started
> >>
> >>>it registers its available services. The result of this is that every
> >>
> >>time a
> >>
> >>>composite is started the domain changes and you get a ripple effect of
> >>>composites being amended as references are updated to include new
> >>
> >>service
> >>
> >>>URIs.
> >>>
> >>>In your note its interesting that you say "The primary benefits of this
> >>>approach are to provide a degree of location transparency for services
> >>
> >>and
> >>
> >>>remove the requirement of the client from knowing the services endpoint
> >>
> >>at
> >>
> >>>installation time.". I've been mulling over an alternative approach.
> >>
> >>What I
> >>
> >>>mean is that I recognize the need for the location transparency but
> that
> >>
> >>we
> >>
> >>>could pre-process all of the domain's composites to take account of
> this
> >>>location transparency before we try and run them. This would give rise
> >>
> >>to a
> >>
> >>>several, more deterministic, processing steps
> >>>
> >>>1. Add all of the contributions to the domain
> >>>2. Assign composites to the nodes where they will run
> >>>3. Based on 2 perform domain level wiring
> >>>4. Re-write the composites to contain the updated reference information
> >>>5. "deploy" to the contributions/composites to their allotted nodes for
> >>>execution
> >>>
> >>>I'd be interested to understand what steps in bringing up a system you
> >>
> >>have
> >>
> >>>in mind. If we can work toward agreement on the steps involved we can
> >>
> >>decide
> >>
> >>>how we should amend the Tuscany code.
> >>>
> >>
> >>I'm trying to understand the important differences between the approach
> >>described by Lou and the approach described by Simon. Lou seems to have
> >>in mind a scenario that defers resolution of the protocol endpoint of
> the
> >>target to the point of actually making the invocation, whereas Simon
> seems
> >>to be suggesting resolving it earlier as part of deployment.
> >>
> >>Is there a scenario (use case) that requires the invocation-time lookup
> >>that Lou is describing and would not work if references were bound to
> >>protocol endpoints as part of a deployment step? If we can identify
> this
> >>scenario, I think it would help us to make progress.
> >>
> >> Simon
> >>
> >>
> >>
> >>---------------------------------------------------------------------
> >>To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> >>For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >>
> >>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
> The value from the reference target is currently set to the target when
the reference is matched to a target service. I guess that could be brought
forward and have the target copied into the reference binding URI prior to
the matching stage. It will only help though if, at deployment time, you
are preprocessing the SCA composites to match reference binding to service
binding and choose the binding you expect to be active at runtime. Otherwise
the runtime won't know which binding invoker to choose.
Is this the direction you are thinking of?
Simon
Re: Request to propogate the value of a references target= attribute
on its associated bindings model object
Posted by Simon Nash <na...@hursley.ibm.com>.
See inline.
Simon
Lou Amodeo wrote:
> By deferring the endpoint resolution until the point of invocation it
> reduces the window of opportunity for the reference to lookup the endpoint
> prior to the service being started. It also always services to change
> endpoints (reregister) without the need for recycle the client.
>
> Getting back to the original request, rather than decide on a
> specific implementation, I was looking for an adjustment in the model. At
> the root of this is the ability of a binding element such as binding.ws to
> be able to see the attributes of its parent the reference element.
> Of which target is an attribute.
>
In general elements don't know about their parent, only about their
children. They only know about their parent or its attributes if the
parent has passed that information down to them. Maybe others can
explain the reason for this.
The reference target is supposed to be exactly equivalent to the
binding URI. (It's not legal to specify both.) If the value from
the reference target were set into the binding URI, would that give
you what you need?
Simon
>
>
>
> On 1/30/08, Simon Nash <na...@hursley.ibm.com> wrote:
>
>>
>>Simon Laws wrote:
>>
>>
>>>On Jan 21, 2008 6:55 PM, Lou Amodeo <lo...@gmail.com> wrote:
>>>
>>>
>>>
>>>>This is a request to propogate the value of a references target=
>>
>>attribute
>>
>>>>as a first class attribute on its associated bindings model object.
>>>>This request is based on a requirement to provide support to implement a
>>>>late-endpoint resolution capability for service references when a
>>>>reference
>>>>specifies the target= attribute. This value in conjunction with a domain
>>>>wide services registry allows the binding invokers to use the value
>>>>specified for <reference target="" as a key to perform a service lookup
>>
>>to
>>
>>>>obtain the services endpoint URI dynamically during the invocation of
>>
>>the
>>
>>>>service rather than during compositie startup. The primary benefits of
>>>>this
>>>>approach are to provide a degree of location transparency for services
>>
>>and
>>
>>>>remove the requirement of the client from knowing the services endpoint
>>
>>at
>>
>>>>installation time. This would only apply to clients that are running in
>>>>the
>>>>same domain as the services they reference.
>>>>
>>>
>>>
>>>Hi Lou
>>>
>>>This is interesting as I've been thinking about this myself. We
>>
>>currently
>>
>>>take this approach in the Tuscany code base so let me give a bit a of a
>>>review of that and we can then discuss what is required.
>>>
>>>In the Tuscany code we have a 'Domain' service which acts as the
>>>manager/registry of all of the 'Nodes' that in turn run composites.
>>>
>>>Our domain level wiring support started out life in the default binding
>>>only, I.e. you could only wire between remote components using 'target='
>>
>>if
>>
>>>the reference also used the default binding. The default binding has
>>
>>some
>>
>>>code in it that used the binding URI, which by default contains
>>
>>information
>>
>>>from target=, to ask the domain registry what the physical URI of the
>>
>>target
>>
>>>service is.
>>>
>>>Now to extend this support across different types of binding we started
>>
>>to
>>
>>>look at this in a slightly different way. Rather than embedding code in
>>
>>each
>>
>>>different type of binding we added some code at the Domain level that
>>
>>looks
>>
>>>across the whole domain model and matches references with services.
>>
>>Where a
>>
>>>match is found the reference URI is completed with URI information from
>>
>>the
>>
>>>service. The intention with this domain level processing is that we can
>>
>>more
>>
>>>easily handle binding selection, policy matching and autowiring at the
>>>domain level. The result of this processing is an amended composite that
>>
>>can
>>
>>>be sent to the node for execution.
>>>
>>>This all sounds great but its starting to get a little complicated. This
>>
>>is
>>
>>>because we are doing the processing dynamically. When a composite is
>>
>>started
>>
>>>it registers its available services. The result of this is that every
>>
>>time a
>>
>>>composite is started the domain changes and you get a ripple effect of
>>>composites being amended as references are updated to include new
>>
>>service
>>
>>>URIs.
>>>
>>>In your note its interesting that you say "The primary benefits of this
>>>approach are to provide a degree of location transparency for services
>>
>>and
>>
>>>remove the requirement of the client from knowing the services endpoint
>>
>>at
>>
>>>installation time.". I've been mulling over an alternative approach.
>>
>>What I
>>
>>>mean is that I recognize the need for the location transparency but that
>>
>>we
>>
>>>could pre-process all of the domain's composites to take account of this
>>>location transparency before we try and run them. This would give rise
>>
>>to a
>>
>>>several, more deterministic, processing steps
>>>
>>>1. Add all of the contributions to the domain
>>>2. Assign composites to the nodes where they will run
>>>3. Based on 2 perform domain level wiring
>>>4. Re-write the composites to contain the updated reference information
>>>5. "deploy" to the contributions/composites to their allotted nodes for
>>>execution
>>>
>>>I'd be interested to understand what steps in bringing up a system you
>>
>>have
>>
>>>in mind. If we can work toward agreement on the steps involved we can
>>
>>decide
>>
>>>how we should amend the Tuscany code.
>>>
>>
>>I'm trying to understand the important differences between the approach
>>described by Lou and the approach described by Simon. Lou seems to have
>>in mind a scenario that defers resolution of the protocol endpoint of the
>>target to the point of actually making the invocation, whereas Simon seems
>>to be suggesting resolving it earlier as part of deployment.
>>
>>Is there a scenario (use case) that requires the invocation-time lookup
>>that Lou is describing and would not work if references were bound to
>>protocol endpoints as part of a deployment step? If we can identify this
>>scenario, I think it would help us to make progress.
>>
>> Simon
>>
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
>>For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Request to propogate the value of a references target= attribute on its associated bindings model object
Posted by Lou Amodeo <lo...@gmail.com>.
By deferring the endpoint resolution until the point of invocation it
reduces the window of opportunity for the reference to lookup the endpoint
prior to the service being started. It also always services to change
endpoints (reregister) without the need for recycle the client.
Getting back to the original request, rather than decide on a
specific implementation, I was looking for an adjustment in the model. At
the root of this is the ability of a binding element such as binding.ws to
be able to see the attributes of its parent the reference element.
Of which target is an attribute.
On 1/30/08, Simon Nash <na...@hursley.ibm.com> wrote:
>
>
> Simon Laws wrote:
>
> > On Jan 21, 2008 6:55 PM, Lou Amodeo <lo...@gmail.com> wrote:
> >
> >
> >>This is a request to propogate the value of a references target=
> attribute
> >>as a first class attribute on its associated bindings model object.
> >>This request is based on a requirement to provide support to implement a
> >>late-endpoint resolution capability for service references when a
> >>reference
> >>specifies the target= attribute. This value in conjunction with a domain
> >>wide services registry allows the binding invokers to use the value
> >>specified for <reference target="" as a key to perform a service lookup
> to
> >>obtain the services endpoint URI dynamically during the invocation of
> the
> >>service rather than during compositie startup. The primary benefits of
> >>this
> >>approach are to provide a degree of location transparency for services
> and
> >>remove the requirement of the client from knowing the services endpoint
> at
> >>installation time. This would only apply to clients that are running in
> >>the
> >>same domain as the services they reference.
> >>
> >
> >
> > Hi Lou
> >
> > This is interesting as I've been thinking about this myself. We
> currently
> > take this approach in the Tuscany code base so let me give a bit a of a
> > review of that and we can then discuss what is required.
> >
> > In the Tuscany code we have a 'Domain' service which acts as the
> > manager/registry of all of the 'Nodes' that in turn run composites.
> >
> > Our domain level wiring support started out life in the default binding
> > only, I.e. you could only wire between remote components using 'target='
> if
> > the reference also used the default binding. The default binding has
> some
> > code in it that used the binding URI, which by default contains
> information
> > from target=, to ask the domain registry what the physical URI of the
> target
> > service is.
> >
> > Now to extend this support across different types of binding we started
> to
> > look at this in a slightly different way. Rather than embedding code in
> each
> > different type of binding we added some code at the Domain level that
> looks
> > across the whole domain model and matches references with services.
> Where a
> > match is found the reference URI is completed with URI information from
> the
> > service. The intention with this domain level processing is that we can
> more
> > easily handle binding selection, policy matching and autowiring at the
> > domain level. The result of this processing is an amended composite that
> can
> > be sent to the node for execution.
> >
> > This all sounds great but its starting to get a little complicated. This
> is
> > because we are doing the processing dynamically. When a composite is
> started
> > it registers its available services. The result of this is that every
> time a
> > composite is started the domain changes and you get a ripple effect of
> > composites being amended as references are updated to include new
> service
> > URIs.
> >
> > In your note its interesting that you say "The primary benefits of this
> > approach are to provide a degree of location transparency for services
> and
> > remove the requirement of the client from knowing the services endpoint
> at
> > installation time.". I've been mulling over an alternative approach.
> What I
> > mean is that I recognize the need for the location transparency but that
> we
> > could pre-process all of the domain's composites to take account of this
> > location transparency before we try and run them. This would give rise
> to a
> > several, more deterministic, processing steps
> >
> > 1. Add all of the contributions to the domain
> > 2. Assign composites to the nodes where they will run
> > 3. Based on 2 perform domain level wiring
> > 4. Re-write the composites to contain the updated reference information
> > 5. "deploy" to the contributions/composites to their allotted nodes for
> > execution
> >
> > I'd be interested to understand what steps in bringing up a system you
> have
> > in mind. If we can work toward agreement on the steps involved we can
> decide
> > how we should amend the Tuscany code.
> >
> I'm trying to understand the important differences between the approach
> described by Lou and the approach described by Simon. Lou seems to have
> in mind a scenario that defers resolution of the protocol endpoint of the
> target to the point of actually making the invocation, whereas Simon seems
> to be suggesting resolving it earlier as part of deployment.
>
> Is there a scenario (use case) that requires the invocation-time lookup
> that Lou is describing and would not work if references were bound to
> protocol endpoints as part of a deployment step? If we can identify this
> scenario, I think it would help us to make progress.
>
> Simon
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>
Re: Request to propogate the value of a references target= attribute
on its associated bindings model object
Posted by Simon Nash <na...@hursley.ibm.com>.
Simon Laws wrote:
> On Jan 21, 2008 6:55 PM, Lou Amodeo <lo...@gmail.com> wrote:
>
>
>>This is a request to propogate the value of a references target= attribute
>>as a first class attribute on its associated bindings model object.
>>This request is based on a requirement to provide support to implement a
>>late-endpoint resolution capability for service references when a
>>reference
>>specifies the target= attribute. This value in conjunction with a domain
>>wide services registry allows the binding invokers to use the value
>>specified for <reference target="" as a key to perform a service lookup to
>>obtain the services endpoint URI dynamically during the invocation of the
>>service rather than during compositie startup. The primary benefits of
>>this
>>approach are to provide a degree of location transparency for services and
>>remove the requirement of the client from knowing the services endpoint at
>>installation time. This would only apply to clients that are running in
>>the
>>same domain as the services they reference.
>>
>
>
> Hi Lou
>
> This is interesting as I've been thinking about this myself. We currently
> take this approach in the Tuscany code base so let me give a bit a of a
> review of that and we can then discuss what is required.
>
> In the Tuscany code we have a 'Domain' service which acts as the
> manager/registry of all of the 'Nodes' that in turn run composites.
>
> Our domain level wiring support started out life in the default binding
> only, I.e. you could only wire between remote components using 'target=' if
> the reference also used the default binding. The default binding has some
> code in it that used the binding URI, which by default contains information
> from target=, to ask the domain registry what the physical URI of the target
> service is.
>
> Now to extend this support across different types of binding we started to
> look at this in a slightly different way. Rather than embedding code in each
> different type of binding we added some code at the Domain level that looks
> across the whole domain model and matches references with services. Where a
> match is found the reference URI is completed with URI information from the
> service. The intention with this domain level processing is that we can more
> easily handle binding selection, policy matching and autowiring at the
> domain level. The result of this processing is an amended composite that can
> be sent to the node for execution.
>
> This all sounds great but its starting to get a little complicated. This is
> because we are doing the processing dynamically. When a composite is started
> it registers its available services. The result of this is that every time a
> composite is started the domain changes and you get a ripple effect of
> composites being amended as references are updated to include new service
> URIs.
>
> In your note its interesting that you say "The primary benefits of this
> approach are to provide a degree of location transparency for services and
> remove the requirement of the client from knowing the services endpoint at
> installation time.". I've been mulling over an alternative approach. What I
> mean is that I recognize the need for the location transparency but that we
> could pre-process all of the domain's composites to take account of this
> location transparency before we try and run them. This would give rise to a
> several, more deterministic, processing steps
>
> 1. Add all of the contributions to the domain
> 2. Assign composites to the nodes where they will run
> 3. Based on 2 perform domain level wiring
> 4. Re-write the composites to contain the updated reference information
> 5. "deploy" to the contributions/composites to their allotted nodes for
> execution
>
> I'd be interested to understand what steps in bringing up a system you have
> in mind. If we can work toward agreement on the steps involved we can decide
> how we should amend the Tuscany code.
>
I'm trying to understand the important differences between the approach
described by Lou and the approach described by Simon. Lou seems to have
in mind a scenario that defers resolution of the protocol endpoint of the
target to the point of actually making the invocation, whereas Simon seems
to be suggesting resolving it earlier as part of deployment.
Is there a scenario (use case) that requires the invocation-time lookup
that Lou is describing and would not work if references were bound to
protocol endpoints as part of a deployment step? If we can identify this
scenario, I think it would help us to make progress.
Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Request to propogate the value of a references target= attribute on its associated bindings model object
Posted by Simon Laws <si...@googlemail.com>.
On Jan 21, 2008 6:55 PM, Lou Amodeo <lo...@gmail.com> wrote:
> This is a request to propogate the value of a references target= attribute
> as a first class attribute on its associated bindings model object.
> This request is based on a requirement to provide support to implement a
> late-endpoint resolution capability for service references when a
> reference
> specifies the target= attribute. This value in conjunction with a domain
> wide services registry allows the binding invokers to use the value
> specified for <reference target="" as a key to perform a service lookup to
> obtain the services endpoint URI dynamically during the invocation of the
> service rather than during compositie startup. The primary benefits of
> this
> approach are to provide a degree of location transparency for services and
> remove the requirement of the client from knowing the services endpoint at
> installation time. This would only apply to clients that are running in
> the
> same domain as the services they reference.
>
Hi Lou
This is interesting as I've been thinking about this myself. We currently
take this approach in the Tuscany code base so let me give a bit a of a
review of that and we can then discuss what is required.
In the Tuscany code we have a 'Domain' service which acts as the
manager/registry of all of the 'Nodes' that in turn run composites.
Our domain level wiring support started out life in the default binding
only, I.e. you could only wire between remote components using 'target=' if
the reference also used the default binding. The default binding has some
code in it that used the binding URI, which by default contains information
from target=, to ask the domain registry what the physical URI of the target
service is.
Now to extend this support across different types of binding we started to
look at this in a slightly different way. Rather than embedding code in each
different type of binding we added some code at the Domain level that looks
across the whole domain model and matches references with services. Where a
match is found the reference URI is completed with URI information from the
service. The intention with this domain level processing is that we can more
easily handle binding selection, policy matching and autowiring at the
domain level. The result of this processing is an amended composite that can
be sent to the node for execution.
This all sounds great but its starting to get a little complicated. This is
because we are doing the processing dynamically. When a composite is started
it registers its available services. The result of this is that every time a
composite is started the domain changes and you get a ripple effect of
composites being amended as references are updated to include new service
URIs.
In your note its interesting that you say "The primary benefits of this
approach are to provide a degree of location transparency for services and
remove the requirement of the client from knowing the services endpoint at
installation time.". I've been mulling over an alternative approach. What I
mean is that I recognize the need for the location transparency but that we
could pre-process all of the domain's composites to take account of this
location transparency before we try and run them. This would give rise to a
several, more deterministic, processing steps
1. Add all of the contributions to the domain
2. Assign composites to the nodes where they will run
3. Based on 2 perform domain level wiring
4. Re-write the composites to contain the updated reference information
5. "deploy" to the contributions/composites to their allotted nodes for
execution
I'd be interested to understand what steps in bringing up a system you have
in mind. If we can work toward agreement on the steps involved we can decide
how we should amend the Tuscany code.
Regards
Simon