Simon Laws wrote:
I want to persist/read the domain model to/from disc. At the moment it's
held in memory and there's no way of reading it in or writing it out other
than via the domain API. The model itself is very limited and overlaps the
assembly model so I'm stripping out any repeated info so now would be a good
time to look at formalizing it a little and getting the XML form sorted out.
The limited information we end up with over and above the assembly model is
of the order of...
Domain
DomainURL
Nodes
Node
NodeName
NodeReference -> Callable reference to the node
LifecycleState -> what state is the node in
Contributions
Contribution -> link back to contribution mode
DeployedComposites
Composite -> link to assembly model
Services - a list of service endpoints exposed by the composites
on this node (duplicated back into the assembly model so we could loose
this)
Contributions
Contribution -> link to contribution model
DomainLevelComposite -> link to composite from assembly model
There is some extra info that is held to make processing easier but I want
to review it and see just how necessary it is and dump it if it's not
required.
Way back in September [1] Sebastien suggested we use an SCA assembly to
describe the organisation of the nodes in a domain. As we already use an SCA
assembly to describe the domain I think this would be relatively painless
and we could tidy up the domain components to be a first class
model/serialization of the domain information that we have rather than
coming up with some other XML structure. I note that there is already an
implementation.node. Was this the intention of this extension? If so it
could be a starting point.
Regards
Simon
[1] http://www.mail-archive.com/[email protected]/msg23176.html
That was the intention :) a node would be:
<component name="myNode">
<implementation.node composite="my:composite"/>
</component>
You could also extend the idea to do:
<component name="myNode">
<service name="xyz">
<binding.abc...>
</service>
<implementation.node composite="my:composite"/>
</component>
where the <service> could represent:
- technical services offered to manage the node
- or a description of the business services offered by the composite
loaded into the node (reflected from the composite)
(I'm not sure which way to go, would be good to explore both, but that
was the general idea)
and where my:composite could <include> other composites
(if you decided to load multiple composites into the node).
I'm not convinced that the domain needs to track which contribution has
been loaded into each node, as it can be deducted from the composites.
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
