more comments inline On 8/6/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote: > > Comments inline. > > Simon Laws wrote: > > I want to get the distributed version of the SCA Binding up and running > > again now the new wiring code is done and the SCA Binding is only > created > > when required. We need to create a mechanism to switch off/override the > > local SCA binding when it's not appropriate and then choose the > appropriate > > distributed binding in place of the local binding. > > Currently the default SCA Binding model is defined and implemented in > > o.a.t.s.assembly.The runtime artifacts (providers etc.) for the local > SCA > > Binding are in o.a.t.s.core.runtime. > > > > I didn't think that we had two different bindings, distributed and local. > > I'd like to suggest the following: > > One SCA binding implementation, packaged as a binding extension, i.e. > separate from assembly and core. The assembly module should only retain > the SCABinding and SCABindingFactory interfaces. > > To allow the SCA binding model to be used without dragging its runtime > implementation, we'd adopt a layering similar to the WS binding or Java > implementation: > - binding-sca, the SCA binding model implementation classes > - binding-sca-xml, support for reading / writing SCA bindings in SCA > assembly XML > - binding-sca-xyz, runtime implementation of the SCA binding using > technology xyz (axis2, jms, or whatever else we want to use) > > The SCA binding runtime implementation should be capable of local and > remote invocations: > - location invocations when the target service exists within the same in > memory assembly model > - remote invocations when the target service does not exist within the > same in memory assembly model because it's in a different classloader, > Geronimo module, or even JVM) > > Finally, I think it would be good if we could start to leverage the WS > binding for remote invocations. It'll be more lightweight than JMS and > easier to distribute too as it won't rely on a central message queue > server.
OK, I think this matches with what I want although I hadn't thought of making the model separate from the runtime so I'll go ahead an create binding-sca-xml, binding-sca-axis2, binding-sca-jms to sit alongside the binding-sca and move the current classes to the appropriate places. I'll start to bring up the axis2 code. Not sure about maintaining the JMS support just yet but don't want it to disappear altogether. > We need to extend the SCA Binding model to take account of domain > topology > > information. In the current distributed runtime this information is > > available from the domain but is only dealt with by the > CompositeActivator > > when replacing the SCA Binding with remote bindings when required. I > think > > we can make the SCA Binding a bit smarter and record its local/remote > status > > more directly. The topology information should still be maintained by > the > > domain but it should be accessible by the SCA Binding in a form that, > given > > two components, the SCA Binding can tell whether a local or remote > binding > > is required. > > > > I'm planning to make a few small changes to the CompositeBuilder to help > with this. The changes will not give you the address of a > component/service, but at least will allow you to determine if it's > local or remote. > > I'll post more about this later. I await with bated breath. > A remote service SCA Binding needs to advertise the endpoint at which its > > service is available. Again this is a domain issue and the process for > doing > > this should be managed by the domain through an interface that allows > the > > service name and protocol specific URL to be registered. > > > > Yes, I was thinking about a simple address service maintaining: > component/service -> http://host:port/path Ok, I created an initial interface here a while ago but then went on holiday so haven't done anything with it yet ( http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/modules/distributed/src/main/java/org/apache/tuscany/sca/distributed/management/ServiceDiscovery.java). I would like the interface implemtation for be invisible from the SCA Binding point of view so the node starts an SCADomain/Runtime with appropriate pointers to the service discovery function. As long as the SCA Binding can see this function it could be implemented as a local file read or a centralized service, or something else, and the SCA Binding won't care but will still be able to access endpoint information. > A remote reference SCA Binding need to determine the endpoint at which the > > remote service is available, by asking the domain for the protocol > specific > > URL given a service name, and configure the physical binding > appropriately. > > > > If we start with the SCA binding just wrappering the WS binding Axis2 > implementation then its easy, we just need to configure it with the > endpoint address obtained from the address service. see above > In both cases a matching distributed binding needs to be chosen at both > > ends. Previously we created a binding-sca module to contain the extra > code > > required for handling the distributed aspects of the SCA Binding. I > think it > > would be useful to maintain this separation in the event that we want to > > provide alternative protocols for the distribute SCA binding. I'm > wondering > > if we should go with something more specific such as binding-sca-ws, > > binding-sca-jms. > > How about binding-sca-axis2? OK > The protocol a domain uses could then be controlled using > > the usual extension mechanism. Doing this does imply that the correct, > i.e. > > local or distributed, binding provider factory can be located. This is > done > > currently based on the binding type in the model so this will have an > impact > > on how we factor the SCA Binding model. > > > > Not sure there's an issue, if we just make sca-binding-axis2 available > on the classpath it'll be picked up and the right BindingProviderFactory > will be used. I think your suggestion of packaging the model code and runtime code in separate modules is the answer to this. > Am hoping to get a bit of discussion going here to help me understand the > > changes that have recently been made to the wiring code and the SCA > binding > > so that the distributed version provides a neat extension to the new > > features. > > > > Simon > > > > > -- > Jean-Sebastien > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
