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 <[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]
