On Mon, Jun 15, 2009 at 11:37 PM, Raymond Feng<[email protected]> wrote: > Hi, > > Now we have Endpoint/EndpointReference models to encapsulate the metadata > for <component, service/reference, binding>. I think we should better align > the core-spi to the Endpoint/EndpointReference to further simplify the > invocation/extension code. > > a) Move the methods from RuntimeWire to Endpoint/EndpointReference > (potentially RuntimeEndpoint/RuntimeEndpointReference)
+1 I still think the idea of having a wire at each end of the SCA wire leads to much confusion. I was thinking that we should at least have separate service and reference wires but getting rid of it is clearer. > > 1) Endpoint owns the service binding invocation chain (one per Endpoint) > and the service invocation chains (one per Operation) +1 If' we're still going to use an EndpointReference to represent the binding end of the chain we need to take account of that. We could probably do without it but it would need a bit of reworking in the runtime. > 2) EndpointReference owns the reference invocation chains (one per > Operation) and the reference binding invocation chain (one per > EndpointReference) +1 > 3) For local wires over a given binding, the EndpointReferenceProvider for > the binding is responsible for finding the corresponding service invocation > chain from > the Endpoint and dispatch the invocations to it. This can be done in > the BindingInvoker. And we need to decide what information in the EndpointReference allows this optimization to happen effectively > > b) Remove methods that looks up by binding from > RuntimeComponentService/RuntimeComponentReference and push them onto the > Endpoint/EndpointReference if necessary. +1 > > c) Simplify the > BindingProviderFactory/ServiceBindingProvider/ReferenceBindingProvider SPIs: > > 1) Replace the component/service/binding tuple with Endpoint > 2) Replace the component/reference/binding tuple with EndpointReference +1 We should also look at how much of the runtime digs into the contents of components, services and references to try and improve the separation of the runtime from the model. Just to help up with the notion of Endpoint/EndpointReference serialization. We need to clarify the way that we indicate the status of an EndpointReference. At the moment we are relying on the "unresolved" flags on EndpointReference and Endpoint to determine a rather involved set of states. I would prefer we move to something more explicit to indicate EndpointReference wired to an Endpoint that is not yet in the domain EndpointReference wired to an Endpoint that is known to be in the domain but which we haven't matched against yet EndpointReference wired to an Endpoint where the binding and location it known EndpointReference that is not wired Simon
