Hi Kishanthan,
On Tue, Jul 1, 2014 at 8:03 PM, Kishanthan Thangarajah <[email protected]> wrote: > Hi All, > > We recently had a meeting on $subject. Our current story for CApp (Carbon > Application) development approach is broken when including application of > QoS for services. This was mainly due to the issues we faced with, > > - the file-based metadata persistence layer for services. > - the possibility to change/apply QoS via mgt console. > - clustering and deployment synchronization. > > To fix these, as the first step, we have removed the file based > persistence layer from platform. This layer was mainly used to persist QoS > related settings of the axis2services. This can be replaced by using > services.xml file for each service. All types of axis2services (other than > proxy-services) has support for services.xml currently. For proxy services, > the application of some QoS (Ex: security) can be defined inline by > referring the relevant policies from registry. > > We need a meeting to discuss about the following next steps. > - How this will affect ESB (proxy-services) and how to fix those. > - Removing the current way of applying QoS via mgt console and providing a > different approach, which will not be part of the CApp development process. > This will have serious impact on STS functionality of IS. STS is a specialised axis2 service, deployed from an OSGi bundle and shared across all tenants. The security policy used to secure the STS is within the scope of a tenant and is deployed as a service metafile like any other service. STS is unsecured by default. Tenant admins would secure the STS with preferred policy. Two reason why the above approach would not work for IS, 1. Securing STS is a admin functionality in my opinion. It is not a development time aspect. This may be not the case for other services. 2. Since STS is a shared service editing services.xml won't work. If we go with this new approach in platform, we need to do the following from IS side. 1. We need to continue using the security wizard UI to apply policies and modify the backend service to persist policy in either registry or Identity DB. 2. We need to modify the Security Deployment Interceptor which reads the security policy from filesystem, to read it from registry or database. @Sagara/KasunG How is AS team planning to handle this. Are you going to deprecate usage of security wizard UI and leave it to development time? Or are you having any other approach in mind? Thanks, Johann. > Thanks, > Kishanthan. > > -- > *Kishanthan Thangarajah* > Senior Software Engineer, > Platform Technologies Team, > WSO2, Inc. > lean.enterprise.middleware > > Mobile - +94773426635 > Blog - *http://kishanthan.wordpress.com <http://kishanthan.wordpress.com>* > Twitter - *http://twitter.com/kishanthan <http://twitter.com/kishanthan>* > > _______________________________________________ > Dev mailing list > [email protected] > http://wso2.org/cgi-bin/mailman/listinfo/dev > > -- Thanks & Regards, *Johann Dilantha Nallathamby* Associate Technical Lead & Product Lead of WSO2 Identity Server Integration Technologies Team WSO2, Inc. lean.enterprise.middleware Mobile - *+94777776950* Blog - *http://nallaa.wordpress.com <http://nallaa.wordpress.com>*
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
