Hi,

Yes, thats an option too.. a better one infact (just refrained from
mentioning it to avoid cluttering and confusing ;-) ).

Thanks

- Venkat

On Dec 20, 2007 4:07 PM, Simon Laws <[EMAIL PROTECTED]> wrote:

> 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
>

Reply via email to