Hi Simon, Thanks for your elaborate answer. It's good to hear that these topics are work in progress!
> This is my view of where we are. > > Service lookup - We are moving to a domain model now that > doesn't rely on service lookup internally. If you take a look > at the workspace code and sample/calculator-distributed as it > now stands the service endpoints in the domain are calculated > in the workspace, i.e. before the individual composites are > deployed and don't need looking up by each of the nodes that > are running composites. It seemed like a simpler solution as > the service lookup piece was causing unwanted complexity. The > workspace code is new so there aren't docs yet. There is the > calculator-distributed sample though and the Tutorial code > gives it a good workout. Ask here if you want to know more > :-) I just tried to get the new calculator-distributed sample working in my eclipse (the old version worked fine). LaunchDomain starts but when I start LaunchCalculatorNodeB I get the following Exception: INFO: Creating node: http://localhost:9990/node-image/NodeB 09.04.2008 18:15:42 org.apache.tuscany.sca.node.launcher.NodeLauncherUtil node SCHWERWIEGEND: SCA Node could not be created java.lang.reflect.InvocationTargetException at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) at java.lang.reflect.Constructor.newInstance(Constructor.java:494) at org.apache.tuscany.sca.node.launcher.NodeLauncherUtil.node(NodeLauncherUtil.java:297) at org.apache.tuscany.sca.node.launcher.NodeLauncher.createNode(NodeLauncher.java:60) at org.apache.tuscany.sca.node.launcher.NodeLauncher.main(NodeLauncher.java:109) at node.LaunchCalculatorNodeB.main(LaunchCalculatorNodeB.java:26) Caused by: org.osoa.sca.ServiceRuntimeException: java.io.FileNotFoundException: http://localhost:9990/node-image/NodeB at org.apache.tuscany.sca.node.impl.NodeImpl.<init>(NodeImpl.java:120) at org.apache.tuscany.sca.node.impl.NodeFactoryImpl.createSCANode(NodeFactoryImpl.java:37) at org.apache.tuscany.sca.implementation.node.launcher.NodeImplementationLauncherBootstrap.<init>(NodeImplementationLauncherBootstrap.java:95) ... 8 more Caused by: java.io.FileNotFoundException: http://localhost:9990/node-image/NodeB at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1172) at java.net.URL.openStream(URL.java:1007) at org.apache.tuscany.sca.node.impl.NodeImpl.<init>(NodeImpl.java:100) ... 10 more Exception in thread "main" org.apache.tuscany.sca.node.launcher.LauncherException: java.lang.reflect.InvocationTargetException at org.apache.tuscany.sca.node.launcher.NodeLauncherUtil.node(NodeLauncherUtil.java:318) at org.apache.tuscany.sca.node.launcher.NodeLauncher.createNode(NodeLauncher.java:60) at org.apache.tuscany.sca.node.launcher.NodeLauncher.main(NodeLauncher.java:109) at node.LaunchCalculatorNodeB.main(LaunchCalculatorNodeB.java:26) Caused by: java.lang.reflect.InvocationTargetException at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) at java.lang.reflect.Constructor.newInstance(Constructor.java:494) at org.apache.tuscany.sca.node.launcher.NodeLauncherUtil.node(NodeLauncherUtil.java:297) ... 3 more Caused by: org.osoa.sca.ServiceRuntimeException: java.io.FileNotFoundException: http://localhost:9990/node-image/NodeB at org.apache.tuscany.sca.node.impl.NodeImpl.<init>(NodeImpl.java:120) at org.apache.tuscany.sca.node.impl.NodeFactoryImpl.createSCANode(NodeFactoryImpl.java:37) at org.apache.tuscany.sca.implementation.node.launcher.NodeImplementationLauncherBootstrap.<init>(NodeImplementationLauncherBootstrap.java:95) ... 8 more Caused by: java.io.FileNotFoundException: http://localhost:9990/node-image/NodeB at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1172) at java.net.URL.openStream(URL.java:1007) at org.apache.tuscany.sca.node.impl.NodeImpl.<init>(NodeImpl.java:100) ... 10 more If I open http://localhost:9990/ui/workspace/ in my browser, I can't see any Contributions, Composites, Clouds or Files. So it's not remarkable that http://localhost:9990/node-image/NodeB cannot be found. Do I first have to configure the workspace by manually uploading contributions ? BTW, I just tried to manually upload a sca.contribution.xml (in Files) and got another Exception: HTTP Status 500 - java.io.IOException: java.io.FileNotFoundException: files\C:\resources\nodeB\META-INF\sca-contribution.xml (Die Syntax für den Dateinamen, Verzeichnisnamen oder die Datenträgerbezeichnung ist falsch) The german error message reads "the syntax for filename, pathname or volume is wrong". So any help or additional documentation would be appreciated. > Load balancing and failover - The default plan for load > balancing is to run composites in a cluster. I got close to > having a simple sample running on my own machine in a Tomcat > cluster with the old domain approach. I haven't converted > this over to the new workspace yet but here is how I expect > it to work. > > - The details of the head of the cluster are provided to the > workspace as a node to which composites can be deployed > - This configuration causes references targeting services > that will run in the cluster to have their bindings > configured with the URI of the head node of the cluster > - All of the real nodes in the cluster request the same > composite from the workspace and hence start the same > services but of course on different physical addresses > - Service requests are dispatched to the head node of the > cluster based on the configuration provided by the workspace > - The head node sprays out requests to the cluster as appropriate. > > This should (!) work for stateless service but I haven't > actually tried it yet. Stateful services, e.g. conversations > or services with COMPOSITE scope are a little more > problematic as the problem of affinity and fail over comes > up. To make fail over work in the stateful case we will have > to provide persistance of the conversation state etc. This is > still not there yet Sounds good so far. Load balancing and especially failover are crucial for our EILF project so we are looking foreward that Tuscany will provide solutions for those topics. The majority of services we employ will be stateless. But several may need to be stateful, so this will get an issue sooner or later. At the moment I can only offer to take part in discussions about those topics and test your implementations (like I did with my various Conversational examples). Thanks. Bye, Daniel --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
