2008/9/12 ant elder <[EMAIL PROTECTED]>: > > > 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 > > Its time for me to have a more clear picture before starting coding a new binding o something else. I have DHT table just done by the support (aka overlay weaver) and from the same support I have a Application Level Multicast ready. My idea was to put in DHT the endpoint and distributing the current central domain manager support. Each node joins the DHT from a bootstrap node, exposes its composite in the DHT and fireup its components. Are there any pitfalls o problems in doing this? Is that what the point 2 says? I know that part of this work it was already done for supporting distributed domain, but please forgive..i don't remember where to look again and a lot of code is changed from the last time.
-- "I wish I were the first star that you see to shine every night 'cause so you're eyes know that I look at you and that I'm always with you..".. from Favola - Moda.
