Re: GSoC 2012 Idea : TUSCANY-4023
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 < ddwijeward...@gmail.com> wrote: > > > On Wed, Mar 14, 2012 at 8:56 PM, Raymond Feng 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 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
Re: GSoC 2012 Idea : TUSCANY-4023
On Wed, Mar 14, 2012 at 8:56 PM, Raymond Feng 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 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, a
Re: GSoC 2012 Idea : TUSCANY-4023
Hi, Dishara. It's glad to see you did some homework :-). 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, 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 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
Re: GSoC 2012 Idea : TUSCANY-4023
Hi Raymond, On Mon, Mar 12, 2012 at 10:03 PM, Raymond Feng 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
Re: GSoC 2012 Idea : TUSCANY-4023
Hi, Dishara. Thank you for the interest. I'll elaborate more on the idea. 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. 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]. [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
GSoC 2012 Idea : TUSCANY-4023
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
Re: GSoC 2012
Great, I'll draft a few ideas. Thanks, Raymond On Mar 4, 2012, at 9:42 PM, Luciano Resende wrote: > It's that time again for us to build a list of project ideas and start > attracting students for GSoC. If you have specific ideas, please go > ahead and create a JIRA with the appropriate tag. > > > -- Forwarded message -- > From: Ulrich Stärk > Date: Sun, Mar 4, 2012 at 9:01 AM > Subject: Google Summer of Code 2012 upcoming > To: p...@apache.org > Cc: d...@community.apache.org > > > Hello PMCs, > > Google Summer of Code is the ideal opportunity for you to attract new > contributors to your projects. > > If you want to participate with your project you NOW need to > > - understand what it means to be a mentor [1] > - propose your project ideas. Just label your issues with gsoc2012 in JIRA and > they will show up at [2]. See also [1]. > - subscribe to code-awa...@apache.org (restricted to potential > mentors, meant to be used > as a private list - general discussions on the public > d...@community.apache.org list as much as possible please) > > The ASF will apply as a participating organization with GSoC, your project > doesn't need to do that. See [3] for more information. Note that the ASF isn't > accepted yet, nevertheless you *really* should start recording your ideas now. > > Last year we had 38 students completing GSoC successfully, some of which are > now active contributors to the projects they worked on. Let's make this a > success again this year! > > On behalf of the GSoC 2012 admins, > > Uli > > [1] http://community.apache.org/guide-to-being-a-mentor.html > [2] http://s.apache.org/gsoc2012tasks > [3] http://community.apache.org/gsoc.html > > > -- > Luciano Resende > http://people.apache.org/~lresende > http://twitter.com/lresende1975 > http://lresende.blogspot.com/
GSoC 2012
It's that time again for us to build a list of project ideas and start attracting students for GSoC. If you have specific ideas, please go ahead and create a JIRA with the appropriate tag. -- Forwarded message -- From: Ulrich Stärk Date: Sun, Mar 4, 2012 at 9:01 AM Subject: Google Summer of Code 2012 upcoming To: p...@apache.org Cc: d...@community.apache.org Hello PMCs, Google Summer of Code is the ideal opportunity for you to attract new contributors to your projects. If you want to participate with your project you NOW need to - understand what it means to be a mentor [1] - propose your project ideas. Just label your issues with gsoc2012 in JIRA and they will show up at [2]. See also [1]. - subscribe to code-awa...@apache.org (restricted to potential mentors, meant to be used as a private list - general discussions on the public d...@community.apache.org list as much as possible please) The ASF will apply as a participating organization with GSoC, your project doesn't need to do that. See [3] for more information. Note that the ASF isn't accepted yet, nevertheless you *really* should start recording your ideas now. Last year we had 38 students completing GSoC successfully, some of which are now active contributors to the projects they worked on. Let's make this a success again this year! On behalf of the GSoC 2012 admins, Uli [1] http://community.apache.org/guide-to-being-a-mentor.html [2] http://s.apache.org/gsoc2012tasks [3] http://community.apache.org/gsoc.html -- Luciano Resende http://people.apache.org/~lresende http://twitter.com/lresende1975 http://lresende.blogspot.com/
