Hi Milinda, Please see my comments.
On Sun, Jul 1, 2012 at 11:49 AM, Milinda Pathirage < [email protected]> wrote: > Hi Devs, > > Current GFac runtime context hierarchy is confusing and I think there is > a mismatch between what actually happens inside GFac and the current > context hierarchy which includes JobContext, InvocationContext, > MessageContext, ExecutionContext and SecurityContext. > > As I understand what really happens inside GFac Core(only considering job > execution; deployment is excluded in this) is as follows(please > correct me if I am wrong): > > * Workflow interpreter or Axis2 Service invoke submitJob operation of > * GFac API with required information(input message, security related > * information, application description) and when invoked GFac Core > * will execute 'in handler chain', actual application(or job) and > * finally the 'out handler chain' before sending response message back > * to the client. > > According to above, I think it's enough to have MessageContext(to > represent input and output message), JobExecutionContext(represent > single execution of a application; will contains both input and output > message contexts and ApplicationContext) and > ApplicationContext(Application related configuration required to execute > application). > I agree with this approach. FYI we have implemented JobContext very recently to create an API for GFac . previously there wasn't an API for gfac. So if you can preserve the data in JobContext this approach would be fine. And right now we are not using SecurityContext at all but ideally we will be having securityContext when we implement security related features of Airavata. So I think we need to preserve that data too, Do you think we need to keep them in SecurityContext object or just add them to one of the proposed Context objects ? Please correct the naming according to the data we keep in Context objects and I agree the naming is kind of confusing according to what we keep in context objects. Thanks for proposing a new architecture and lets discuss more and come up with a better API. Lahiru > > I am going to implement above in the branch created to refactor GFac. > Please feel free to comment on this. > > Thanks > Milinda > > > -- > Milinda Pathirage > PhD Student Indiana University, Bloomington; > E-mail: [email protected] > Web: http://mpathirage.com > Blog: http://blog.mpathirage.com > -- System Analyst Programmer PTI Lab Indiana University
