hi Jeremy, has somebody captured the current version of the logical model in UML.
thanks, Michael On 3/22/06, Jeremy Boynes <[EMAIL PROTECTED]> wrote: > > 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 >
