More comments in line... Simon
> Created a separate factory for it (separate as I though the model may need >> to be pluggable as some point) >> > > Would it be possible to just add the create method the AssemblyFactory? Yep, we could do that. Am going to hold back for a little while on this in case we decide we need the extra flexibility. > > > Created a new EndpointProvider type and associated factory. >> > > I assume the "EndpointProvider" is a system utility that match/resolve the > endpoints based on the reference/service binding configurations. If so, I > suggest that name it differently such as EndpointResolver and we can just > have the interface and default impl (no factory is required). We use the > term Provider for binding/implementation extensions to provide their > specific logic into Tuscany. > I'm not opposed to changing the name but this is function that I expect others to be provided in a pluggable way without having to change the core Tuscany functionality. How would this work without a factory? > > Created an Endpoint module to provide a provider implementation. >> Created an Endpoint wire to trap attempted calls over unresolved endpoints >> Separated off the Endpoint builder code into a new builder class. Same >> code >> but easier to identify. >> Added an endpoint collection to references >> Used the Endpoint in the wire builder in place of the old internal target >> structure. The logic is weaved in to the existing logic as follows. >> For references with no target, put the binding into reference binding as >> before >> > > I think it would be better to create an endpoint for the reference without > target. There could be two cases, autowiring and binding with explicit URI > to external services. Autowiring and binding with URI that equates to a target component service name are considered as references with a target and have and endpoint constructed. Bindings with explicit URI that don't equate to the name of a component service are currently not represented by an endpoint. We could create and endpoint in this latter case but I didn't want to upset the current code that covers this case. You are, I think suggesting, we move to the next level where we represent all combinations with Endpoints. I was nervous about taking that step in the first instance. > > A few examples will help, for example: > > <reference name="myRef" target="C1/S1"> > <binding.x/> > <binding.y/> > </reference> = Endpoint with a target name of "C1/S1" and candidate bindings X and Y > > > <reference name="myRef" target="C1/S1 C2/S1"> > <binding.x/> > <binding.y/> > </reference> = Enpoint with a target name of "C1/S1" and candidate bindings X and Y Enpoint with a target name of "C2/S1" and candidate bindings X and Y > > <reference name="myRef"> > <binding.x/> > <binding.y/> > </reference> Autowire set on the component or composite = zero or one Endpoints with candidate bindings X and Y Autowire not set = no Endpoint > > > <reference name="myRef"> > <binding.x uri="http://x"/> > <binding.y uri="http://y"/> > </reference> > > Assuming that there is no component call "X" or "Y" = No Endoints. Although I agree that in this case we could create an Endpoint representation. Another case: <reference name="myRef"> <binding.x uri="C1/S1 <http://x/>"/> </reference> > > Create an Endpoint for all explicit reference targets >> For resolved endpoints (Endpoints where the target is resolved) put the >> binding into reference bindings, i.e. the same as before >> For unresolved endpoints create an endpoint provider and a wire. We don't >> have unresolved targets in tuscany (except in the sca binding test) so >> should not happen. If you do put a target name in that can't be matched >> with >> a service you'll get a warning. >> >> If there is no Endpoint module on the classpath it will not create a >> provider or a wire hence disabling any Endpoint based processing. The >> Endpoint model will still be used though >> >> As part of this change I've updated the logic that looks for target names >> in >> binding uri. It's now applied to all binding types which I believe is what >> the spec says, There is though an issue here. I'll raise a separate >> thread. >> >> There are also a couple of thoughts I had. >> >> Can we make the CompositeBuilderImpl have just one constructor? >> Should builders be pluggable? >> I've used some of the CompoisteActivator functions in the EndpointWire >> that >> could do with moving into the activator interface. >> >> Simon >> >>
