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