Hi all, Currently, WSO2 App Cloud follows the container based approach to provide different runtime to deploy application artifacts. Likewise we can follow the same approach to deploy ESB car file as a app type in WSO2 App Cloud. But, our requirement is to provide a separate cloud perspective (view) for end users for integration solutions, so we thought to generalize the app cloud to operate in two modes (as app cloud and integration cloud) on single app cloud deployment.
1. We need two different URLs (https://apps.cloud.wso2.com and https://integration.cloud.wso2.com ) to login to separate clouds. How SSO works : Currently, when a user login, it redirect to WSO2IS for SSO and then it comes to app cloud with https://apps.cloud.wso2.com url. Same as when user requests integration cloud it should redirect to WSO2IS and then it comes to the app cloud with https://integration.cloud.wso2.com url. For that we use 2 different issuers and 2 SPs configured in IS side. When the request first come to the app cloud, we find which cloud the user requests based on the host name, and then redirect the request to IS with correct issuer. Loading relevant cloud view with valid titles, breadcrumbs, navigation buttons, etc ...: Once the SSO happens we put the requested cloud to the session and then loads the UI with the correct UI elements reading the following json file. { "app-cloud" : { "pageTitle": "WSO2 App Cloud", "cloudTitle" : "Application Cloud", "properties" : { "documentationUrl": "AppCloud.Documentation.Url", "supportUrl": "AppCloud.Support.Url” } }, "integration-cloud" : { "pageTitle": "WSO2 Integration Cloud", "cloudTitle" : "Integration Cloud", "properties" : { "documentationUrl": "IntegrationCloud.Documentation.Url", "supportUrl": "IntegrationCloud.Support.Url” } } } 2. Based on the selected cloud, app cloud should operate as follows. - We want to differentiate app types per cloud. - Application home page should list the application which was created in selected cloud. - Application home page search function should work on application which was created in selected cloud only. - Separate subscription plans required per cloud. [max number of applications and databases per cloud] - Separate white listing required per cloud. So we changed the app cloud database table structure as shown in below diagram and updated the implementation to get per cloud data. With these changes we can deploy the app cloud as a separate deployment if required in future. 3. Unified UI design Per app type, we will be require loading different UI components to the app home page. As an example: How we display endpoints per app type. Different type of application provides different types of endpoints. ESB app types give SOAP and REST endpoints. Web/PHP gives just a web url. JAX-WS gives SOAP endpoint, etc…Likewise we will be required to add more UI components per app types. So we decided to go with unified UI design approach per app type with javascript abstraction layer. https://github.com/wso2/app-cloud/blob/master/modules/jaggeryapps/appmgt/src/modules/application/endpoints.jag This is how we render endpoints per app type: When user navigates to the app home page we make a call to the container and get the urls and generate the UI component to display in app home page. We don’t persist these endpoints in database. So user can’t see the endpoints when the container is not up and running. Please give your feedback on this if something looks wrong. Thank you Amalka
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
