The ServiceDomain instance can be used to dynamically register services.  It's what we use in the deployer to register services in a deployment.  Now, the real question is in what context would you be doing this?  A concrete example / use case would help.

This is great, thanks.  Comments inline:

 

1. We have a set of different Service Types (potentially running with different versions).

2. Service Types are known at development time.

This is an important point - dependencies are known at development-time for a service.  The actual resolution of an implementation/endpoint for the dependencies is external from the service implementation.  IOW, document the dependency and contract and defer the resolution to the runtime.

 

3. Service Instances have a different life cycle than the Switchyard Application. These are created and destroyed at runtime.

4. Directing a message to one instance or the other depends on logic that takes into account the exchange information (headers and/or body) as well as the service Instance information.

#3 is true for any referenced service that resides outside the application.  So agree there.

#4 is likely an extension point that's required in SY core.  Something like an addressing handler which has access to the exchange and a reference to the registry.  I actually think this might coincide with another change I've been thinking of which specifically identifies bindings and includes binding metadata in the registry.  That would give you the information you needed to make an addressing decision I think.

From my point of view this would require having a publicly available API for dealing with the registry in order to register/deregister service instances references.

Yes on having a hook in a handler to get a reference to the registry.  I view this as an extension/customization point for the runtime vs. something a service implementation uses directly.

In terms of registering endpoints dynamically, that's something that requires more thought.  I understand what you're after here and just need to give it a bit more consideration in terms of how that would wire in.  Going back to our conversation on IRC, I think another use case that can be satisfied with this approach is WS-Addressing style cases where an endpoint reference is included with an invocation.

For this case, you should be able to register an interceptor/auditor and pull the service domain off of the exchange as it's in flight.  Unfortunately, it looks like the API only permits the service domain to be retrieved from the service and not the service reference.  This is a problem for your use case, since you want to preempt the addressing handler and supply your own address based off the service reference.  I have filed a JIRA to take care of this oversight:

https://issues.jboss.org/browse/SWITCHYARD-1151

We should be able to bang that out in the first week of 0.7, so please come back and holler if you don't see an update.  Once that is in place, you will want to register an @Auditor around Processors.ADDRESSING and query/assign a provider there.  Some background on auditing:

https://docs.jboss.org/author/display/SWITCHYARD/Auditing+Exchanges