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