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
>
