> > > My concern was that architecturally terming it as an anti-pattern. In ESB > there are many production instances running with artifacts like endpoints, > schema, XSLT etc stored and fetched from registry; all at runtime, with no > much issue. And registry had a caching layer too. I see this as an > abstraction, just like data is exposed as a web service API in data > services server. >
Basically issue happens in multi tenant environment. when different tenants try to access the registry resource at runtime, we need to load the tenant registry before accessing the resource. That makes fetching the resource from registry more costly than fetching directly from the database. If we are accessing only super tenant registry at runtime, I also don't think there is much difference between in fetching data from registry and database. > In this case, I agree on all the good reasons for doing it. > > On Wed, Jun 6, 2018 at 9:59 PM, Sagara Gunathunga <sag...@wso2.com> wrote: > >> >> >> On Wed, Jun 6, 2018 at 1:05 PM, Shazni Nazeer <sha...@wso2.com> wrote: >> >>> Currently we persist oidc related scopes and claims in the registry. >>>> With this approach we need to access the registry in run time, which is an >>>> anti-pattern. So going forward we have decided to persist oidc scopes and >>>> claims in the db and remove from the registry. >>> >>> >>> I'm sure there are good reasons to move the claim mappings from the >>> registry to plain DB. But isn't this essentially the same as ultimately >>> registry stores values in the underlying DB. I'm sure the change may make >>> the implementation straightforward to use the DB query instead of the >>> registry API and also makes way to move away from registry. But why using >>> registry is an anti-pattern? >>> >> >> 1. Registry is not designed to cater runtime traffic, it was originally >> designed to cater non-runtime (design time) traffic, so by design there is >> a scalability issue when we use registry in run-time use cases. Few years >> back we have experienced this when trying to persist AS and ESB runtime >> metafiles in the registry. >> >> 2. We are in a process of moving out registry dependencies from all >> products except G-Reg because most of the cases it's unnecessary , API-M 3 >> did this up to some extend. In this case we have noticed a scalability >> issue in userinfo calls and as a part of the fix we are trying to remove >> one registry dependency from IS. >> >> Thanks ! >> >>> >>> On Wed, Jun 6, 2018 at 11:48 AM, Hasanthi Purnima Dissanayake < >>> hasan...@wso2.com> wrote: >>> >>>> Hi All, >>>> >>>> Currently we persist oidc related scopes and claims in the registry. >>>> With this approach we need to access the registry in run time, which is an >>>> anti-pattern. So going forward we have decided to persist oidc scopes and >>>> claims in the db and remove from the registry. >>>> >>>> *With the new implementation:* >>>> 1. In the management console 'Resident Identity Provider > Inbound >>>> Authentication Configuration > OAuth2/OpenidConnect configuration' will be >>>> divided in to two sections. >>>> a. First section will include the existing EP URLs >>>> b. Second section will include scope claim table which have the >>>> ability to add and delete scope claim mapping. >>>> 2. In the first server start up the scopes and claims defined >>>> in oidc-scope-config.xml will be stored in the db and a caching layer. >>>> 3. So when the UI is loading the scopes and claims that are stored in >>>> the table will be populated to the UI as well. >>>> >>>> I will update the thread with the screen shots of the new UI and the >>>> design of the new table soon. Highly appreciate any suggestions or >>>> feedbacks on this. >>>> >>>> Thanks, >>>> >>>> -- >>>> >>>> Hasanthi Dissanayake >>>> >>>> Senior Software Engineer | WSO2 >>>> >>>> E: hasan...@wso2.com >>>> M :0718407133| http://wso2.com <http://wso2.com/> >>>> >>> >>> >>> >>> -- >>> Shazni Nazeer >>> >>> Mob : +94 777737331 >>> LinkedIn : http://lk.linkedin.com/in/shazninazeer >>> >>> Blogs : >>> >>> https://medium.com/@mshazninazeer >>> http://shazninazeer.blogspot.com >>> >>> <http://wso2.com/signature> >>> >> >> >> >> -- >> Sagara Gunathunga >> >> Director; WSO2, Inc.; http://wso2.com >> Linkedin; http://www.linkedin.com/in/ssagara >> Blog ; http://ssagara.blogspot.com >> Mobile : +9471 <+94%2071%20565%209887>2149951 >> >> > > > -- > Shazni Nazeer > > Mob : +94 777737331 > LinkedIn : http://lk.linkedin.com/in/shazninazeer > > Blogs : > > https://medium.com/@mshazninazeer > http://shazninazeer.blogspot.com > > <http://wso2.com/signature> > > _______________________________________________ > Architecture mailing list > Architecture@wso2.org > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- *Danesh Kuruppu* Associate Technical Lead | WSO2 Email: dan...@wso2.com Mobile: +94 (77) 1690552 Web: WSO2 Inc <https://wso2.com/signature>
_______________________________________________ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
