airavata-architecture mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marlon Pierce <>
Subject Re: GFac's role in Airavata
Date Tue, 22 Apr 2014 21:08:58 GMT
I like the Tomcat analogy for providers. We need to think of
provider+handler codes as being developed by third parties who don't
know or care about the internals of the GFac core.


On 4/22/14 3:05 PM, Suresh Marru wrote:
> 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.
> Cheers,
> Suresh

View raw message