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. --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
