Jean-Sebastien Delfino wrote:
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>
More thoughts on this, using the store scenario to illustrate the idea:
<composite name="myNetwork">
<component name="storeMainNode">
<implementation.node composite="s:store"/>
<property name="binding.json.uri">http://localhost:8100</property>
<property name="binding.ws.uri">http://localhost:8101</property>
</component>
<component name="catalogsNode">
<implementation.node composite="c:catalog"/>
<property name="binding.ws.uri">http://anotherhost:8234</property>
</component>
</composite>
The above describes "myNetWork":
- containing 2 nodes
- one loaded with the store composite
- the other with the catalog composite
- each node has properties to configure a base URI per binding type (and
possibly other binding configuration too)
Or here's with a different syntax:
<composite name="myNetwork">
<component name="storeMainNode">
<implementation.node composite="s:store">
<service name="NodeService">
<binding.json uri="http://localhost:8100"/>
<binding.ws uri="http://localhost:8101/>
</service>
</component>
<component name="catalogsNode">
<implementation.node composite="c:catalog"/>
<service name="NodeService">
<binding.ws uri="http://anotherhost:8101/>
</service>
</component>
</composite>
which may make it easier to specify default binding configuration per
binding type.
Thoughts?
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
