[infinispan-dev] Cloud-TM & Infinispan

Adrian Cole ferncam1 at gmail.com
Sun Oct 3 16:46:40 EDT 2010


Great stuff, Paolo.  I tend to follow this moving forward.  It sounds like
you'll need compute cloud provisioning to handle constructing and changing
the topology for scale reasons or otherwise.  Moreover, you mentioned
geography, something we've been investigating.  Have a look at the below,
and feel free to ping us for help as you move this forward.

http://code.google.com/p/jclouds/wiki/ComputeGuide

Cheers,
-Adrian
founder jclouds

On Sun, Oct 3, 2010 at 7:18 PM, Paolo Romano <romanop at gsd.inesc-id.pt>wrote:

> Hi all,
>
> I am new here, so let me first introduce myself. I am Paolo Romano, a
> researcher working at INESC-ID Lisbon, you can find more about me and my
> research activities at my webpage: http://www.gsd.inesc-id.pt/~romanop<http://www.gsd.inesc-id.pt/%7Eromanop>
> .
>
> I am posting to this mailing list to introduce the Cloud-TM project
> (http://www.cloudtm.eu), a EU funded project started in June which
> brings together Red Hat, INESC-ID Lisbon (http://www.gsd.inesc-id.pt),
> Rome University "La Sapienza" (http://www.dis.uniroma1.it/~hpdcs<http://www.dis.uniroma1.it/%7Ehpdcs>)
> and
> Algorithmica (http://www.algorithmica.it).
>
> Citing the project's abstract:
> "Cloud-TM aims at defining a novel programming paradigm to facilitate
> the development and administration of cloud applications. It will
> develop a Self-Optimizing Distributed Transactional Memory middleware
> that will spare programmers from the burden of coding for distribution,
> persistence and fault-tolerance, letting them focus on delivering
> differentiating business value. Further, the Cloud-TM platform aims at
> minimizing the operational costs of cloud applications, pursuing optimal
> efficiency via autonomic resource provisioning and pervasive self-tuning
> schemes."
>
> Infinispan is expected to play a key role in Cloud-TM, as it has been
> chosen as the reference platform to integrate the main research results
> achieved during the project.  Specifically, our plan is to extend
> Infinispan along the following main directions:
> 1. Build a library of alternative replication mechanisms optimized for
> different workload scenarios (e.g. hi/low conflict rate, read/write
> intensive) and scales of the platform (e.g. few/many nodes,
> local/geographical distribution)
> 2. Developing self-scaling mechanisms aimed at elastically allocating
> nodes from Cloud computing platforms to Infinispan caches depending on
> the current workload.
> 3. Developing self-tuning mechanisms that will adaptively alter the data
> replication and distribution algorithms depending on the current
> workload characteristics and scale of the platform.
> 4. Providing programmers with a Distributed Software Transactional
> Memory interface via a wrapper over Infinispan. This wrapper would be
> close  in spirit to what  PojoCache is for TreeCache, though we are
> currently oriented towards using a Domain Modelling Language and a
> precompilation phase to generate the code to interact with Infinispan
> (along the lines of what is done in the Fenix framework,
> https://fenix-ashes.ist.utl.pt/trac/fenix-framework). Note that we are
> still at very early design phase, so we are open to ideas, comments and
> especially to learn from your experiences with PojoCache.
>
> As developers of Infinispan, your feedback is extremely valuable to us.
> On one hand, as nobody better than you could provide us indications on
> how to fit within Infinispan's codebase any new experimental feature we
> will be developing in the least intrusive fashion. On the other hand, as
> you can help us to identify what are the most critical issues for
> realistic deployments of Infinispan in Cloud environments, pointing out,
> for instance, which ones, among the current Infinispan
> paramers/functionalities, would benefit the most from self-tuning
> approaches.
>
> We have already started looking at the internal structure of the
> replication's modules of Infinispan, and in the next days we will be
> posting more about the kind of replication schemes (see point 1 above)
> we would like to integrate in Infinispan, and how we are planning to do so.
> In the meanwhile, as a teaser :-), I am sending a reference to a couple
> of recent papers of ours if you are curious to know what kind of
> replication solutions we are currently working on:
> - http://www.gsd.inesc-id.pt/~romanop/files/papers/prdc09.pdf<http://www.gsd.inesc-id.pt/%7Eromanop/files/papers/prdc09.pdf>
> - http://www.gsd.inesc-id.pt/~romanop/files/papers/middleware10.pdf<http://www.gsd.inesc-id.pt/%7Eromanop/files/papers/middleware10.pdf>
>
> Cheers,
>
>    Paolo
>
> --
>
> Paolo Romano, PhD
> Researcher at INESC-ID
> Rua Alves Redol, 9
> 1000-059, Lisbon Portugal
> Tel. + 351 21 3100300
> Fax  + 351 21 3145843
> Webpage http://www.gsd.inesc-id.pt/~romanop<http://www.gsd.inesc-id.pt/%7Eromanop>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20101003/9eede21e/attachment.html 


More information about the infinispan-dev mailing list