Hi Sagara, Thanks a lot for your valuable suggestions. Those are certainly worth much more than 2 cents! :)
Regarding Rest API, I know Carbon Kernel supports webapp deployment and I was just thinking about using the Apache CXF runtime provided from the AS features. I just had a concern of including all CXF dependencies in a webapp as it will increase the app size. Regarding security, I am aware of the standard filters & interceptors available in the CXF and I can use CarbonContext APIs to authenticate. My biggest concern is handling security from the UI application. I already looked at API Manager, APP Manager Jaggery applications and one of my concerns is that those apps use different ways to authenticate. Most of the security handling logic is a core part of the application and that is why I said that there is no standard way of securing app. If I also need to secure a Jaggery application, I will have to copy some code and maintain. Other concern is that all these additional features require more dependencies and the products get more bulkier. I'm more than willing to use newer technologies and develop a more rich UI. As I mentioned, I'm thinking of using Carbon UI components for the "initial version" only. For next versions, I will consider all these improvements. Right now, I'm bit tight on schedule and I have to develop the UI soon. I'm targeting the UI for the Message Broker first and bringing the mentioned dependencies will take more time and it may have an impact on MB release. Thanks again for your inputs and I will think again on the development approach for Metrics UI. Best Regards, On Tue, Mar 17, 2015 at 10:22 PM, Sagara Gunathunga <sag...@wso2.com> wrote: > > > On Tue, Mar 17, 2015 at 6:36 PM, Isuru Perera <isu...@wso2.com> wrote: > >> Thanks Chanaka! I had a chat with Sameera also. >> >> For the initial version, we will develop Metrics Visualization as a >> Carbon UI component. The backend will also be a standard Web Service and >> the UI component will communicate with backend via a Stub. (This is the >> usual way of developing Carbon Components). I will see how I can avoid >> conflicts in jQuery etc. >> >> Following are the reasons (in summary) >> >> Reasons to drop Rest API: >> >> - No standard way of securing REST APIs within Carbon Kernel. If we >> have to support OAuth, we need to bring in additional features etc. >> - Apache CXF support is not available in Carbon Kernel. Not every >> product will have webapp management features, which will provide Apache >> CXF >> runtime. >> >> Did you mean we have products without admin console ? Admin console is a > web application, if the product contains admin console means product has > the capability to deploy any web application, you may have to change the > deployment approach. > > It's not necessary to have CXF runtime to deploy CXF applications you only > need Carbon runtime, just embed required CXF dependencies in side the web > application, only concern is app size become bit high but that's not an big > issue. > > In case if you decided to write CXF services, there are 2 standard > approach to provide security, either write JAX-RS Filter[1] or CXF > Interceptor ( + Validator) [2] in both cases within your implementation you > can call Carbon APIs to perform authentication. [ There is a simple JSP > sample available with AS to illustrate Carbon APIs) > > >> Reason to drop the idea of using a separate webapp. >> >> - No standard way of securing the webapp. Applications implement its >> own logic to secure. SSO requires additional features. >> >> In fact there is no single spec for web apps hence there is no standard > to secure web apps, please refer above mentioned sample how to call Carbon > APIs using JSP, in case if you decided to follow JSP you can use similar > approach. Also for SAML SSO you just need Opensaml as a dependency inside > the web app, also check with IS team AFAIR their SSO proxy also optimized > to work with less number of dependencies. > > AFAIK writing new applications through Carbon UIs is not recommended, if > you look at recently developed dashboards, store/publisher applications > those are developed and deploying as web applications. In my POV you are > making lot of UI limitations by using Carbon UIs. > > >> >> - >> - Not every product will have features to support Jaggery >> applications. >> >> I think this is just matter of time, Jaggery is developed to implement > rich UIs for WSO2 products and we should use it for same purpose. > >> The metrics components need to be simple and easy to install. For >> example, the first product integrating Metrics, WSO2 Message Broker doesn't >> support Apache CXF runtime or Jaggery runtime by default. If Metrics UI is >> a set of standard Carbon components, it'll be easy for the products to use. >> > As this is a new application and targeting visualization we should much > focus on UX aspect and i don't think Carbon UIs and admin services are > close to such rich experience, just my 2 cents :) > > [1] - http://svn.apache.org/repos/asf/cxf/trunk/rt/rs/security/ > [2] - > https://github.com/coheigea/testcases/tree/master/apache/cxf/cxf-syncope/src/test/java/org/apache/coheigea/cxf/syncope/authentication > > Thanks ! > >> Thanks! >> >> Best Regards, >> >> On Tue, Mar 17, 2015 at 4:51 PM, Chanaka Jayasena <chan...@wso2.com> >> wrote: >> >>> As discussed offline. There are pros and cons in both approaches. If you >>> provide this feature as a Carbon component, you will have to work with the >>> old jQuery version married to the ui.core. Since your UI is going to be >>> rich with widgets and charts, there is a possibility to run in to >>> conflicts. But you can also try to name your files in the component end >>> with _ajaxprocessor.jsp and not let the Carbon default template and >>> libraries load. With this approach AFAIK you can inherit the security and >>> avoid the possibility of conflicts. Having a weird file name will be a con >>> in this approach. >>> >>> If you create a separate jaggery web app, of cause you will have to deal >>> with authentication. Since our new UI framework is there, please try to use >>> that in your development [1]. >>> >>> 1 - https://github.com/manuranga/fuse >>> >>> thanks, >>> Chanaka >>> >>> On Mon, Mar 16, 2015 at 2:06 PM, Isuru Perera <isu...@wso2.com> wrote: >>> >>>> Hi all, >>>> >>>> I'm working on a simple UI for Metrics visualization. Few days back, we >>>> released the first version of WSO2 Carbon Metrics [1], which can send >>>> output to CSV files, database via JDBC & JMX. >>>> >>>> For the Metric Visualization, we will be using the data from database. >>>> Hence the UI application will be tightly coupled with JDBC and JDBC >>>> reporting must be enabled. >>>> >>>> *User Stories* >>>> >>>> As a user, I want to: >>>> >>>> - view metrics data in a timeseries chart with a configurable time >>>> period. >>>> - compare different metrics. >>>> - compare metrics from multiple sources. >>>> - save the charts and display those later. >>>> >>>> I will send the UI Wire-frames soon. >>>> *Main Components* >>>> >>>> - REST API - This will be an Apache CXF application. The REST APIs >>>> will get the data via JDBC. The responses will be in JSON format. >>>> - Metrics UI - This is the main dashboard, which will get data from >>>> REST APIs. Metrics UI needs server side processing for loading/storing >>>> dashboards etc. Hence the application can be developed as a Carbon UI >>>> component or a Jaggery application. The IGViz library [2] will be used >>>> for >>>> charts. >>>> >>>> >>>> *Concerns* >>>> >>>> Both REST API and Metrics UI need authentication & authorization. I >>>> haven't decided the best way to authenticate REST APIs in Apache CXF >>>> application. Any suggestions? >>>> >>>> For Metrics UI, we need a login page. As I have seen from other >>>> applications, if we use Jaggery, we need to create separate login pages and >>>> manage security within the application. For example, API Manager Jaggery >>>> applications have implemented login pages. The APP Manager uses SSO for >>>> login. In order to use SSO, we need to use additional Identity Server >>>> features. >>>> >>>> If we create Metrics UI as a Carbon UI Component, we don't have to >>>> worry about securing the application and we can use existing authorization >>>> mechanisms for Carbon UI components. >>>> >>>> Since Metrics UI is a simple application, I think a Carbon UI component >>>> approach might be better than creating a separate application in Jaggery. >>>> >>>> Please let me know any suggestions/feedback. >>>> >>>> Thanks! >>>> >>>> [1] https://github.com/wso2/carbon-metrics/tree/v1.0.0 >>>> [2] http://mail.wso2.org/mailarchive/dev/2015-March/044631.html >>>> >>>> -- >>>> Isuru Perera >>>> Senior Software Engineer | WSO2, Inc. | http://wso2.com/ >>>> Lean . Enterprise . Middleware >>>> >>>> about.me/chrishantha >>>> >>> >>> >>> >>> -- >>> Chanaka Jayasena >>> Senior Software Engineer; WSO2, Inc.; http://wso2.com/ >>> email: chan...@wso2.com; cell: +94 77 785 5565 >>> blog: http://chanaka3d.blogspot.com >>> >> >> >> >> -- >> Isuru Perera >> Senior Software Engineer | WSO2, Inc. | http://wso2.com/ >> Lean . Enterprise . Middleware >> >> about.me/chrishantha >> >> _______________________________________________ >> Architecture mailing list >> Architecture@wso2.org >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > > > -- > Sagara Gunathunga > > Senior Technical Lead; WSO2, Inc.; http://wso2.com > V.P Apache Web Services; http://ws.apache.org/ > Linkedin; http://www.linkedin.com/in/ssagara > Blog ; http://ssagara.blogspot.com > > -- Isuru Perera Senior Software Engineer | WSO2, Inc. | http://wso2.com/ Lean . Enterprise . Middleware about.me/chrishantha
_______________________________________________ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
