SwitchYard Clustering same targetNamespace limitation

[yusufb]

I would like to use the targetNamespace attribute on a composite service to uniquely DEFINE AND VERSION a service. I would like to use a convention like "urn:group-id:service-id:service-version" for the targetNamespace. For example, 2 versions of the same service could be:

1. urn:switchyard-evaluation:simple-service:1.0
2. urn:switchyard-evaluation:simple-service:1.1

These 2 versions of this service could run simultaneously on a SwitchYard cluster. By forcing the targetNamespace of dependent services to be the same, we cannot use this convention (to either define the service-id or service-version, since both service deployments must have exactly the same targetNamespace). This also results in the versions of all shared/dependent services to be fixed (we cannot modify one service version in the stack while leaving the others unchanged). It seems that it is not possible to specify which version of a service we depend on.

To resolve this issue, is it possible to perhaps specify a different targetNamespace in the service reference? For example:

<sca:reference name="IServiceProvider" multiplicity="0..1" promote="IServiceProvider/IServiceProvider" targetNamespace="urn:switchyard-evaluation:simple-service:1.0">
    <sca:interface.java interface="za.co.bla.switchyard.services.IServiceProvider"/>
    <remote:binding.remote />
 </sca:reference>

Or am I missing the point completely?

Thanks!

Yusuf.

[kcbabo]

Hey Yusuf,

You're not missing the point at all.  Just happened to catch us in the middle of a work in progress. :-)  The requirement for a shared targetNamespace is a temporary limitation.  The ability to set the target namespace and even the target service name will likely be specified via the binding.remote definition.  This same requirement exists within a single instance if you want one application to talk to another with a different namespace.  We have considered using the binding.sca defintion in the SCA assembly spec to address both cases (effectively replacing binding.remote).  If you have an opinion one way or the other on this, now is the perfect time to share! 

cheers,

keith