On Fri, Sep 12, 2008 at 11:27 AM, Simon Laws <[EMAIL PROTECTED]>wrote:
> > > 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 > That sounds about right to me. The current dynamic impl might be mostly 1b. right now but i think we can make it also do more of 2. as this progresses. Agree with that last point, it would be really good for Tuscany to be able to work with those types of existing technologies, this ActiveMQ based approach is just one of the ways as it was easy to get something going with our existing JMS binding, the overlayweaver project Giorgio mentioned sounds interesting - its Distributed HashTable support seems like it could work quite well with the dynamic Endpoint function we already have code for in Tuscany. Anyway from all that I think its now worth continuing to explore this and doing some of the things suggested in that 2nd email in this thread. ...ant
