Meeraj,
My comments inline. I thought we were going to continue this discussion
back in the context of the "Componentizing our runtime" thread at
http://www.mail-archive.com/[email protected]/msg15725.html, but
the discussion there has stopped, so I'll respond here.
Meeraj Kunnumpurath wrote:
I can't see how kernel modularization is related to interface based
models. Model is only part of the SPI, SPI also provides a set os
services, which all have well-defined contracts.
Interfaces are important to achieve modularization, define clear and
minimal contracts between modules, minimize dependencies and shield
modules from implementation changes in others. I'm not sure why we're
picking on the models in particular as this design principle applies to
all the modules that present SPIs.
This applies to all SPIs, but one of the benefits of using model
interfaces is the ability to use alternate implementations of these
interfaces and/or combine these interfaces with others. To illustrate
this I am prototyping the following (in my sandbox at the moment):
- The ability for the model to expose different APIs: the base model API
in sca/modules/assembly as well as a different "model builder" API in
sca/modules/builder.
- The ability to have a significantly different implementation of the
model, backed by Spring bean definitions for example. I am starting to
experiment with this in sca/modules/bean and sca/modules/bean-test and
just committed it to my sandbox so that people can take a look.
In both cases, the other modules (SCDL handling for example) don't see a
difference between the default assembly model implementation under
sca/modules/assembly and the variant implementations, they just talk to
the same interfaces.
More generally, I'd like SCA and its assembly model to be consumable in
many different environments, Apache products, J2EE app servers and tool
environments, and become as pervasive as the WSDL model for example.
Clean interfaces not exposing the implementation details and allowing
for alternate implementations will help achieve that goal.
I am not sure what extra benefits we have by supporting different data
binding mechanisms for the model objects. If I remember right, we had
this discussion a long while ago and we decided to go with Java based
model objects.
I'm not sure that there's a great case for alternate implementations of
the model directly backed by XML databinding technologies. A straight
mapping to XML using an XML databinding may not be able to populate the
logical relationships (e.g. ComponentReferences pointing to target
ComponentServices) that you'll expect in a logical assembly model. On
the other hand I think it will be useful to be able to implement the
model using a modeling technology for integration with tooling for
example, or in a form that can be easily backed by a database or some
other form of repository.
I have never found a need to mock model objects in the tests, as the
model objects, as I said earlier, don't have any behaviour. We often
mock, service objects that do have behaviour.
I don't think that a model never implements any behaviour. The current
model in trunk actually already has a little bit of behaviour (for
example to synchronize bi-directional relationships or clone itself). I
spent some time today working with the Spring bean model and they have
some behaviour in their model. If I remember correctly the WSDL model
implements some behaviour to resolve portTypes in imported WSDLs for
example. As we start to implement more of the actual SCDL spec I'm sure
we're going to have to add more behaviour as well, at least to
validate/enforce some integrity constraints in the model.
If this about modularizing SPI, I would say it is an affort worth
discussing. However, the model changes, I can't see any visible
benefit in doing that. Since we have already had discussion on this
during M1 and we decided to go with Java based POJO model classes, I
believe it is water under bridge and can't see the point in bringing
this up again.
This is about modularizing SPIs, using interfaces, and the assembly
model is one of these core SPIs. The discussion we had in M1 was
polarized around using SDO, EMF or POJOs, this is not the point here.
Ta
Meeraj
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
