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 <[EMAIL PROTECTED]> wrote:
On 8/9/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
