Hi Rasika, I did not get the point of "two network calls" here.
Instead of the direct OSGI call to user management, what we are hoping to achieve is doing one network call to user management admin service. I did not understand your second point either. Our actual consideration is that a direct OSGI call from the UI to a back-end feature like user management brings the unnecessary concern of maintaining additional features in the server except the Jaggery runtime on top of tomcat. However, Please do correct me if these considerations are wrong. For example, I too have the following doubt. Our EMM or IoT servers are meant to be run as either manager or worker nodes. Manager node is the place where we deploy the UI. Any of these servers is a carbon server and in every carbon server, user management feature comes by default. In that case, I also have the question of why should we do a costly network call to user management via admin services when the same functionality is anyway accessible so easily by a direct OSGI call via Jaggery wrapper functions. @prabatha, WDYT? Regards Dilan. *Dilan U. Ariyaratne* Senior Software Engineer WSO2 Inc. <http://wso2.com/> Mobile: +94766405580 <%2B94766405580> lean . enterprise . middleware On Tue, Aug 2, 2016 at 3:13 PM, Rasika Perera <rasi...@wso2.com> wrote: > Hi All, > > We would be able to easily provide a REST API for this at device-mgt api >> layer. >> But, due to the fact that such an API is OAuth token protected, this is >> again not a solution >> because by this point of time, the logged-in user has not even received a >> token. >> As a result, current suggestion is to do a SOAP webservice call using >> basic-auth to >> user management admin services and retrieve tenant information. > > In this case, I am -1 to do two network calls. When designing new UUF, > this was one of main concern too. Whenever possible you need to do direct > method calls(i.e. OSGi call). > > >> This direct coupling of backend OSGi services with the UI is not >> encouraged as that creates an unnecessary requirement >> such that UI jaggery app and the carbon user management OSGi service to >> co-exist in the same server. > > With the current jaggery app delivery mechanism, We can easily solve this > problem by adding carbon feature level dependency to the user management > OSGi service(whatever feature that brings OSGi service of our concern). > > For instance; > If our jaggery app feature is "org.wso2.carbon.device.mgt.ui.feature" we > can add; > > <includedFeatures> > <featureDef>{groupId}:{artifactId}</featureDef> > </includedFeatures> > > WDYT? > > On Tue, Aug 2, 2016 at 2:45 PM, Dilan Udara Ariyaratne <dil...@wso2.com> > wrote: > >> Hi All, >> >> At EMM/IoTs UI web app level, >> for setting up an OAuth token pair for a newly authenticated user, >> we require the use of tenant-based client app credentials. >> >> These credentials will be retrieved by the provided tenant domain of the >> authenticated user >> and it seems that currently the particular information is retrieved via a >> jaggery wrapper function called >> "carbon.server.tenantDomain({username: username})" to the underneath >> user-mgt OSGi service of the default pack. >> >> This direct coupling of backend OSGi services with the UI is not >> encouraged as that creates an unnecessary requirement >> such that UI jaggery app and the carbon user management OSGi service to >> co-exist in the same server. >> >> Thus, I am bringing in the concern of $subject. >> >> We would be able to easily provide a REST API for this at device-mgt api >> layer. >> But, due to the fact that such an API is OAuth token protected, this is >> again not a solution >> because by this point of time, the logged-in user has not even received a >> token. >> >> As a result, current suggestion is to do a SOAP webservice call using >> basic-auth to >> user management admin services and retrieve tenant information. >> >> Cheers, >> Dilan. >> >> *Dilan U. Ariyaratne* >> Senior Software Engineer >> WSO2 Inc. <http://wso2.com/> >> Mobile: +94766405580 <%2B94766405580> >> lean . enterprise . middleware >> >> >> _______________________________________________ >> Dev mailing list >> Dev@wso2.org >> http://wso2.org/cgi-bin/mailman/listinfo/dev >> >> > > > -- > With Regards, > > *Rasika Perera* > Software Engineer > LinkedIn: http://lk.linkedin.com/in/rasika90 > > [image: wso2-signature-general.png] <https://wso2.com/signature> > > WSO2 Inc. www.wso2.com > lean.enterprise.middleware >
_______________________________________________ Dev mailing list Dev@wso2.org http://wso2.org/cgi-bin/mailman/listinfo/dev
