airavata-architecture mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Suresh Marru <>
Subject Re: GFac's role in Airavata
Date Tue, 22 Apr 2014 19:05:43 GMT
Hi Eroma,

These are good questions. Now and then stepping back and thinking these
will help. I will try and answer these in detail.

GFac stands for Generic Application Factory - the context of factory
changed over time. Initially it was a factory to create application
services each running in its own JVM, later it was more of instantiating
objects. Today (in my opinion) the factory word is not applicable since we
are really creating services or objects (in a literal sense) but rather its
more of a Facade. So may we should redefine the acronym as Generic
Application Facade :)

Please see below for more:

On Mon, Apr 21, 2014 at 1:43 PM, Eroma Abeysinghe <> wrote:

> Hi Architects,
> What do you think GFac's role is?

GFac framework itself is pretty generic, it chains together few handlers
and invokes an extensible set of providers. What the providers do is really
agnostic to the framework. I look at this as a simple three step process -
pre-process -> process -> post-process. If there are too many
pre-processing steps, then they can be implemented in pluggable handlers
and invoked using chain of responsibility pattern.

> Meaning....
> 1. What features would you want to add?

There are lot of features, I would like to add, but all of them will be in
pluggable extensions. So the basic thing I would like to see is the
framework increasingly should be agnostic to what happens within the
applications and how they are executed. The framework should be less and
less dictative and provide all the necessary capability to manage
applications at scale and in a reliable way. So I should write one plugin
which works well for a single execution and has been builtin checkpoint
recovery at critical steps and then framework should help me deal with
multiple threads of these executions, logging, recovery, call-back and so
on. There should be a guideline of how the contract between the framework
and extensions.

> 2. What existing features you want to change and how?

I would like to see GFac modeled on the concepts of tomcat. Bring your war
drop in, if needed add some more extension specific configurations, restart
get going. I am not referring to tomcat hot deployment style, but referring
to the ease in which war's can be developed and remain independent of
changes to the framework itself.

> 3. What features you want to remove or you think is invalid now?

I think the current architecture is too prescriptive on how a provider
should be written. I rather like to see it more suggestive.

> 4. What is your wishlist for GFac?

The framework providing core features like scalability, extensibility,
fault tolerance, thread management, persistence of requests and leaving out
all the lower level intrenches to the extensible components themselves.


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message