Talk:COSMOS DC Design Discussions

Hubert - thanks for these suggestions. I've got some comments/questions below. Let's do a few iterations and then get some of these into bugzilla.

Binding Service: Is the suggestion that we remove the BindingService, or provide a base implementation? The BindingService interface was put into the framework for two purposes. One was to provide a mechanism for allowing component providers to construct, initialize and manage their components using their own extensions to the assembly declarations, and the other was to provide an isolation mechanism for the component classloaders. The fact that the Sample and GLA binding services are so similiar is due to the fact that they don't really do much.

Component Coupling: Completely agree on the batch import. My initial plan was to add support for array types to the wiring code - just never got around to it. As you surmised, the initial implementation was geared for live data collection, not mass imports after the fact.

I think the container should be retained. It gives the framework the capability to multiplex component pipelines and supports a richer composition model for deployment. For cases where the source does a destructive read, you can only support composition scenarios by modifying components, which will reduce reuse.

Wire Method: Yeah - upon reflection (pun intended), it probably would've been better to have the base class discover the wiring methods by introspection. I'd rather not use Object and Object array as type, however, as that means adding complexity to components that support multiple wiring types. Let's see if we can come up with a strongly typed implementation.

Separation of concerne: Can you give some specifics here? I'm not sure I agree about removing all traces of Keyset/DataType from the assembly. They were put there explicitely to allow for linkages back to our SML work (or forward into any SDMX work we may do). I agree that they probably shouldn't show up in the components - that kind of information should be mediated by the binding services. As for WSDM, I think we've already got an enhancement request to support muse-generated management interfaces for components.

Query framework: I think we have this already. It's called the IDataQueryService. The JPA example implemented this for the EJBQL dialect, however our move to iBatis, the demand for those 'convenience' API, and our short timeline for delivering and End 2 End demo meant that adding support for an SQL dialect didn't make it into the iteration. I think adding generic support for SQL and XPath make a ton of sense.

Inbound/Outbound: I think I agree, this distinction could be made at runtime when the assembly is parsed, just by looking at the outer container (source == inbound, query == outbound). The concept (at least at runtime) is valid, as the two types of assemblies may present different control interfaces.

Other Things:More useful sources and sinks: Yes. I'd like to see the GLA source hooked up to live data as well. What impact will that have on your batch update request?

Other Things:User friendly interface:We've got remote clients written (and you can always use MAX). Should we try to get Sheldon to help us make a web-based management app?

Other Things:Doc: Oh yes.