On Mon, Oct 13, 2008 at 2:08 AM, Raymond Feng <[EMAIL PROTECTED]> wrote:
> I'm wondering if we can combine the Endpoint and RRB efforts together. Here > are some ideas: > > 1) An SCA service has a list of Endpoints representing the end point for > each binding protocol. > > 2) An SCA reference has 0..N Endpoints depending on the multiplicity of the > reference. > > 3) Each endpoint has a binding interface contract. If it's not known before > the operation selector, then it's an "Any" interface with an "Any" > operation. > > 4) There is one invocation chain for each endpoint (based on the binding > interface contract) and one for the SCA service or reference. The two > invocation chains are connected as we described on the wiki page. For a SCA > service configured with multiple bindings, there will be multiple endpoint > invocation chains connecting to the same service invocation chain. It's > similar for SCA references. > > Thanks > Raymond > > Hi Raymond, +1 from me. Working with your list here are some more thoughts... 1) An SCA service has a list of Endpoints representing the end point for each binding protocol. The builder can be extended to generate this list. Initially based on configured bindings. Ultimately I'd like to see the list populated with promoted endpoints as well rather than relying on $promoted$ services. Not something for the first iteration though. 2) An SCA reference has 0..N Endpoints depending on the multiplicity of the reference. This is already in place. The endpoints are currently created by the builders and the output of the endpoint processing is used to populate the computed binding list. We need to remove this second stage and updated the activators just to work off of Endpoints. Currently the activators only work off Endpoints if the referenced service can't be found 3) Each endpoint has a binding interface contract. If it's not known before the operation selector, then it's an "Any" interface with an "Any" operation. In what situation isn't the binding interface contract known. It anything I'd say it was a question of wireFormat rather than operationSelection but I'm probably missing something here. 4) There is one invocation chain for each endpoint (based on the binding interface contract) Can we merge the Endpoints we are discussing here with the EndpointRefs that are held currently by wires? 4a) The endpoint model on the reference side should give rise to an EndpointProvider (I'm probably convinced that we should change Resolver back to Provider) which in turn gathers binding specific endpoint providers that can be used to resolve the Endpoint (find the referenced service) in a binding specific way if required. 4b) the endpoint model in the service side should also give rise to an EndpointProvider. I can see that on the service side we can have the multple endpoint invocation chains call into the single service invocation chain. However on the reference side I don't think this is the case as a proxy will be targeting a particular service over a specific binding. Hence we need to associate the end of the reference chain with a specific binding invoker. Won't it be better to stick with a full set of chains for each Endpoint? I think we can leverage the endpoint idea to help us build out the RRB wires without messing up the runtime in the mean time. Regards Simon
