Hi All, Since we have almost finished a few milestones in IS 6.0.0, we thought of discussing some points regarding the deployment of different portal and the development experience around this.
We have already planned to develop the following components in IS 6.0.0 As in the diagram, there are 3 portals called admin, user and developer tool which allows different user personas to perform their respective operations. All three web applications should be configured with SSO and should give a good experience by clearly separating the responsibilities as well as making each web app easily accessible. 1. Admin portal provides user management, sp/idp operations. 2. User portal provides the user specific operations. 3. Dev Tool provides the facility to create artifacts and manage it. The developer tool can be illustrated as in the following diagram, (a) Represents the communication between browser based editor and the editor backend. Since we are going to implement a single page application for the editor, we hope to develop a editor backend service separately to allow scaling independently. (b) Each developer has his own workspace area in the development server. (c) We can give the option to configure a github account per tenant in the editor and push the artifact from workspace to the github account to manage the artifact. (d) CLI interface provides the basic operations supported by IS to be executed in the command line. We can download the artifact from the editor and deploy through the CLI interface. (e) Editor backend is configured to access the IS Rest API and it is possible to deploy the artifact from the editor to the IS directly. As in above, we can either develop the artifacts like sp/idp in a file or by using the editor and then deploy through CLI tool. If it is developed using the editor, we can directly push to the runtime. When we consider a production deployment like WSO2 cloud, we can consider the following diagram as the best practice for that, As in above, we allow the developer to develop the artifacts in dev-env and push to the runtime by either directly from the tool or through CLI interface. When we think about governing this artifact we have several options, 1. We can download the dev-env artifacts and change the environment specific configurations and push to the next env. By doing that, we don't need to put editor functionality to the developer in other environments except the dev-env. 2. If we want to allow to configure the editor functionality in each environment, then no issue there and we can do the same as in dev-env to the developer as well in production. However, there are several special cases in IS which require to edit some artifacts like Service provider for privileged users who has permission to create OAuth applications through DCR in production. So after creating the OAuth applications, they can list their applications in production User portal and edit. When they click on edit link, it will open the selected application in the developer tool in the same environment. When we login to the Admin portal, we can list the SP/IDPs and if that environment is configured for the developer portal access, then we can enable the edit button for each artifact to allow editing it via the developer tool. Otherwise, it will only allow to list and view the artifact in read-only mode. This is similar to a real production environment where editing artifacts is not allowed, except special cases like DCR application. Artifact Deployment After we create the artifacts from the editor or by hand, we get a yaml file as the outcome. We are going to store this in database as the deployment mechanism in runtime to share between the IS nodes in the cluster easily. There are several methods to achieve this, either store the entire config as a blob in DB or prepare a schema in DB for each DB vendors. What would be the best approach for this ? thanks *Harsha Thirimanna* *Associate Tech Lead | WSO2* Email: [email protected] Mob: +94715186770 Blog: http://harshathirimanna.blogspot.com/ Twitter: http://twitter.com/harshathirimann Linked-In: linked-in: http://www.linkedin.com/pub/harsha-thirimanna/10/ab8/122 <http://wso2.com/signature>
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
