On Dec 20, 2007 10:07 AM, Venkata Krishnan <[EMAIL PROTECTED]> wrote:
> Hi, > > I think using 'binding' is a bit confusing. So am changing over to > 'bindingConf'... so here is the changed xml... > > <composite name="myNetwork"> > <component name="storeMainNode"> > <implementation.node composite="s:store"/> > <property name="DefaultConfiguration"> > <bindingConf> > <name>json</name> > <uri>http://localhost:8100</uri> <http://localhost:8100/> > <someOtherAttribute>..... </someOtherAttribute> > </bindingConf> > <bindingConf> > <name>ws</name> > <uri>http://anotherhost:8101</uri> <http://localhost:8100/> > <someOtherAttribute>..... </someOtherAttribute> > </bindingConf> > <someOtherConfigs/> > </property> > </component> > > .. for this I'd assume we have a property of the following java type... > > public class DefaultNodeConfigurations { > Binding[] bindingConf; > SomeOtherConfig[] someOtherConfigs; > } > > public class Binding { > //encapsulates all attributes we want in a binding configuration. > //not sure if we may just about be able to use the one in the assembly > model. > } > > That will be a single class encapsulating various configuration > information. If you'd want to model each type of configuration as a class > for example DefaultBindingConfigurations, then that is also an > alternative. > > Does this answer you question, atleast remotely ;-) ? > > - Venkat > > On Dec 20, 2007 2:56 PM, Simon Laws <[EMAIL PROTECTED]> wrote: > > > 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 > > > Thanks for that Venkat, brings a bit of clarity. Would you want to put all the properties under one? I was thinking of... <composite name="myNetwork"> <component name="storeMainNode"> <implementation.node composite="s:store" /> <property name="URI"/> http://localhost:8080/nodeA </porperty> <property name="BindingConfiguration"> <bindingConf> <name>json</name> <uri>http://localhost:8100</uri> <http://localhost:8100/> <someOtherAttribute>..... </someOtherAttribute> </bindingConf> <bindingConf> <name>ws</name> <uri>http://anotherhost:8101</uri> <http://localhost:8100/> <someOtherAttribute>..... </someOtherAttribute> </bindingConf> </property> <property name="SomeOtherConfiguration"> <someOtherConfigs/> </property> </component> Simon
