See my comments inline.
Thanks,
Raymond
--------------------------------------------------
From: "Simon Laws" <[email protected]>
Sent: Wednesday, September 23, 2009 8:44 AM
To: <[email protected]>
Subject: Re: [2.x] builder woes
There is one more static builder: PolicyAttachmentBuilder. This builder will
apply the @attachTo xpath of the policySets to the domain composite as well
as the composites used by implementation.composite. It should be called
right after the include/clone is finished on the domain composite.
Thoughts on the runtime part of the build which involves...
bindingURIBuilder
I think this can stay as is as it's fairly isolated
Is BindingURIBuilder calculating the structural URIs? This could be merged
into the builder that set the component URI. We can name the builder
something like StructuralURIBuilder. If the @uri of a binding is not set,
the binding extension may choose to derive the protocol URI from the
structural URI. Where should this kind of behavior be plugged in? In the
component service/reference binding builder?
componentServiceBindingBuilder
componentReferenceBindingBuilder
binding specific builders. I think they have to come after the
service binding URIs have been calculated. Not clear to me that
service and reference need to remain separate. In the previous
builders the componentReferenceBindingBuilder was called at the end
after endpoint references were created. In OASIS though the reference
either has a binding, in which case it has been manually configured,
or it adopts the binding from the service, which will have already
been configured by the service.
I am tempted to combine these two and the bindingURIBuilder into a
single bindingBuilder.
At this moment, the component service/reference binding builders just call
the BindingBuidler extensions. +1 to merge them. I'm also wondering if these
builders should work against the Endpoint/EndpointReference instead of
(Component/Contract/Binding tuples). If so, should we align them against the
EndpointReference/EndpointBuilder? It's related to the decision on whether
we treat Endpoint/EndpointReference as runtime model or static model.
endpointBuilder
fairly isolated again
endpointReferenceBuilder
this is interesting as there is another endpointReferenceBuilder in
the endpoint module. There are two things going on.
1/ creation of endpoint references based on the local composite
configuration
2/ resolution/matching of cross composite endpoint references in
the distributed case.
The first builder does step 1 and the second builder does step 2. I
would like to at least combine the code into one file and just call
the separate phases from different places.
I'd also like to do the runtime matching for those endpoints
resolved in step 1 so that all local composite errors are reported are
load time
There is some rationalization we could do here by relying on the
endpoint registry as the registry of available endpoints when endpoint
references are actually created. The problem I have with this though
is that endpoints are not added to the registry until the composite is
activated and to populate it earlier would detract from this. So I'll
leave this alone for now.
Should we limit the builder responsibility to configuration only? The
resolution seems to be in a different phase than build.
In use cases like the SCA Domain Manager that provisions the composite
applications, no EndpointRegistry is available.
componentReferencePromotionBuilder
This currently deals in endpoint references and hence has to go
here. However it's really a static model building phase so I'd like to
rephrase this logic in terms of reference targets and bindings and
move it into the componentype/componentConfig build process.
compositePolicyBuilder
This also currently deals in endpoints and endpoint references but
is really static model configuration. So need to discuss if this could
be moved back up to the static phase. I don't have a problem if it
needs to stay here for whatever reason.
Maybe we can use a criteria as follows to determine if the static model
needs to be updated or the information goes only to the runtime model:
* Is the information useful for deployment/provisioning without running the
composite application?
I think all of these runtime builders could live outside of assembly
and be called in a separate group by the node to allow for this move.
This overlaps with Raymond's discussion about where the builders
should be more generally.
Simon
