In C5, there is no shared process multitenancy. We will launch separate container instances for tenants. There will be a gateway fronting the deployment which will identify the tenant based on the request URL (which will contain the tenant domain or some UID identifying a tenant), and then route the request to the relevant tenant's container (This would probably be a Kubernetes service endpoint)
Thanks Azeez On Sat, Nov 28, 2015 at 10:11 PM, Frank Leymann <[email protected]> wrote: > Hi Nuwan, > > the fact that most of our customers are not using multi-tenancy is a > convincing argument :-) > > However, let me point out that (vendor-specific) header fields have a > bunch of problems. For example, a cache will have to be aware that it has > to pass the X-xyz header back to the origin server in case of freshness > validation (which is what a cache doesn't do out of the box). Also, a load > balancer can't be set up to route requests based on the URL (as in the case > the tenantID would be part of the URL), etc. Thus, the REST recommendation > is to have tenantIDs in the URL - we need to have arguments available if we > are confronted with these weaknesses in a review. > > Finally a question: How do we identify tenants in C5? Or don't we support > multi-tenancy in C5? > > > Best regards, > Frank > > 2015-11-23 5:26 GMT+01:00 Nuwan Dias <[email protected]>: > >> Hi Frank, >> >> In Summary, there are two main reasons we decided to go against having >> the tenant domain as part of the URI. >> >> 1. Its optional. For people who aren't interested in multi-tenancy ( > >> 75%), there would not be a need to expose this complexity. >> >> 2. With C5, tenancy is going to be container based. Therefore the >> underlying Applications would not (necessarily) have to deal with tenant >> related concepts. So having a tenant domain as part of the URL would not >> make much sense in there. >> >> Thanks, >> NuwanD. >> >> On Sun, Nov 22, 2015 at 11:18 PM, Malintha Amarasinghe < >> [email protected]> wrote: >> >>> Hi, >>> >>> Yes we have implemented it in the way Sanjeewa mentioned in the previous >>> mail. Due to the complexity and inconsistency (with the requests which does >>> not require tenant domain) of having the tenant domain as the part of the >>> context, we decided to send it as a query/header parameter. According to >>> the current implementation, we have used a header parameter. >>> >>> A sample request would be as follow: >>> >>> >>> - User "[email protected]" wants to see what are the APIs that are >>> available in the tenant cloud.com >>> >>> *GET* http://127.0.0.1:9764/api/am/store/v1/apis HTTP/1.1 >>> *X-WSO2-Tenant*: cloud.com >>> *Authorization*: *Basic* *Or Bearer token* >>> >>> >>> >>> We identify the user's tenant domain from the authorization header. If >>> he need to lookup resources of a different tenant domain, he can send it >>> from the *X-WSO2-Tenant *header. This is only supported in Store for >>> following use cases. >>> >>> 1. User wants to get all APIs from a different tenant domain. >>> 2. User wants to get a specific API from a different tenant domain. >>> 3. User wants to see documents of an API which is in a different tenant >>> domain. >>> 4, User wants to see a specific document of an API which is in a >>> different tenant domain. >>> >>> Thank you. >>> Malintha. >>> >>> >>> >>> On Sun, Nov 22, 2015 at 9:49 PM, Sanjeewa Malalgoda <[email protected]> >>> wrote: >>> >>>> Hi frank, >>>> As we discussed during last meeting tenant domain will not be a part of >>>> context. So application url remain as it is and current logged tenant will >>>> identified using authentication details client send(we start tenant flow >>>> based on logged in user). >>>> If need we can make tenant name query parameter in url. >>>> Requested tenant can be transport header and part of API. >>>> >>>> I think malintha already implemented this for some resources which >>>> requires requested tenant. He may provide more information. >>>> >>>> Thanks >>>> sanjeewa. >>>> >>>> sent from my phone >>>> On Nov 22, 2015 7:14 PM, "Frank Leymann" <[email protected]> wrote: >>>> >>>>> Dear all, >>>>> >>>>> let me try to understand: >>>>> >>>>> A user ([email protected]) wants to access a resource created by a >>>>> certain tenant (cloud.com) - correct? The tenant created the >>>>> resource and we decided to make the tenant-id part of the context of the >>>>> resource's URL. >>>>> >>>>> Thus, the user who wants to access the tenant's resource is a >>>>> parameter of some sort of (new?) API that requests access to the tenant's >>>>> resource. >>>>> >>>>> This (new?) API would look something like this: >>>>> >>>>> <host>/<context>/{tenant}/<API-name>/<parameters>&[email protected] >>>>> >>>>> Does it make sense or did I miss the discussion? >>>>> >>>>> >>>>> >>>>> Best regards, >>>>> Frank >>>>> >>>>> 2015-11-17 16:16 GMT+01:00 Sanjeewa Malalgoda <[email protected]>: >>>>> >>>>>> If we think this very carefully requested tenant domain should be >>>>>> part of the API. >>>>>> Let me explain it, >>>>>> We have API and that behave in some manner according to provided >>>>>> parameters and inputs. >>>>>> In this particular scenario, we are passing completely different data >>>>>> set and get different results. >>>>>> So cant we take this as user input for API? If we added that as >>>>>> parameter then it will be part of API(non mandatory parameter). >>>>>> >>>>>> Or else we may need to have ability of setting custom fields in >>>>>> carbon context as that can be accessible across all places of started >>>>>> flow. >>>>>> But according to current implementation we cannot place anything in >>>>>> carbon context. >>>>>> With tenant app sharing concept we need to have logged in tenant and >>>>>> requested tenant both in message context to give proper results. >>>>>> Shouldn't we have that capability in carbon context? >>>>>> >>>>>> Thanks, >>>>>> sanjeewa. >>>>>> >>>>>> >>>>>> >>>>>> On Mon, Nov 16, 2015 at 2:20 PM, Malintha Amarasinghe < >>>>>> [email protected]> wrote: >>>>>> >>>>>>> Hi All, >>>>>>> >>>>>>> In API Manager REST API, we will be supporting cross tenant >>>>>>> scenarios. Few examples would be like below. >>>>>>> >>>>>>> 1. [email protected] wants to see the APIs that are available in the >>>>>>> tenant store; cloud.com >>>>>>> 2. [email protected] wants to see the documents of an API weatherAPI >>>>>>> that are available in the tenant store; cloud.com >>>>>>> >>>>>>> For this requirement we need to pass the "required tenant domain" >>>>>>> parameter with the request as the logged in user belongs to is a >>>>>>> different >>>>>>> tenant. There are several possible ways to specify this. >>>>>>> >>>>>>> 1. Specify this as a query parameter for every resource this is >>>>>>> required >>>>>>> >>>>>>> ex: GET >>>>>>> http://127.0.0.1:9763/api/am/publisher/v1/apis?*tenantDomain=cloud.com >>>>>>> <http://cloud.com>* >>>>>>> >>>>>>> >>>>>>> 2. Specify this as a header parameter >>>>>>> >>>>>>> 3. Specify this within the URI. >>>>>>> >>>>>>> a. before the Jax-RS web app context >>>>>>> >>>>>>> ex: GET http://127.0.0.1:9763/*t/cloud.com <http://cloud.com>* >>>>>>> /api/am/publisher/v1/apis >>>>>>> >>>>>>> b. after the Jax-RS web app context >>>>>>> >>>>>>> ex: GET http://127.0.0.1:9763/api/am/publisher/v1/*t/cloud.com >>>>>>> <http://cloud.com>*/apis >>>>>>> >>>>>>> >>>>>>> Regarding these three options, option (3.a) would require the web >>>>>>> app to be deployed on each and every tenant. Or otherwise we should >>>>>>> manually register contexts in tomcat run-time to match those contexts. >>>>>>> Even >>>>>>> if we register context manually, this would not be a good solution as >>>>>>> the >>>>>>> user might expect the web app to be in the tenant space (when he sees >>>>>>> the >>>>>>> /t/tenant part in the URI) but it is not there actually. Option (3.b) >>>>>>> would >>>>>>> require the web app to handle the tenant as a resource and every other >>>>>>> resource would need to be a sub-resource. And we need to specifically >>>>>>> handle for the super tenant which we don't specify the tenant in the >>>>>>> URL. >>>>>>> For options (1) and (2), we don't need to face such difficulties. >>>>>>> >>>>>>> Please share your thoughts. >>>>>>> >>>>>>> Thanks. >>>>>>> Malintha >>>>>>> >>>>>>> -- >>>>>>> Malintha Amarasinghe >>>>>>> Software Engineer >>>>>>> *WSO2, Inc. - lean | enterprise | middleware* >>>>>>> http://wso2.com/ >>>>>>> >>>>>>> Mobile : +94 712383306 >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> >>>>>> *Sanjeewa Malalgoda* >>>>>> WSO2 Inc. >>>>>> Mobile : +94713068779 >>>>>> >>>>>> <http://sanjeewamalalgoda.blogspot.com/>blog >>>>>> :http://sanjeewamalalgoda.blogspot.com/ >>>>>> <http://sanjeewamalalgoda.blogspot.com/> >>>>>> >>>>>> >>>>>> >>>>> >>> >>> >>> -- >>> Malintha Amarasinghe >>> Software Engineer >>> *WSO2, Inc. - lean | enterprise | middleware* >>> http://wso2.com/ >>> >>> Mobile : +94 712383306 >>> >> >> >> >> -- >> Nuwan Dias >> >> Technical Lead - WSO2, Inc. http://wso2.com >> email : [email protected] >> Phone : +94 777 775 729 >> > > -- *Afkham Azeez* Director of Architecture; WSO2, Inc.; http://wso2.com Member; Apache Software Foundation; http://www.apache.org/ * <http://www.apache.org/>* *email: **[email protected]* <[email protected]> * cell: +94 77 3320919blog: **http://blog.afkham.org* <http://blog.afkham.org> *twitter: **http://twitter.com/afkham_azeez* <http://twitter.com/afkham_azeez> *linked-in: **http://lk.linkedin.com/in/afkhamazeez <http://lk.linkedin.com/in/afkhamazeez>* *Lean . Enterprise . Middleware*
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
