On Dec 20, 2007 11:17 AM, ant elder <[EMAIL PROTECTED]> wrote: > 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.
+1 > > > We don't have any way to define binding specific configuration today, we We don't way of defining binding configuration on a node by node basis. We could call on domain.xml at the domain level but that doesn't help with base urls. What I was trying to say in my previous post was that the Node URI should provide the bare URL for all bindings that are able to use it as it does now. If we need specific configuration for a binding then that would be an added extra and would override the Node configuration. > > 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 I think of a standalone node as a simple domain with only one node so I was thinking that we would like to support simple configuration/persistence in a similar way for both.I.e if you don't define a node as being connected to a domain then it should be possible to configure it from file and persist that configuration in terms of it's default URI and the contribution/composite it will run. The configuration would be limited compared to that of the domain. Just my view of course. > > 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 Simon
