FYI: I have refactored the builder implementation classes into
"tuscany-builder" module under [1]. The builder interfaces are left in
"assembly" module for now.
[1] http://svn.apache.org/viewvc?rev=819680&view=rev
Thanks,
Raymond
--------------------------------------------------
From: "Simon Laws" <[email protected]>
Sent: Friday, September 25, 2009 2:41 AM
To: <[email protected]>
Subject: Re: [2.x] builder woes
Hi Raymond.
Replies in line...
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?
Ok so I think this breaks down into two pieces then...
1/ Calculation of the structure URI for each reference or service in
the static model
2/ Extend the binding specific builders to take the static uri and
combine it with the binding specific endpoint configuration. The
binding specific build phase comes next. If
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.
In my mind EndpointReferences are runtime artifacts. Endpoints feel
more static as their configuration can be established and is stable
while a composite is assigned to a node. Overall though I'd says this
notion of static and runtime builders is just a convenience for giving
some structure to the build process. It probably doesn't make that
much material difference. It may make a difference in future dynamic
scenarios where we want to be able to build and rebuild
EndpointReferences independently of the static model. However we need
to put all of our domain scenarios back on the table and review them
before we put too much store in that.
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.
A domain manager could be made a available as the model is build but I
agree that it is probably useful to consider these as separate phases.
If only because then we have the endpoint registry populated with
deployed and active endpoints against which endpoint references can be
resolved.
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?
+1
Simon
