On Dec 20, 2007 6:05 AM, Venkata Krishnan <[EMAIL PROTECTED]> wrote: > I too feel using property is better than using service. Using a complex > property, does this seem sane... > > <composite name="myNetwork"> > <component name="storeMainNode"> > <implementation.node composite="s:store"/> > <property name="DefaultConfiguration"> > <binding> > <name>json</name> > <uri>http://localhost:8100</uri> <http://localhost:8100/> > <someOtherAttribute>..... </someOtherAttribute> > </binding> > <binding> > <name>ws</name> > <uri>http://anotherhost:8101</uri> <http://localhost:8100/> > <someOtherAttribute>..... </someOtherAttribute> > </binding> > <someOtherConfigs/> > </property> > </component> > > Thanks > - Venkat > > > On Dec 20, 2007 6:21 AM, Simon Laws <[EMAIL PROTECTED]> wrote: > > > 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 > > > Hi Venkat
Looks better to me but is this operable? Given that this is within a component of type implementation.node we need to make these properties available in the resulting component and also available to the binding infrastructure. Or at least available to the domain so that it can take the default info and apply it to the bindings. Forgive my ignorance of this but what type of "Object" would be placed in the model as a result of properties like this? Simon
