On 8/6/07, Simon Laws <[EMAIL PROTECTED]> wrote: > > 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] > > > > > I've just taken the initial step of moving the current sca binding implementation code we currently have out of assembly and into binding-sca and binding-sca-xml. No integration with the distributed piece yet but the first step. There are a couple of points worth noting
What is there now will change as we add the distributed code back in I've added a test implementation of SCA binding in assembly-xml to prevent cyclic dependency given the tests that are currently there I Can't get to the BaseArtefactProcessor as it is abstract in assembly-xml so I've copied code for now. There is a separate discussion on this subject [1] I currently maintain two constructors in SCABindingProcessor as somethings required the old form. This is a todo I have experienced the usual mvn weirdness in getting this to work due to the changing dependencies. The hierarchy now is pretty much that binding-sca sits directly on top of assembly. Several things reference binding-sca explicitly now. It's not loaded as an extension. binding-sca-xml is loaded as an artifact processor using the new service base loading mechanism. Anyhow I expect you will find you need to do a mvn clean and will have to remove sca artifacts from you local repo to make this work. Simon [1] http://www.mail-archive.com/[email protected]/msg21229.html
