Hi
So apart from these minor comments you like it;-) I think you are several
chapters ahead of me here. This Endpoint model is my first effort at
addressing some of the issues at hand and adding some function over the top
of the model we already have without breaking the existing model. Now I know
a little more it's clear that we need to review the way that bindings are
used and, in particular, the way that they drive wire creation. For me
personally this was too big a piece to bite off in the first instance.
Hopefully we can iterate to something that satisfies both of us. I've put
some comments in line.
Simon
On Tue, Jun 10, 2008 at 7:00 PM, Jean-Sebastien Delfino <[EMAIL PROTECTED]>
wrote:
> Simon Laws wrote:
> ...
>
>> I've created an itest (late-reference-resolution) to show how late
>>>
>>>> resolution could be done using endpoint resolvers.
>>>>
>>> ...
>
> I've spent some time looking at that test and the following classes:
> Endpoint
> EndpointFactory
> Endpoint
> EndpointResolver
> EndpointResolverFactory
> EndpointResolverFactoryExtensionPoint
> EndpointWireImpl
>
> I'd like to suggest the following alternate design:
>
> A) Endpoint has two many relationships with other model objects IMO, and
> when I put it in a UML diagram I noticed that it duplicates a number of
> existing model relationships and mixes real attributes and setter accessors
> for derived attributes or relationships:
> getCandidateBindings()
> getSourceBinding()
> getSourceCallbackBinding()
> getSourceComponent()
> getSourceComponentReference()
> getTargetBinding()
> getTargetComponent()
> getTargetComponentService()
> getTargetName()
> setSourceBinding(Binding)
> setSourceCallbackBinding(Binding)
> setSourceComponent(Component)
> setSourceComponentReference(ComponentReference)
> setTargetBinding(Binding)
> setTargetComponent(Component)
> setTargetComponentService(ComponentService)
> setTargetName(String)
That may be true. I wasn't heading for model perfection I was aiming for
something that worked and that allowed me to better understand the model as
it stands today without breaking it. I added the things to Endpont that I
needed given the model and processing as it stands with a view to removing
any that weren't as we polish the model further.
>
> I thought that Endpoint could just boil down to:
> interface Endpoint<B extends Binding> {
> B getBinding();
> void setBinding(B);
> }
I think we are talking about different things. This strikes me as a resolved
endpoint in that you already know what the binding is going to be. I am
concerned about representing an unresolved target so that it can be resolved
at a later date. Maybe I chose the wrong term when I called it Endpoint and
I'm confusing you. Should we have a Target model instead?
>
> with a Endpoint (0..n) --> (1) Binding relationship. No big invention here
> that looks like a WSDL endpoint.
>
> B) I think that Endpoints are specific to protocols/middleware/binding
> types. They all have a URI plus additional derived binding-specific fields.
> The normal extension mechanism that we use to handle Binding extensions
> should apply to Endpoints here too (allowing you to provide a specific
> Endpoint implementation extension for WebService, EJB, JMS etc.)
>
I think that the way that you resolve endpoints may be specific to a
particular binding type and that the concept of a resolved endpoint is
specific to a binding type. I don't agree that the Endpoint model itself has
to be specific to a binding. However I think your mental model of an
endpoint includes some binding specific data that maybe the binding provider
could use for configuration. So I guess we are thinking about different
parts of the problem. Hopefully we can bring them together!
>
> C) I was envisioning ReferenceEndpointProvider and ServiceEndpointProvider
> interfaces, mirrored on the current ReferenceBindingProvider and
> ServiceBindingProvider but working with Endpoints instead, giving you the
> ability to handle invocations in an endpoint specific way, on an endpoint
> basis (allowing you to manage connection pools for example, which we can't
> really do at the moment with the Binding based design).
So was I but Raymond didn't like that (see previous thread) so I changed it.
Again I wasn't considering that an endpoint would be involved during
invocation which I think is what you are suggesting.
>
> D) Resolution of the address of a target could be done when initializing
> /resolving the Endpoint model, at EndpointProvider.start() time, or at
> invocation time. When done at model initialization/resolution time, the
> outcome of the resolution would be visible in the domain assembly model,
> providing useful feedback to the domain administrator.
>
Agreed. This is the flexibility I have added.
> E) The late-reference-resolution itest uses a static global to implement
> its dynamic lookup. I think that shows that the current EndpointResolver SPI
> does not give it enough context to do that kind of resolution. I think that
> the Endpoint model should be able to obtain a pointer to the top level
> domain composite for example. It would be easy to do if it used the
> ArtifactProcessor mechanism that we're already using for other model
> objects, you could just use the ModelResolver passed to
> ArtifactProcessor.resolve() to get it for example.
>
It's just a test! The EnpointResolver is free to use whatever mechanism it
likes in order to resolve a target name to a target service. This is likely
to involve some remote call to a registry somewhere that is holding this
information. If the local model of the domain already knew the answer then
late binding processing would not be required. I wrote a test registry with
a global static just so that I didn't have to extend the domain manager with
a query to do target lookup functions. I haven't got to that yet.
> F) Finally I think it is important to allow a model populated with resolved
> Endpoints to be saved into a correct composite expressing the same
> information with <binding> elements. That's important IMO to be able to
> communicate the resolved composite using a standard SCA form without
> inventing a new non-standard dialect for this.
This currently works because resolved endpoints are turned back into
bindings on the reference. As I said, this first foray into Endpoint
modeling was specifically intended leave the rest of the model and
associated processing intact.
>
> -- Sebastien
>
