On Wed, Jul 4, 2012 at 10:02 PM, Srinath Perera <[email protected]> wrote:
> Hi Milinda, > > Context hierarchy mirror the execution. There is a execution context for > each execution, each execution has two message contexts (incoming and > outgoing). I guess it is OK to mirror the same idea in a different model. > > But IMHO security context you should keep, as that hides the > different security impls as Ram mentioned. > +1 Lahiru > > --Srinath > > On Mon, Jul 2, 2012 at 9:40 PM, Raminderjeet Singh < > [email protected] > > wrote: > > > The Security context is to handle different security protocols.There can > > be security context like Grid security, Cloud security, SSH/kerberos > > security etc. We want to make the security configurable at provider level > > and request level. Provider level means that we configure default > security > > setting for a provider while system setup. Request level means that if > > someone want to overwrite security credentials then he can do it using > > security context. Security is attached to each request. > > > > You are looking into the implementation so you are the best judge. > Please > > let me know if you want me to explain more. > > > > Thanks > > Raminder > > > > On Jul 2, 2012, at 11:49 AM, Milinda Pathirage wrote: > > > > > Hi Lahiru, > > > > > > I am thinking of keeping security related data in MessageContext. In > > > case we have to get security related data from application > > > configuration, we can do it via ApplicationContext. > > > > > > Thanks > > > Milinda > > > > > > On Sun, Jul 1, 2012 at 10:03 PM, Lahiru Gunathilake <[email protected] > > > > wrote: > > >> 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 > > > > > > > > > > > > -- > > > Milinda Pathirage > > > PhD Student Indiana University, Bloomington; > > > E-mail: [email protected] > > > Web: http://mpathirage.com > > > Blog: http://blog.mpathirage.com > > > > > > > -- > ============================ > Srinath Perera, Ph.D. > Senior Software Architect, WSO2 Inc. > Visiting Faculty, University of Moratuwa > Member, Apache Software Foundation > Research Scientist, Lanka Software Foundation > Blog: http://srinathsview.blogspot.com/ > Photos: http://www.flickr.com/photos/hemapani/ > Phone: 0772360902 > -- System Analyst Programmer PTI Lab Indiana University
