Frank Budinsky wrote: > Now back to the issue of whether or not to use SDO for the SCDL model. > Personally, I think that the main issue Jeremy is bringing up is that the > way SDO is currently being used for a Java binding of the physical model, > which then needs to be transformed into a different logical model, really > makes one question its value. You need to write similar code to create the > logical model, whether it's by reading from StAX or from the generated > physical model API. The generated API is a little nicer, but hardly enough > to warrant the added layer/complexity. I think I agree with that. > > But, if I step back, I really question the need for two models in the > first place. If I understand the history of this, the goal was to have a > logical model to hide the physical model, and specifically, the EMF > complexity it contained. If that's true, and given my comments above about > the EMF-less code that we're planning to generate, I would think that the > right end goal is to unifying the logical model with the generated model, > instead of eliminating it and writing all the model building code by hand. > > I think that we really should use the Tuscany code generator. It is > important that it be a competitive Java binding technology (as good or > better then JAXB, etc.), so what better way to make that happen then to > use it ourselves. The SDO spec is pretty vague on what an SDO generator > actually generates (other than the fact that the interfaces are > bean-like), so we have a lot of opportunity to provide options, etc., to > make it do exactly what we want. > > That's my admittedly biased 2 cents worth :-) >
I would say that the goal for the logical model was to have a view of the configuration information that was easy to work with programatically. To support testing we wanted to be able to construct models easily that could be used to boot component containers. Although we would use that to test the containers themselves, the main goal was to allow users to test the logic in their components when some container interaction was required. With that in mind, I am not sure that any simple XML->Java binding approach is the right way to go. What we found before was that led to a model that mirrored the XML structure rather than the "logical" structure of the configuration. That is where the SDO/EMF issues crept in. To provide the model we wanted we needed to mix functionality into the generated code. This was hard to maintain so we attempted to factor it out into subclasses; that didn't really work which is why we ended up with a separate physical model. I think SDO/EMF is a perception victim here - I think we would have had the same issues with XMLBeans, JAXB or any other binding framework. If SDO could de-serialize directly into our logical model then that would be a simple option to use. However, if the price we need to pay to achieve that is a heavily annotated XML schema or a custom code generator I think we are back to where we are now. Finally, I want to be clear I don't think this is an SDO problem, I think it is an issue we have because the model does not map directly to XML and that we would have this problem with any technology - I have certainly seen the same issue in projects that used XMLBeans and Castor. We could enhance SDO to handle this mapping better (e.g. through a more sophisticated code generator). I think we would be better served though to direct that energy into improving the SDO-centric features of our implementation rather than doing something special for Tuscany's loading problem. One alternative we have is to make the logical model directly map to the XML. At one point we were there, but we moved away from that to simplify testing. I think that is the right strategic choice as it makes testing easier for our users - the price we pay for their convenience is a more complex configuration loader. -- Jeremy
