[2.x] Matching an EndpointReference to the target Endpoint

[Raymond Feng <en...@gmail.com>]

Hi,

I'm working on the policy matching between an EndpointReference and an 
Endpoint. Thinking in a big picture, the following is a list of things we 
have to deal with. I hope we can further refine our code as part of this 
exercise.

1. Check if an endpoint is a suitable target for a given endpoint reference
    a) Check the compatibility of interface contracts
        * InterfaceContractMapper
    b) Check the compatibility of policy configurations (intents and 
policySets)
        * PolicyBuilder?  (I'm trying to come up some SPIs here)

2. Find the local target endpoint during build phase
    * EndpointReferenceBuilderImpl
    a) via @target (look up an endpoint in the same composite that matches 
the structural URI)
    b) via autowiring (look up an endpoint in the same composite that is 
compatible)

NOTE: the current implementation looks up the target component/service and 
create endpoints out of them. I think we should match against the existing 
endpoints and (we set the matching endpoint as the "targetEndpoint" 
attribute of endpoint reference).

3. Bind an endpoint reference to an endpoint in the EndpointRegistry (if the 
endpoint reference uses an SCA URI)
    * EndpointReferenceBinder
        * There is no binding configured on the reference (get the binding 
configuration from the endpoint)
        * There is a binding configured on the reference

NOTE: 2 and 3 will follow the same criteria to find the matching endpoint(s) 
for a given endpoint reference.

4. Create an endpoint reference from the endpoint (ComponentContextImpl)
    * Lookup a service proxy (or ServiceReference) from the Node API
    * Create a service proxy for SCA client API

Thanks,
Raymond
---
Raymond Feng
Apache Tuscany PMC Member: http://tuscany.apache.org
Co-author of Tuscany In Action (A book on Tuscany SCA): 
http://tuscanyinaction.com/
 

Re: [2.x] Matching an EndpointReference to the target Endpoint

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

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

Re: [2.x] Matching an EndpointReference to the target Endpoint

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

...snip
>
> 1. Check if an endpoint is a suitable target for a given endpoint reference
>   a) Check the compatibility of interface contracts
>       * InterfaceContractMapper
>   b) Check the compatibility of policy configurations (intents and
> policySets)
>       * PolicyBuilder?  (I'm trying to come up some SPIs here)
>
> 2. Find the local target endpoint during build phase
>   * EndpointReferenceBuilderImpl
>   a) via @target (look up an endpoint in the same composite that matches the
> structural URI)
>   b) via autowiring (look up an endpoint in the same composite that is
> compatible)
>
> NOTE: the current implementation looks up the target component/service and
> create endpoints out of them. I think we should match against the existing
> endpoints and (we set the matching endpoint as the "targetEndpoint"
> attribute of endpoint reference).

Agreed, and in this case we could do the policy matching at this
point. There used to be a method set up ready to do that but it
disappeared at some stage. Doing policy matching on local endpoints at
build time rather than waiting until runtime is advantageous because
it identifies any errors early on the the deployment process.

Of course, in the case where no matching endpoint is found locally for
the target name we can't do matching until runtime.

>
> 3. Bind an endpoint reference to an endpoint in the EndpointRegistry (if the
> endpoint reference uses an SCA URI)

We only need to do this if the endpoint has not been located at build time.

>   * EndpointReferenceBinder
>       * There is no binding configured on the reference (get the binding
> configuration from the endpoint)
>       * There is a binding configured on the reference

I note that I don't think the matching code takes account of this at
the moment and always assumes that the binding is taken from the
matching endpoint

>
> NOTE: 2 and 3 will follow the same criteria to find the matching endpoint(s)
> for a given endpoint reference.
>
> 4. Create an endpoint reference from the endpoint (ComponentContextImpl)
>   * Lookup a service proxy (or ServiceReference) from the Node API
>   * Create a service proxy for SCA client API

Not sure I understand what you are saying in point 4.

Simon