Hi Dilan, Sorry I was trying to make my answer very short thus some points were not clearly explained.
> 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. This is the exact problem I am trying to emphasize. When we invoke REST service or SOAP service from the Jaggery App; flow will be similar to the following. [image: Inline image 1] Browser will invoke the jaggery api / jaggery page. Then the page will do a web service call using a HTTP client. Hence we are making two network calls here. Network calls are costlier and adds another set of problems such as connection timeouts...etc. We can avoid second network call by directly calling the OSGi service. 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. Yes. correct. This is why we need to avoid calling another HTTP call to invoke user management apis. I did not understand your second point either. My second point is that currently how we install jaggery apps into the product distribution is via Carbon Features. To be exact; we are using p2 touchpoints to copy jaggery apps into relevant path(i.e. <PRODUCT_HOME>/repository/deployments/server/jaggeryapps). Suppose our jaggery app is "Foo" and it needs a backend called "Bar". Since our jaggery app is a carbon feature we can declare feature dependencies in the pom.xml so that we explicitly declare when you using this jaggery app "Foo"; "Bar" feature should be co-exist. Thanks Rasika On Tue, Aug 2, 2016 at 5:47 PM, Dilan Udara Ariyaratne <[email protected]> wrote: > 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 <[email protected]> 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 <[email protected]> >> 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 >>> [email protected] >>> 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 >> > > -- 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 [email protected] http://wso2.org/cgi-bin/mailman/listinfo/dev
