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)
I thought that Endpoint could just boil down to:
interface Endpoint<B extends Binding> {
B getBinding();
void setBinding(B);
}
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.)
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).
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.
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.
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.
-- Sebastien
