On Thu, Mar 30, 2017 at 12:56 PM, Harsha Thirimanna <[email protected]> wrote:
> 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 <+94%2071%20518%206770> > 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
