On Dec 19, 2007 11:49 PM, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
> 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] > > +1 I think this will fit in well and provide a mechanism for static configuration, and subsequent persistence, of the domain configuration. I appreciate the point about allowing for more comprehensive configuration of bindings over and above the base URI. However the use of the <service> element for this purpose could lead to confusion. I'm not that familiar with how complex properties work but could we, in some way, combine the two and have. <composite name="myNetwork"> <component name="storeMainNode"> <implementation.node composite="s:store"/> <property name="bindingDefaults"> <binding.json uri="http://localhost:8100"/> </property> </component> ... Simon
