On Thu, Sep 11, 2008 at 6:40 PM, Raymond Feng <[EMAIL PROTECTED]> wrote:
> Hi, > > Here is my understanding how it works by looking at the sample and your > answers. > > 1) A component from composite A is wired to another component from > composite B. The wiring uses binding.sca and @target. > 2) Two nodes will start independently with a deployable composite and > required contributions for A and B. > 3) binding.sca over JMS will start an AcitveMQ broker which enables the > peer discovery > 4) The discovery helps the binding.sca over JMS to find the corresponding > service for the @target uri (componentName/serviceName). > > I take the discovery as a mechanism to enable the binding.sca addressing > with ActiveMQ JMS brokers. And I don't perceive this is a way to form a > dynamic SCA domain. > > a) The discovery-based wire resolving will only help the binding.sca (or > other bindings with discovery capability), not other bindings such as > binding.ws with @target. > b) It doesn't provide a SCA domain manager to manage contributions, > composites and nodes so that 1) can work. > > Thanks, > Raymond > > From: ant elder > Sent: Thursday, September 11, 2008 9:33 AM > To: [email protected] > Subject: Re: A new JMS impl of binding.sca and "dynamic" SCA domains > > > Ok then answers in line but if you articulated your concerns instead of put > them behind questions things might go faster ... > > > On Thu, Sep 11, 2008 at 5:19 PM, Raymond Feng <[EMAIL PROTECTED]> wrote: > > My concerns are behind the questions you trimmed :-). Answers to these > questions will help me understand your approach. I relist the questions > below. > > > 1) What's the result of the discovery? A list of SCA nodes (for example, > node.composite that describes the node configuration)? > > A network of ActiveMQ brokers > > > > 2) Do we have a "manager" that initiate the discovery and maintain the > membership dynamically? > > > No > > > 3) Where are the SCA contributions from? Is this part of the discovery? > > > Something tells the node about them, right now in this initial code that > would be the user at node startup > > > 4) Which part is responsible to manage the SCA contributions and resolve > composites at the domain level? The input to a SCA node is a deployable > composite and a list of SCA contributions (contribution uri + location). > > > > What you've said is just the way the current org.apache.tuscany.sca.node > APIs work, ideally they would be extended to support this approach better > (which is what i was suggesting in the 2nd email in this thread) > > > 5) I cannot find samples/helloworld-distributed. Where is it? > > > > https://svn.apache.org/repos/asf/tuscany/java/sca/samples/helloworld-distributed > > > 6) Can you describe the steps in sequence for this approach? I would like > to > see how the players interact in this dynamic fashion and what information > is > produced from each interaction. > > > Could you try the sample and see if it helps you understand? > > ...ant > FWIW from our past experience in this area we have seen many ways of baking this particular cake. Here are the two main categories that I personally use to describe the approaches. 1. Central domain (where some central manager controls the domain configuration and tells nodes what to do) 1a. A program performs this management function and configures nodes correctly 1b. A human brain performs this management function and the user takes responsibility for configuring nodes correctly 2. Distributed domain (where the domain configuration is distributed across nodes and they chat to each other programmatically to share this configuration) IMHO the domain manager we have in the code falls into 1a, Ant's binding.sca.jms that we have now currently falls into 1b. I say currently as I don't know what else Ant has in mind and we haven't discussed it here yet. We should. Raymond clearly has a different model in mind so it would be interesting to understand that and lets not let this thread stall. As it stands, with some limitations that we could document, binding.sca.jms does provide an easy way of getting a distributed SCA application up and running so it has value. I'd like to use it as the catalyst for us exploring these more dynamic scenarios. More specifically the scenario I have in mind is either a) moving a node or b) starting duplicate nodes. Girorgio's comment was also interesting. One of the important points here is that there are already many many existing solutions for supporting distributed applications and managing resource allocation. If we make sure that our runtime is able to play nicely in the environment in which it finds itself and consider itself part of a domain then we are in a good position to leverage any number of existing technologies, whether that be web app containers, grid style schedulers or p2p fabrics. Simon
