I understand the reasons for moving away from registry and it makes sense. No question about that. And I'm +1 for doing it.
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. 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
