Distributed SCA Binding

[Simon Laws <si...@googlemail.com>]

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.

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.

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.

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.

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

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

Re: Distributed SCA Binding

[Simon Laws <si...@googlemail.com>]

On 8/6/07, Simon Laws <si...@googlemail.com> wrote:
>
> more comments inline
>
> On 8/6/07, Jean-Sebastien Delfino < jsdelfino@apache.org> 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: tuscany-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: tuscany-dev-help@ws.apache.org
> >
> >
> 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/tuscany-dev@ws.apache.org/msg21229.html

Re: Distributed SCA Binding

[Simon Laws <si...@googlemail.com>]

more comments inline

On 8/6/07, Jean-Sebastien Delfino <js...@apache.org> 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: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>

Re: Distributed SCA Binding

[Jean-Sebastien Delfino <js...@apache.org>]

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: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org