Hi All, We can minimize the FE-BE communication by only moving the methods which require Queue connection to be created. Then there won't be any key shared and exposed to the FE. So basically browseQueue() method move to the BE and once the queue details comes to FE getMsgProperties(), getMsgContentType(), getMessageContentAsString() can be called with those data. I think then the communication overhead will be reduce up to considerable extent. I will consider the other client classes methods also with the same approach. If there is any concern with this approach please post to this thread.
Cheers! On Wed, Apr 9, 2014 at 3:32 PM, Suresh Attanayaka <sur...@wso2.com> wrote: > Hi Ishara, > > I would not agree with your argument regarding the FE-BE communication > overhead, afterall most of the time it is just a java call over the > local-transport, no http cost at all. For me, consuming the JMS queue from > the UI is no different from connecting to the database over JDBC from the > UI which is not really our model. > > Plus, the key shared there is a system key and exposing it over HTTP is > not a good idea. It should be shared using the OSGI service instead. > > On Wed, Apr 9, 2014 at 2:30 PM, Ishara Premadasa <ish...@wso2.com> wrote: > >> Hi Indika, >> >> Your observation is correct that getAccessKey() method is not exposed to >> all the users, however few clarifications to made is this method is not >> configured to admin role only. According to the current permission model in >> carbon we can create new roles and assign permissions to that accordingly. >> However if you look at the permission tree there is only two MB related >> permission options named, >> >> >> MB >> >> >> >> >> - >> >> >> Add Queue >> >> >> >> >> >> >> >> - Queue Details >> >> Therefore for a user to perform other queue operations than this, we need >> to provide admin--> configure permission as shown in image [1] which is the >> reason getAccessKey() is bound to /permission/admin/configure level. (This >> is more like for any user to work with MB it needs some admin priviledges >> )Therefore IMO it would be better if we can add more options to above MB >> level permissions like Browse Queue etc. so user can be authorized to >> getAccessKey() >> by selecting that permission rather than moving the operations into BE. >> >> >> On Wed, Apr 9, 2014 at 11:48 AM, Indika Sampath <indi...@wso2.com> wrote: >> >>> Hi All, >>> >>> There is an issue with browsing the queue for users which haven't admin >>> role. The reason is following two methods restricted to the admin role in >>> Axis2 level. >>> >>> - getCurrentUser() >>> - getAccessKey() >>> >>> There is a way to get the current logged user from the session but there >>> is no way to get the access key. >>> org.wso2.carbon.andes.ui.client.QueueBrowserClient creating a queue >>> connection and access the queue from the FE. We need user name and access >>> key to creating queue connection. There might be some security issue with >>> QueueBrowserClient as I and Hasitha had discussion with Suresh on >>> yesterday. Some operations in org.wso2.carbon.andes.ui module needs to move >>> to the BE. I have come up with the following implementation design. >>> >>> Move following methods in the QueueBrowserClient to >>> org.wso2.carbon.andes.core.QueueManagerService and expose as web service >>> via org.wso2.carbon.andes.admin.AndesAdminService. >>> >>> >>> - browseQueue() >>> - closeBrowser() >>> - getMsgContentType() >>> - getMessageContentAsString() >>> >>> When we change like this we need to call the BE four times for each >> Browse operation and this would be same for publish sample msg, purge queue >> etc. which we don't necessarily have to go for BE. Wouldn't it be an >> overhead that we make several FE <--> BE calls for a single UI operation >> each time? >> >> Thanks! >> Ishara >> >> [1] >> https://svn.wso2.org/repos/wso2/people/isharap/permissions_non_admin_user.png >> >> >>> But there are another two classes >>> org.wso2.carbon.andes.ui.client.QueueReceiverClient and >>> org.wso2.carbon.andes.ui.client.QueueSenderClient needs do the same thing >>> as I think. >>> >>> Cheers! >>> >>> -- >>> Indika Sampath >>> Software Engineer >>> WSO2 Inc. >>> http://wso2.com >>> >>> Phone: +94 716 424 744 >>> Blog: http://indikasampath.blogspot.com/ >>> >>> >> >> >> -- >> Ishara Premasada >> Software Engineer, >> WSO2 Inc. http://wso2.com/ >> >> >> *Blog : http://isharapremadasa.blogspot.com/ >> <http://isharapremadasa.blogspot.com/>Twitter : >> https://twitter.com/ishadil <https://twitter.com/ishadil> Mobile : >> +94 714445832 <%2B94%20714445832>* >> >> >> > > > -- > Suresh Attanayake > Senior Software Engineer; WSO2 Inc. http://wso2.com/ > Blog : http://sureshatt.blogspot.com/ > Web : http://www.ssoarcade.com/ > Facebook : https://www.facebook.com/IdentityWorld > Twitter : https://twitter.com/sureshatt > LinkedIn : http://lk.linkedin.com/in/sureshatt > Mobile : +94755012060 > Mobile : +016166171172 > -- Indika Sampath Software Engineer WSO2 Inc. http://wso2.com Phone: +94 716 424 744 Blog: http://indikasampath.blogspot.com/
_______________________________________________ Dev mailing list Dev@wso2.org http://wso2.org/cgi-bin/mailman/listinfo/dev
