On Wed, Jun 19, 2013 at 9:22 AM, Sameera Perera <[email protected]> wrote:
> <<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, > Why? What is the use case or mapping model? > 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 > > -- Thanks, Samisa... Samisa Abeysinghe VP Engineering WSO2 Inc. http://wso2.com http://wso2.org
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
