Jean-Sebastien Delfino wrote:
[snip]
Jean-Sebastien Delfino wrote:
Venkata Krishnan wrote:
Hi Sebastien,
I agree with your suggestions on two accounts...
- its really good to have the model defined around interfaces as it
gives
the flexibility to improve / modify the implementations we choose
over a
period of time without the impacting the core which I assume will
use only
these interfaces. If we use factories to instantiate model objects
(i.e.
specific implementations of these interfaces) that will keep the
core futher
away from impacts of changes to implementation of the SPI model. We
could
probably configure the factory class to be used as part of the scdl
- for
example as the property of a Loader(s). Hope I am making sense?
Yes, making a lot of sense to me...
I've created an AssemblyFactory interface. Hope it will help decouple
the various modules. I'll try what you're proposing to pass the factory
to the loaders once I manage to get past the circular dependencies with
Deployer that I mentioned in
http://mail-archives.apache.org/mod_mbox/ws-tuscany-dev/200703.mbox/[EMAIL PROTECTED]
(and are preventing me to build the loaders at the moment). If anybody
has any ideas on how to best refactor this to avoid circular
dependencies, let's talk about it.
- Specific to the case of references, I did imagine that we may have to
clearly abstract out references at componentType level, component
level and
composite level as there is something specific in 'references' to
each level
- for example the 'promote' is something that is specific to the
composite
level.
Yes, there's a 4th level in constrainingType, which is the most
abstract and does not have a binding or policySets, but I guess we
can go step by step so I'm not sure we need it yet... I'll leave it
up to you.
I have started to make some changes in the SPI model of the kernel.
But
then, it is not going to be difficult for me to migrate this to your
proposed design in the 'assembly'. So I shall continue for now in the
kernel unless you see some issues.
Good, we'll see if we have the same reading of the spec :). What I
posted below was just an initial idea so let me know when you have a
code update on your side and we'll see how we can exchange ideas and
sync up our interfaces / classes.
Thanks.
- Venkat
The same scheme works for Services as well, so I've added similar
Service interfaces + a Wire interface. I'm thinking that all the
policy related stuff will end up in a separate module but for now I've
created placeholders for policy attachments in o.a.t.policy.model.
I'll double check with the spec to see if the same scheme applies to
Properties as well.
I've added Properties and also interfaces for Component, ComponentType
and ConstrainingType referencing the interfaces above.
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
