...

A - V1.1 and V1.0 completely separate

B - V1.1 and V1.0 composite in the same domain

Handling both v1.1 and v1.0 policies

Image Removed

Need policies in both namespaces represented. Create side by side defintions.xml files in extensions

B-1 Just running in the same domain

Need both types of processors and a shared model. With separate nodes, v1.0 and v1.1 runtimes could be seaprated. Doesn't seem to be much advantage over independent operation

B-2 Running and interacting in the same domain

Need Either need both types of processors and a shared model . With separate nodes, v1.0 and v1.1 runtimes could be separatedor support the domain with the new distributed endpoint registry. The V1.1 and v1.0 runtimes remain separate and are run in separate nodes, i.e. you either start a 1.1 or a 1.0 node. A single node (our runtime) doesn't support both. Need an interoperable binding.sca (we have this at the moment as it is based on binding.ws)

...

across v1.1 and v1.0)

Handling both v1.1 and v1.0 policies

Image Added

Need policies in both namespaces represented. Create side by side defintions.xml files in extensions?

C V1.1 component implemented using V1.0 composite

Need both types of processors and a shared model. Need a shared runtime, i.e. some flexibility in builders, pluggable conversations and callbacks. Not sure about activation.

D V1.1 implemented using implementation.osoa (or similar)

Image Added