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

Reply via email to