You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Kevin Williams <kj...@gmail.com> on 2007/08/08 22:15:04 UTC
Cross-jvm locate service
I am interested in extending the current locate service capability to
support the location of services that may be running within the same
domain but a separate jvm. The most straightforward approach may be
to dynamically create and return a service reference using the same
Tuscany runtime elements that now create service references for
injection in support of the @reference annotation.
Any thoughts or pointers would be appreciated.
Thanks,
--Kevin
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Service visibility (was Re: Cross-jvm locate service)
Posted by Paul Golick <go...@us.ibm.com>.
Kevin and I are considering "in extending the current locate service" with
a mechanism that is aware of the composite context. That is, services
exposed by a "domain level" composite would be visible to all and services
available on other composites would only be visible to the containing
composite.
If this is not a correct interpretation of the SCA Assembly Model, please
correct me.
Paul
Simon Nash <na...@hursley.ibm.com>
2007-08-09 06:27 AM
Please respond to
tuscany-dev@ws.apache.org
To
tuscany-dev@ws.apache.org
cc
Subject
Service visibility (was Re: Cross-jvm locate service)
This is technically feasible (see other discussion on this thread)
but I think we need to be careful about how wide open we are making
the services within a Tuscany SCA domain. I don't think we want
every service within every domain to be wide open for anyone to reach
down from the sky and call it. As the owner of a service, I would want
to decide whether it is exposed for local calling, distributed calling
within my domain (which can consist of multiple runtime nodes), or
revealed to other domains via some global locateService API. I think
the right way for me to exercise this control is to create a
self-reference or a service reference within my domain, then selectively
pass this out to other domains in a manner that I can control, e.g., in
a service registry that is able to implement a governance policy.
Simon
Kevin Williams wrote:
> I am interested in extending the current locate service capability to
> support the location of services that may be running within the same
> domain but a separate jvm. The most straightforward approach may be
> to dynamically create and return a service reference using the same
> Tuscany runtime elements that now create service references for
> injection in support of the @reference annotation.
>
> Any thoughts or pointers would be appreciated.
>
> Thanks,
>
> --Kevin
>
Service visibility (was Re: Cross-jvm locate service)
Posted by Simon Nash <na...@hursley.ibm.com>.
This is technically feasible (see other discussion on this thread)
but I think we need to be careful about how wide open we are making
the services within a Tuscany SCA domain. I don't think we want
every service within every domain to be wide open for anyone to reach
down from the sky and call it. As the owner of a service, I would want
to decide whether it is exposed for local calling, distributed calling
within my domain (which can consist of multiple runtime nodes), or
revealed to other domains via some global locateService API. I think
the right way for me to exercise this control is to create a
self-reference or a service reference within my domain, then selectively
pass this out to other domains in a manner that I can control, e.g., in
a service registry that is able to implement a governance policy.
Simon
Kevin Williams wrote:
> I am interested in extending the current locate service capability to
> support the location of services that may be running within the same
> domain but a separate jvm. The most straightforward approach may be
> to dynamically create and return a service reference using the same
> Tuscany runtime elements that now create service references for
> injection in support of the @reference annotation.
>
> Any thoughts or pointers would be appreciated.
>
> Thanks,
>
> --Kevin
>
> ---------------------------------------------------------------------
> 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: Cross-jvm locate service
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Kevin Williams wrote:
> Sebastien and Simon,
>
> Thanks for this conversation. Its been very helpful. I would like to
> recap a little and ask a couple of questions.
>
> At the highest level the steps to locate a service are:
>
> 1. Look locally and if found proceed as Tuscany does today, otherwise
> 2. Dynamically create a reference for the target service using
> binding and end-point URI info
> 3. Create a CallableReference for that self-reference
> 4. Get a ServiceReference proxy to the service from the CallableReference
> 5. Return the ServiceReference
>
Yes
> For an example of how to dynamically create a reference(2) you
> mentioned: CompositeConfigurationBuilderImpl.createSelfReference() and
> I assume you meant CompositeBuilderImpl.createSelfReference(Component,
> ComponentService), right?
>
I meant CompositeConfigurationBuilderImpl, as I have refactored
CompositeBuilderImpl in trunk earlier this week :)
> Since I won't have a ComponentService available I will need to somehow
> provide the required binding and InterfaceContract information. I
> think there are factories for these.
>
> Can you point me to code that creates a CallableReference from a
> ComponentReference (3) ?
>
org.apache.tuscany.sca.implementation.java.invocation.JavaComponentInfo.getServiceReference()
does that.
the interesting part is:
ObjectFactory<B> factory = createWireFactory(type, wire);
return new ServiceReferenceImpl<B>(type, factory);
type is a business interface
I'm afraid that ObjectFactory will always remain a mistery to me,
starting with the class name... this looks like a Factory for Objects,
what does that tell me exactly? :) so I hope that someone else on the
list mastering the art of ObjectFactory can jump in and help here :)
> Thanks!
>
> --Kevin
>
>
> On 8/9/07, Simon Laws <si...@googlemail.com> wrote:
>
>> On 8/9/07, Jean-Sebastien Delfino <js...@apache.org> wrote:
>>
>>> Comments inline.
>>>
>>> [snip]
>>> Simon Laws wrote:
>>>
>>>> Currently getServiceReference() expects a service name so we can rely
>>>> on the implication that all contributed composites are notionally
>>>>
>>> included
>>>
>>>> into the domain level composite to reference a component and extend
>>>> Sebastien's process to say.
>>>>
>>>>
>>> Just to make sure it's clear, as I'm not sure I completely follow the
>>> above sentence, components deployed to other nodes will not be present
>>> in the in-memory composite model kept in an SCAdomain object.
>>>
>> I was just pointing out that regardless of where a component is actually
>> running one of it's services can be identified in the domain composite using
>> the component/service name by virtue of the implicit inclusion of
>> contributed composites into the domain composite. This is an important
>> assumption as it means that people can arbitrarily locate services deployed
>> into the domain. I was making no statement about what is in the model inside
>> each JVM. I assume that the model in each JVM will contain whatever
>> artifacts that have been contributed to that JVM.
>>
>> So if you have different contributions for each JVM in the domain then you
>> get whatever is contributed to the JVM in your model. If you want to
>> reference a component that is not part of the contributions loaded by the
>> JVM then you are forced to look elsewhere in the distributed domain.
>>
>> If you want the components in a single contribution/composite to be
>> distributed across JVMs then this is a different scenario. We have done this
>> before with the distributed runtime by recording the component/JVM mapping
>> in a topology file. This still doesn't imply that the components will make
>> it into the model (although they do in the current distributed
>> implementation).
>>
>>
>>> 1. look for the target component model object in the in-memory domain
>>>
>>>> composite kept in SCADomain
>>>>
>>>> if found
>>>>
>>>> 2. look for the target service on that component
>>>> 3. find on that component the self-reference created for that service
>>>> (these self-references are automatically created by CompositeBuilder for
>>>>
>>>> each service provided by a component)
>>>> 4. create a CallableReference for that self-reference
>>>> 5. get a proxy to the service from the CallableReference
>>>>
>>>> else
>>>>
>>>> 2. look for the named component/serivce in other nodes of the
>>>>
>>> distributed
>>>
>>>> (cross JVM) domain
>>>> I am working up some interfaces to allow this to happen in the
>>>>
>>> distributed
>>>
>>>> domain case, for example,
>>>>
>>>>
>>>>
>>> http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/modules/distributed/src/main/java/org/apache/tuscany/sca/distributed/management/ServiceDiscovery.java
>>>
>>>> Not implemented just yet as I'm currently looking at the sca domain
>>>> implementation but you get the idea.
>>>> The implementation could use some simple repository implementation or
>>>> could derive the information from file.
>>>>
>>>> 3. Create a local reference for the remote service
>>>>
>>>>
>>> Your if/else proposal looks good to me.
>>>
>>>
>>>> Not sure of the details here but you both seem happy that this is
>>>> straightforward.
>>>> The thing that does look problematic is determining the
>>>> binding.
>>>>
>>> Not so problematic if it's part of the info returned by your
>>> ServiceDiscovery :)
>>>
>> Agreed I just hadn't put it there yet because I was only dealing with the
>> case where cross JVM call is constructed automatically with the sca binding.
>> You are probably right that I should make it more generally applicable.
>>
>>
>>> In the distributed case I assume that all cross JVM messaging are
>>>
>>>> handled by the sca binding.
>>>>
>>> No, any binding can be used inside an SCA domain.
>>>
>> Sorry I misslead you here unintentionally.What I mean is that in the case I
>> am concentrating on at the moment I'm only dealing with the sca binding. I
>> didn't mean to imply that you can't manually specify remote bindings between
>> components within an sca domain. If you do this though AND you specify the
>> endpoint you are duty bound to bet it right. I.e. I'm not currently putting
>> in code to fix up remote bindings so that the the correct endpoint is
>> obtained regardless of what someone has put in the SCDL, WSDL etc.
>>
>>
>>> Are you expecting that you can do a getService
>>>
>>>> for a non-wired service, i.e. a service with an explicit remote binding
>>>>
>>> such
>>>
>>>> as binding.ws, that is running in another VM.
>>>>
>>> Not sure what you mean by a non-wired service. Services with binding.ws
>>> can be wired too.
>>>
>> I was specifically asking about the case that you do a getService for a
>> service that defines binding.ws with all the trimmings, i.e. endpoint
>> information. Actually maybe this works already. I'll have to go and try.
>>
>>
>>> If so that we will need, as
>>>
>>>> Sebastien suggests, to be able to get hold of more information about the
>>>> remote component than I have taken account of to date so that a partial
>>>> model can be constructed in order to create the correct binding.
>>>>
>>>>
>>> Yes :)
>>>
>>>> 4 & 5 as above
>>>>
>>>> Simon
>>>>
>>>>
>>>>
>>> --
>>> Jean-Sebastien
>>>
>>>
>>> ---------------------------------------------------------------------
>>> 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
>
>
>
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
Re: Cross-jvm locate service
Posted by Kevin Williams <kj...@gmail.com>.
Sebastien and Simon,
Thanks for this conversation. Its been very helpful. I would like to
recap a little and ask a couple of questions.
At the highest level the steps to locate a service are:
1. Look locally and if found proceed as Tuscany does today, otherwise
2. Dynamically create a reference for the target service using
binding and end-point URI info
3. Create a CallableReference for that self-reference
4. Get a ServiceReference proxy to the service from the CallableReference
5. Return the ServiceReference
For an example of how to dynamically create a reference(2) you
mentioned: CompositeConfigurationBuilderImpl.createSelfReference() and
I assume you meant CompositeBuilderImpl.createSelfReference(Component,
ComponentService), right?
Since I won't have a ComponentService available I will need to somehow
provide the required binding and InterfaceContract information. I
think there are factories for these.
Can you point me to code that creates a CallableReference from a
ComponentReference (3) ?
Thanks!
--Kevin
On 8/9/07, Simon Laws <si...@googlemail.com> wrote:
> On 8/9/07, Jean-Sebastien Delfino <js...@apache.org> wrote:
> >
> > Comments inline.
> >
> > [snip]
> > Simon Laws wrote:
> > > Currently getServiceReference() expects a service name so we can rely
> > > on the implication that all contributed composites are notionally
> > included
> > > into the domain level composite to reference a component and extend
> > > Sebastien's process to say.
> > >
> >
> > Just to make sure it's clear, as I'm not sure I completely follow the
> > above sentence, components deployed to other nodes will not be present
> > in the in-memory composite model kept in an SCAdomain object.
>
>
> I was just pointing out that regardless of where a component is actually
> running one of it's services can be identified in the domain composite using
> the component/service name by virtue of the implicit inclusion of
> contributed composites into the domain composite. This is an important
> assumption as it means that people can arbitrarily locate services deployed
> into the domain. I was making no statement about what is in the model inside
> each JVM. I assume that the model in each JVM will contain whatever
> artifacts that have been contributed to that JVM.
>
> So if you have different contributions for each JVM in the domain then you
> get whatever is contributed to the JVM in your model. If you want to
> reference a component that is not part of the contributions loaded by the
> JVM then you are forced to look elsewhere in the distributed domain.
>
> If you want the components in a single contribution/composite to be
> distributed across JVMs then this is a different scenario. We have done this
> before with the distributed runtime by recording the component/JVM mapping
> in a topology file. This still doesn't imply that the components will make
> it into the model (although they do in the current distributed
> implementation).
>
> > 1. look for the target component model object in the in-memory domain
> > > composite kept in SCADomain
> > >
> > > if found
> > >
> > > 2. look for the target service on that component
> > > 3. find on that component the self-reference created for that service
> > > (these self-references are automatically created by CompositeBuilder for
> >
> > > each service provided by a component)
> > > 4. create a CallableReference for that self-reference
> > > 5. get a proxy to the service from the CallableReference
> > >
> > > else
> > >
> > > 2. look for the named component/serivce in other nodes of the
> > distributed
> > > (cross JVM) domain
> > > I am working up some interfaces to allow this to happen in the
> > distributed
> > > domain case, for example,
> > >
> > >
> > http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/modules/distributed/src/main/java/org/apache/tuscany/sca/distributed/management/ServiceDiscovery.java
> > > Not implemented just yet as I'm currently looking at the sca domain
> > > implementation but you get the idea.
> > > The implementation could use some simple repository implementation or
> > > could derive the information from file.
> > >
> > > 3. Create a local reference for the remote service
> > >
> >
> > Your if/else proposal looks good to me.
> >
> > > Not sure of the details here but you both seem happy that this is
> > > straightforward.
> > > The thing that does look problematic is determining the
> > > binding.
> >
> > Not so problematic if it's part of the info returned by your
> > ServiceDiscovery :)
>
>
> Agreed I just hadn't put it there yet because I was only dealing with the
> case where cross JVM call is constructed automatically with the sca binding.
> You are probably right that I should make it more generally applicable.
>
> > In the distributed case I assume that all cross JVM messaging are
> > > handled by the sca binding.
> >
> > No, any binding can be used inside an SCA domain.
>
>
> Sorry I misslead you here unintentionally.What I mean is that in the case I
> am concentrating on at the moment I'm only dealing with the sca binding. I
> didn't mean to imply that you can't manually specify remote bindings between
> components within an sca domain. If you do this though AND you specify the
> endpoint you are duty bound to bet it right. I.e. I'm not currently putting
> in code to fix up remote bindings so that the the correct endpoint is
> obtained regardless of what someone has put in the SCDL, WSDL etc.
>
> > Are you expecting that you can do a getService
> > > for a non-wired service, i.e. a service with an explicit remote binding
> > such
> > > as binding.ws, that is running in another VM.
> >
> > Not sure what you mean by a non-wired service. Services with binding.ws
> > can be wired too.
>
> I was specifically asking about the case that you do a getService for a
> service that defines binding.ws with all the trimmings, i.e. endpoint
> information. Actually maybe this works already. I'll have to go and try.
>
> > If so that we will need, as
> > > Sebastien suggests, to be able to get hold of more information about the
> > > remote component than I have taken account of to date so that a partial
> > > model can be constructed in order to create the correct binding.
> > >
> >
> > Yes :)
> > > 4 & 5 as above
> > >
> > > Simon
> > >
> > >
> >
> > --
> > Jean-Sebastien
> >
> >
> > ---------------------------------------------------------------------
> > 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: Cross-jvm locate service
Posted by Simon Laws <si...@googlemail.com>.
On 8/9/07, Jean-Sebastien Delfino <js...@apache.org> wrote:
>
> Comments inline.
>
> [snip]
> Simon Laws wrote:
> > Currently getServiceReference() expects a service name so we can rely
> > on the implication that all contributed composites are notionally
> included
> > into the domain level composite to reference a component and extend
> > Sebastien's process to say.
> >
>
> Just to make sure it's clear, as I'm not sure I completely follow the
> above sentence, components deployed to other nodes will not be present
> in the in-memory composite model kept in an SCAdomain object.
I was just pointing out that regardless of where a component is actually
running one of it's services can be identified in the domain composite using
the component/service name by virtue of the implicit inclusion of
contributed composites into the domain composite. This is an important
assumption as it means that people can arbitrarily locate services deployed
into the domain. I was making no statement about what is in the model inside
each JVM. I assume that the model in each JVM will contain whatever
artifacts that have been contributed to that JVM.
So if you have different contributions for each JVM in the domain then you
get whatever is contributed to the JVM in your model. If you want to
reference a component that is not part of the contributions loaded by the
JVM then you are forced to look elsewhere in the distributed domain.
If you want the components in a single contribution/composite to be
distributed across JVMs then this is a different scenario. We have done this
before with the distributed runtime by recording the component/JVM mapping
in a topology file. This still doesn't imply that the components will make
it into the model (although they do in the current distributed
implementation).
> 1. look for the target component model object in the in-memory domain
> > composite kept in SCADomain
> >
> > if found
> >
> > 2. look for the target service on that component
> > 3. find on that component the self-reference created for that service
> > (these self-references are automatically created by CompositeBuilder for
>
> > each service provided by a component)
> > 4. create a CallableReference for that self-reference
> > 5. get a proxy to the service from the CallableReference
> >
> > else
> >
> > 2. look for the named component/serivce in other nodes of the
> distributed
> > (cross JVM) domain
> > I am working up some interfaces to allow this to happen in the
> distributed
> > domain case, for example,
> >
> >
> http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/modules/distributed/src/main/java/org/apache/tuscany/sca/distributed/management/ServiceDiscovery.java
> > Not implemented just yet as I'm currently looking at the sca domain
> > implementation but you get the idea.
> > The implementation could use some simple repository implementation or
> > could derive the information from file.
> >
> > 3. Create a local reference for the remote service
> >
>
> Your if/else proposal looks good to me.
>
> > Not sure of the details here but you both seem happy that this is
> > straightforward.
> > The thing that does look problematic is determining the
> > binding.
>
> Not so problematic if it's part of the info returned by your
> ServiceDiscovery :)
Agreed I just hadn't put it there yet because I was only dealing with the
case where cross JVM call is constructed automatically with the sca binding.
You are probably right that I should make it more generally applicable.
> In the distributed case I assume that all cross JVM messaging are
> > handled by the sca binding.
>
> No, any binding can be used inside an SCA domain.
Sorry I misslead you here unintentionally.What I mean is that in the case I
am concentrating on at the moment I'm only dealing with the sca binding. I
didn't mean to imply that you can't manually specify remote bindings between
components within an sca domain. If you do this though AND you specify the
endpoint you are duty bound to bet it right. I.e. I'm not currently putting
in code to fix up remote bindings so that the the correct endpoint is
obtained regardless of what someone has put in the SCDL, WSDL etc.
> Are you expecting that you can do a getService
> > for a non-wired service, i.e. a service with an explicit remote binding
> such
> > as binding.ws, that is running in another VM.
>
> Not sure what you mean by a non-wired service. Services with binding.ws
> can be wired too.
I was specifically asking about the case that you do a getService for a
service that defines binding.ws with all the trimmings, i.e. endpoint
information. Actually maybe this works already. I'll have to go and try.
> If so that we will need, as
> > Sebastien suggests, to be able to get hold of more information about the
> > remote component than I have taken account of to date so that a partial
> > model can be constructed in order to create the correct binding.
> >
>
> Yes :)
> > 4 & 5 as above
> >
> > 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: Cross-jvm locate service
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Comments inline.
[snip]
Simon Laws wrote:
> Currently getServiceReference() expects a service name so we can rely
> on the implication that all contributed composites are notionally included
> into the domain level composite to reference a component and extend
> Sebastien's process to say.
>
Just to make sure it's clear, as I'm not sure I completely follow the
above sentence, components deployed to other nodes will not be present
in the in-memory composite model kept in an SCAdomain object.
> 1. look for the target component model object in the in-memory domain
> composite kept in SCADomain
>
> if found
>
> 2. look for the target service on that component
> 3. find on that component the self-reference created for that service
> (these self-references are automatically created by CompositeBuilder for
> each service provided by a component)
> 4. create a CallableReference for that self-reference
> 5. get a proxy to the service from the CallableReference
>
> else
>
> 2. look for the named component/serivce in other nodes of the distributed
> (cross JVM) domain
> I am working up some interfaces to allow this to happen in the distributed
> domain case, for example,
>
> http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/modules/distributed/src/main/java/org/apache/tuscany/sca/distributed/management/ServiceDiscovery.java
> Not implemented just yet as I'm currently looking at the sca domain
> implementation but you get the idea.
> The implementation could use some simple repository implementation or
> could derive the information from file.
>
> 3. Create a local reference for the remote service
>
Your if/else proposal looks good to me.
> Not sure of the details here but you both seem happy that this is
> straightforward.
> The thing that does look problematic is determining the
> binding.
Not so problematic if it's part of the info returned by your
ServiceDiscovery :)
> In the distributed case I assume that all cross JVM messaging are
> handled by the sca binding.
No, any binding can be used inside an SCA domain.
> Are you expecting that you can do a getService
> for a non-wired service, i.e. a service with an explicit remote binding such
> as binding.ws, that is running in another VM.
Not sure what you mean by a non-wired service. Services with binding.ws
can be wired too.
> If so that we will need, as
> Sebastien suggests, to be able to get hold of more information about the
> remote component than I have taken account of to date so that a partial
> model can be constructed in order to create the correct binding.
>
Yes :)
> 4 & 5 as above
>
> 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: Cross-jvm locate service
Posted by Simon Laws <si...@googlemail.com>.
On 8/8/07, Jean-Sebastien Delfino <js...@apache.org> wrote:
>
> Kevin Williams wrote:
> > I am interested in extending the current locate service capability to
> > support the location of services that may be running within the same
> > domain but a separate jvm. The most straightforward approach may be
> > to dynamically create and return a service reference using the same
> > Tuscany runtime elements that now create service references for
> > injection in support of the @reference annotation.
> >
> > Any thoughts or pointers would be appreciated.
> >
> > Thanks,
> >
> > --Kevin
> >
>
> This sounds good to me. I guess you're talking about
> SCADomain.getService(targetComponentName/targetServiceName). We've been
> flip-flopping between locateService/getService a few times :) ... Here
> are a few more thoughts.
>
> First here's how SCADomain.getService() currently works:
> 1. look for the target component model object in the in-memory domain
> composite kept in SCADomain
> 2. look for the target service on that component
> 3. find on that component the self-reference created for that service
> (these self-references are automatically created by CompositeBuilder for
> each service provided by a component)
> 4. create a CallableReference for that self-reference
> 5. get a proxy to the service from the CallableReference
>
> Some pointers to code:
> [1] and [2] ->
>
> org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.getServiceReference
> ()
> [3] and [4] ->
>
> org.apache.tuscany.sca.core.component.ComponentContextImpl.createSelfReference
> ()
> [5] -> org.apache.tuscany.sca.core.component.CallableReferenceImpl
>
> Now, when the target component/service runs in a different JVM, you
> won't have an in-memory model object representing it :( but that's not a
> big issue :) ... As you suggested you can simply create a local
> reference and bind it to the target service (assuming you know its
> binding type and endpoint URI), then proceed to get a CallableReference
> and a proxy for it as usual.
>
> This gives us the following steps:
> 1. determine the binding type and endpoint URI of the target
> component/service you're looking for (I won't get into the details of
> how to do that here, as I think Simon is covering it in his distributed
> binding implementation)
> 2. dynamically create a reference for your target service and configure
> it with that binding and endpoint URI
> 3. perform steps [4] and [5] from above.
>
> For step 2,
>
> org.apache.tuscany.sca.assembly.builder.impl.CompositeConfigurationBuilderImpl.createSelfReference
> ()
> shows how to create a reference from a service.
>
> Hope this helps.
>
> --
> Jean-Sebastien
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
> Hi Kevin
This seems to fit with the distributed work. I hadn't considered opening
this up to DefaultSCADomain.getServiceReference() but I don't see why that
shouldn't be done. Let me just ask a few questions to make sure I'm clear
about what you are after.
> location of services that may be running within the same
> domain but a separate jvm
How are you intending to refer to the service that is running in a separate
JVM. Currently getServiceReference() expects a service name so we can rely
on the implication that all contributed composites are notionally included
into the domain level composite to reference a component and extend
Sebastien's process to say.
1. look for the target component model object in the in-memory domain
composite kept in SCADomain
if found
2. look for the target service on that component
3. find on that component the self-reference created for that service
(these self-references are automatically created by CompositeBuilder for
each service provided by a component)
4. create a CallableReference for that self-reference
5. get a proxy to the service from the CallableReference
else
2. look for the named component/serivce in other nodes of the distributed
(cross JVM) domain
I am working up some interfaces to allow this to happen in the distributed
domain case, for example,
http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/modules/distributed/src/main/java/org/apache/tuscany/sca/distributed/management/ServiceDiscovery.java
Not implemented just yet as I'm currently looking at the sca domain
implementation but you get the idea.
The implementation could use some simple repository implementation or
could derive the information from file.
3. Create a local reference for the remote service
Not sure of the details here but you both seem happy that this is
straightforward. The thing that does look problematic is determining the
binding. In the distributed case I assume that all cross JVM messaging are
handled by the sca binding. Are you expecting that you can do a getService
for a non-wired service, i.e. a service with an explicit remote binding such
as binding.ws, that is running in another VM. If so that we will need, as
Sebastien suggests, to be able to get hold of more information about the
remote component than I have taken account of to date so that a partial
model can be constructed in order to create the correct binding.
4 & 5 as above
Simon
Re: Cross-jvm locate service
Posted by Jean-Sebastien Delfino <js...@apache.org>.
Kevin Williams wrote:
> I am interested in extending the current locate service capability to
> support the location of services that may be running within the same
> domain but a separate jvm. The most straightforward approach may be
> to dynamically create and return a service reference using the same
> Tuscany runtime elements that now create service references for
> injection in support of the @reference annotation.
>
> Any thoughts or pointers would be appreciated.
>
> Thanks,
>
> --Kevin
>
This sounds good to me. I guess you're talking about
SCADomain.getService(targetComponentName/targetServiceName). We've been
flip-flopping between locateService/getService a few times :) ... Here
are a few more thoughts.
First here's how SCADomain.getService() currently works:
1. look for the target component model object in the in-memory domain
composite kept in SCADomain
2. look for the target service on that component
3. find on that component the self-reference created for that service
(these self-references are automatically created by CompositeBuilder for
each service provided by a component)
4. create a CallableReference for that self-reference
5. get a proxy to the service from the CallableReference
Some pointers to code:
[1] and [2] ->
org.apache.tuscany.sca.host.embedded.impl.DefaultSCADomain.getServiceReference()
[3] and [4] ->
org.apache.tuscany.sca.core.component.ComponentContextImpl.createSelfReference()
[5] -> org.apache.tuscany.sca.core.component.CallableReferenceImpl
Now, when the target component/service runs in a different JVM, you
won't have an in-memory model object representing it :( but that's not a
big issue :) ... As you suggested you can simply create a local
reference and bind it to the target service (assuming you know its
binding type and endpoint URI), then proceed to get a CallableReference
and a proxy for it as usual.
This gives us the following steps:
1. determine the binding type and endpoint URI of the target
component/service you're looking for (I won't get into the details of
how to do that here, as I think Simon is covering it in his distributed
binding implementation)
2. dynamically create a reference for your target service and configure
it with that binding and endpoint URI
3. perform steps [4] and [5] from above.
For step 2,
org.apache.tuscany.sca.assembly.builder.impl.CompositeConfigurationBuilderImpl.createSelfReference()
shows how to create a reference from a service.
Hope this helps.
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org