tuscany-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dishara Wijewardana <ddwijeward...@gmail.com>
Subject Re: GSoC 2012 Idea : TUSCANY-4023
Date Thu, 22 Mar 2012 16:30:27 GMT
Hi Raymond,

I think I have a better overview of the project better than last week ;) .

I looked in to Zookeeper wiki and also wet through the Zookeeper getting
started guide with the Zookeeper client CLI.
It will be great if I can get to know / a guidance which will be useful to
do beforehand (more in technical perspective, i.e any particular classes to
look at (I already checked out Tuscany sca java trunk)) in depth which may
directly helps for a core development part of this project. And it will
lead me to get a good start for this project and helped me to do a good
contribution for this project and continue the contribution further.

Thanks


On Thu, Mar 15, 2012 at 1:37 AM, Dishara Wijewardana <
ddwijewardana@gmail.com> wrote:

>
>
> On Wed, Mar 14, 2012 at 8:56 PM, Raymond Feng <cyberfeng@gmail.com> wrote:
>
>> Hi, Dishara.
>>
>> It's glad to see you did some homework :-).
>>
>
> Thanks Raymond, :D
>
>
>>
>> The scope is the project is to use Apache ZooKeeper to publish and
>> receive descriptions of service endpoints, such as the component URI, the
>> binding type, associated policies and the endpoint address. For example, we
>> run two components (Component A & B) on two hosts (Host A and B), Component
>> A has a reference to Component B. When Tuscany starts on Host A, we publish
>> the information about component A to the ZooKeeper and receive the
>> description of Component B. The endpoint description of Component B will be
>> used by Host A to resolve the "target" (the logical SCA address) of an SCA
>> reference.  ZooKeeper also maintains the group of Tuscany nodes in the same
>> domain. It keeps the consistent state about all the participating SCA
>> components. In a simplified view, we can treat ZooKeeper as a distributed
>> map.
>>
>
> Thanks for the detailed explanation. I will keep looking around and make
> myself more clear about this and will raise questions on dev list when met.
>
>
>
>>
>> Thanks,
>> Raymond
>>
>> On Mar 13, 2012, at 12:21 PM, Dishara Wijewardana wrote:
>>
>> Hi Raymond,
>>
>> On Mon, Mar 12, 2012 at 10:03 PM, Raymond Feng <cyberfeng@gmail.com>wrote:
>>
>>> Hi, Dishara.
>>>
>>> Thank you for the interest. I'll elaborate more on the idea.
>>
>>
>> Thank you very much for the detailed description.
>>
>> I went through the tuscany distributed runtime wiki once and got an
>> understanding(may be have to go through again ;) ). Seems it got a good
>> architecture to distribute the existing domain registry.
>>
>>
>>>
>>> There is a SCA domain concept in Tuscany, which is a service registry of
>>> metadata about all the components and policies. A composite application can
>>> have components running on different machines and they can be wired to each
>>> other using remote bindings within the SCA domain. From the runtime
>>> perspective, Tuscany uses the domain registry to resolve the wirings
>>> between components.
>>>
>>> Tuscany has two types of implementation of the domain registry at this
>>> point:
>>>
>>> 1) Local registry (which only knows the local endpoints). It can be
>>> extended to use local files to describe remote endpoints in the node.xml.
>>> 2) Multicast based registry on top of Tomcat Tribes or Hazelcast.
>>>
>>>
>>  So we probably not going to use either any of above two domain registry
>> implementations, but the centralized registry. (which I assumed as another
>> registry impl).
>>
>>
>>> In a typical enterprise environment, the multicast doesn't work well due
>>> to networking constraints. A more useful infrastructure is that we have
>>> centralized registry with HA configurations (such as master/slave). Apache
>>> ZooKeeper and Redis can be used for these purposes. The project will  be
>>> mostly implement the DomainRegistry SPI [2].
>>>
>>>
>> As far as I understand, we'll be using a suitable domain registry
>> implementation to distribute among ZooKeeper nodes. And as the wiki stands,
>> Tuscany will not go for JVM clustering, but a higher level clustering
>> solution.
>>
>> This project will have following main targets.
>> - Identify/implement how nodes (in the distributed environment) should be
>> modeled to form a SCA component.
>> - Integrate the nodes to meet the above requirement through a distributed
>> platform (ZooKeeper).
>>  (And integration of nodes should be done by tuscany SCA bindings on top
>> of Apache ZooKeeper nodes)
>>  At the end of the day this will create a bridge between ZooKeeper nodes
>> and SCA components.
>>
>> Also  +1 for Apache ZooKeeper.
>>
>> Please correct me if I have misunderstood the requirement or any feedback
>> will be great full. This is a really interesting project.
>> But I am not quite aware of the scope of this exactly in details .
>>
>>
>>> [1] https://cwiki.apache.org/TUSCANYWIKI/distributed-runtime.html
>>> [2]
>>> https://svn.apache.org/repos/asf/tuscany/sca-java-2.x/trunk/modules/core-spi/src/main/java/org/apache/tuscany/sca/runtime/DomainRegistry.java
>>>
>>> Thanks,
>>> Raymond
>>>
>>> On Mar 11, 2012, at 10:13 AM, Dishara Wijewardana wrote:
>>>
>>> > Hi all,
>>> > This is regarding the project idea "Develop a distributed domain
>>> registry using Apache ZooKeeper, Redis, or Memcache".
>>> >
>>> > I am interested in applying for this SoC program and I saw the JIRA[1]
>>> project idea for Apache Tuscany. I have played with Tuscany and already
>>> > had hands on experience with creating Tuscany SCA components in
>>> webapps and using the callback method and etc (the framework is very helpful
>>> > when communicating between front end and back end).
>>> >
>>> > I would like to work on the project "Develop a distributed domain
>>> registry using Apache ZooKeeper, Redis, or Memcache" .
>>> > These days I started looking in to Apache ZooKeeper and get familiar
>>> with it.
>>> >
>>> > It will be nice if I can get to know some details(what is the expected
>>> scope, what things need to be looked before hand, and etc) of this project
>>> idea, so that I can prepare well for the project.
>>> >
>>> >
>>> > Thanks
>>> > /Dishara
>>>
>>>
>> Thanks
>> /Dishara
>>
>>
>>
>
>
> --
> Thanks
> /Dishara
>
>


-- 
Thanks
/Dishara

Mime
View raw message