Had a quick offline with Raymond about this and a few additional points came up...
- We should look at splitting the policy builder up as it comes too late at the moment to help out with endpoint matching at deployment time. I.e. part of the endpoint matching scheme relies on policies and they aren't currently applied until the policy builder - The two matching phases (2 and 3 in the first mail in this thread) could be made a lot more consistent if we always rely on the registry interface when looking for endpoints. The flip side of this is that currently the endpoints are not added to the registry until activation. This doesn't however stop us from fluffing up a local endpoint matching registry using the same interface in order that the matching algorithm code is the same in both cases. We could add them to the main registry but would have to have a flag to stop them being propagated which is extra complexity. We need to investigate what the algorithm would look like if can use the registry interface in both cases. - Having the same algorithm at deploy and rutime will make some of the dynamic scenarios more achievable however there is still a lot o complexity in there. Particularly around things like domain level autowire. This particular feature is not mandatory so we need to think about whether we really want to support it. - We need to look at what OASIS says about domain level matching when target service is not there. At the moment the runtime creates an unmatched endpoint reference and expects to match it at runtime. Is this sufficient. So few questions to answer here. Regards Simon
