With reference to this previous mail that included discussion on endpoints [1] and the other endpoint discussions it in turn references [2][3][4]. We got the RRB piece done in 1.x but the endpoint piece was held over to 2.x. Now's the time?
>From all these posts here are some suggested changes. The motivation here is to; - clearly express the idea that the combination of a reference or service with a binding implies a single endpoint that can take part in wiring - rationalize the two endpoint and wire structures we have in 1.x - include pluggable support for late binding for those who want to do this kind of thing - if possible tidy the $promoted representation and resolve to new endpoints rather than new services. Structural changes - combine endpoint and endpoint reference into a single endpoint structure - remove endpoint wire so we are left with a single wire representation - allow runtime services to hold a list of active endpoints - allow runtime references to hold a list of target endpoints - add endpoint providers in place of the endpoint resolver - we could look at allowing endpoints to serialize themselves so bindings can use this for callback support. I know Raymond mentioned this previously so I hope he'll add more details. Procedural changes - Reference -- create reference endpoints based on the either targets, bindings or autowire -- don't re-write the reference binding list in memory -- change the activator so that endpoints are used to drive wire creation rather than bindings. -- create a runtime wire in a similar way as now but allow a wire to be created with no binding parts for unresolved endpoints. -- provide an endpoint resolution hook point in the providers for people who want to do resolution at runtime - Service -- create an endpoint to represent and active binding for the service. Allows promotion to add new endpoints without changing the service binding list -- wire creation similar to now but driven by endpoints and not bindings Roundtripping Using endpoints allows us to maintain the binding lists as is. However we need to be able to support the domain re-writing of bindings we have currently. Reference targets give rise to endpoints and resolved endpoints relate to a configured bindings. It is not valid to have both configured bindings and targets so we convert targets to configured bindings in the domain and write them out to the SCDL that's passed to a node. If we allow for unresolved targets we have a problem of how to represent them in SCDL in this domain re-writing case. There is no SCDL structure that represent and endpoint. We need somthing like a tuscany:binding.unresolved that can hold the endpoint information which can then be reconstituted by the node for use at runtime. Thoughts? Simon [1] http://www.mail-archive.com/[email protected]/msg02902.html [2] http://cwiki.apache.org/confluence/display/TUSCANYWIKI/Roadmap+Discussion [3] http://marc.info/?l=tuscany-dev&m=121318046912690&w=2 [4] http://issues.apache.org/jira/browse/TUSCANY-2382
