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.
Marlon 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 < > [email protected]> 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 >
