Jeremy Boynes 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
The logical model is actually pretty close to the model generated from
the XMLSchema. If you take the model generated from the schema and add a
few derived /calculated relationships and derived attributes you get a
reasonable logical model for the runtime configuration.
We had this for some time - and contrary to what you're saying here
Jeremy - it worked. The issue at the time (and it's still an issue now
but Frank is working on fixing that) was that the generated model had
dependencies on EMF and some of the EMF aspects were shining through the
model. This made using this model and in particular writing test cases
difficult for people without EMF expertise. To workaround this problem
and shield people in the group from the EMFness of the generated model,
we created two separate hierarchies, a POJO based model (with no
dependencies on EMF or SDO), and a generated model (and obviously we had
to write the code to transform one into the other).
When we get from Frank a code generator that generates EMF-less model
classes then I think we'll be able to get back to what we had a few
weeks ago, which again worked...
- a generated model - always in line with the schema, without the burden
of writing, debugging and maintaining the parsing code
- derived logical relationships and attributes (when necessary) in
subclasses
- but this logical model will be a POJO model similar to what we have
now without any EMF dependencies.
When we get there, most component implementation types and binding types
should actually be able to work with just the generated model classes,
without writing any code at all (no loader, no parser).
I'll reiterate what I said before, I think that the right strategy here
is to use our databinding technology, and through that exercise help
make it better.
--
Jean-Sebastien
