<<Forked from [Architecture] Do we need any architecture reviews? >>
Hi everyone, We agreed on moving forward with the following the model for AF (with minor adjustments) in yesterday's (6/18/2013) meeting. However, I've been having this sinking feeling that the way we defined Organization (as a tenant) does not translate well for the API-M. In fact, I think API-M had the most compelling use case for Hierarchical Tenancy; the lack of which, I believe they compensated by using the "super-tenant is the organization" model, which doesn't scale to a multi-organization setup such as *Live. To quote Azeez, these concepts (Organization/Applicaiton/etc..) need to mean the same thing across the platform for consistency and clarity. So, we need to make sure the AF Org model works for API-M or come up with a better one that works everywhere. Can we please meet to discuss? On Sat, Jun 15, 2013 at 5:05 PM, Sameera Perera <[email protected]> wrote: > Hi Nuwan, > > The workaround is to make each application run-time environment > (Dev/QA/Staging/Production) a tenant. > So AppA in QA is deployed to Tenat1, AppA-Staging -> Tenant2, AppB-QA -> > T2, etc. > This lets us keep Application level isolation as well as achieve run-time > isolation. > > AppFactory can continue to use the "App/Project is a tenant" model which > it has today; or for a cleaner implementation, it could use an > "Organization is a tenant" model. With the second model AF can share Team > members among projects cleanly; which it does now through a hack, AFAIK. > The isolation AF needs to provide at the project level is for repositories > and metadata. With the second model, this can be achieved using > roles/permissions. > > In summary, a single Application project, will occupy 5 tenants: One to > run AF (which holds to either the org or the project resources), and one > each for the 4 run-times. > > Flip side is that the following use case is difficult to support with the > above model: > The company needs to share a single resource/service among > apps/environments. > > However, this is probably a special case even for Hierarchical Tenancy and > needed to be handled differently. > Solution in the above model would be to expose the service/resource > through an API and have other environments connect to it. Doing so wouldn't > be an AF feature but the responsibility of the Application developer to set > up. > > > On Sat, Jun 15, 2013 at 9:14 AM, Nuwan Bandara <[email protected]> wrote: > >> Hi Sameera, >> >> Just curious, what is the workaround for it ? >> >> Regards, >> /nuwan >> >> >> On Friday, June 14, 2013, Sameera Perera wrote: >> >>> Hi Samisa, >>> No, it needs to be architected or it's requirement be evaluated at a >>> platform architecture level. >>> AF has a use case for it. But, AF also has a workaround for it. >>> >>> >>> >>> On Fri, Jun 14, 2013 at 11:49 AM, Samisa Abeysinghe <[email protected]>wrote: >>> >>> Do we have any implementations? >>> >>> >>> On Fri, Jun 14, 2013 at 11:42 AM, Sameera Perera <[email protected]>wrote: >>> >>> Hi Srinath, >>> Can the Hierarchical Tenancy topic be reviewed, please? >>> >>> >>> On Fri, Jun 14, 2013 at 11:37 AM, Srinath Perera <[email protected]>wrote: >>> >>> Please let me know. Also it is OK to ask for a review/discussion if you are >>> start working on a topic >>> >>> --Srinath >>> >>> -- >>> ============================ >>> Srinath Perera, Ph.D. >>> Director, Research, 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 >>> >>> _______________________________________________ >>> Architecture mailing list >>> [email protected] >>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>> >>> >>> >>> >>> -- >>> >>> ------------------------------ >>> >>> *Sameera Perera* >>> Senior Manager, API Solutions >>> gtalk: [email protected] >>> *WSO2, Inc.* <http://wso2.com/> >>> lean.enterprise.middleware >>> >>> >>> >>> _______________________________________________ >>> Architecture mailing list >>> [email protected] >>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>> >>> >>> >>> >>> -- >>> >>> Thanks, >>> Samisa... >>> >>> Samisa Abeysinghe >>> VP Engineering >>> WSO2 Inc. >>> http://wso2.com >>> http://wso2.org >>> >>> _______________________________________________ >>> Architecture mailing list >>> >>> >> >> -- >> *Thanks & Regards, >> >> Nuwan Bandara >> Technical Lead; **WSO2 Inc. * >> *lean . enterprise . middleware | http://wso2.com * >> *blog : http://nuwanbando.com; email: [email protected]; phone: +94 11 763 >> 9629 >> * >> <http://www.nuwanbando.com/> >> >> >> _______________________________________________ >> Architecture mailing list >> [email protected] >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > > > -- > > ------------------------------ > > *Sameera Perera* > Senior Manager, API Solutions > gtalk: [email protected] > *WSO2, Inc.* <http://wso2.com/> > lean.enterprise.middleware > > > -- ------------------------------ *Sameera Perera* Senior Manager, API Solutions gtalk: [email protected] *WSO2, Inc.* <http://wso2.com/> lean.enterprise.middleware
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
