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
