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