On Dec 20, 2007 10:19 AM, Simon Laws <[EMAIL PROTECTED]> wrote: > On Dec 20, 2007 10:01 AM, ant elder <[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 > > > > > > > > Could there be a base uri for the node instead of per binding type? > > > > ...ant > > > Good point. We will need some base URI information for the node in order > that the domain can communicate with the node. This information is > provided > to the node on its constructor and the domain is notified by the node of > its > URI. With a completely static configuration this info will have to be > configured/persisted by the domain. Should this replace the binding > default > URIs? > > Node URI does provide the defalt binding URI in the current implementation > for all bindings that use HTTP(S) in as much as the node URI provides > default base URL information to our host environments so all bindings that > use HTTP(S) use the node default. However is there a need for default URIs > outside of HTTP? Or for doing different things for different bindings? If > the answer is yes then we need both node information and binding > information. For example, > > 1. Someone wants a simple configuration where they just want to connect a > node and use the sca binding for in domain communications. The probably > don't want to get into the business of configuring specific bindings but > they must provide node contact details. > > 2. Someone wants to provide very specific configuration details for the > web > service bindings in the domain independently of jsonrpc bindings. Perhaps, > for example, because they want these bindings to operate on different > ports > due to firewall policy issues. In this case we want to be able to > configure > at the binding level. > > Simon >
Here's where I'm coming from: We know we want to use containers like Tomcat and Geronimo for hosting node(s), and in those containers we can't use arbitrary http ports. From reading posts on the user list it seems like running in a webapp might even be the most common way people are using Tuscany, so I think we should make this work as easily and simply as possible. We don't have any way to define binding specific configuration today, we probably do need something but then we'd need that for both distributed domains and for standalone nodes so maybe the way domains are persisted is not the place to put this. One alternative might be to use the sca-definitions file but that would depend on the specific bit of configuration being defined. Anyway, those two seem like different requirements to me and think it would be clearer to separate them for now. ...ant
