On Tue, Mar 17, 2015 at 6:36 PM, Isuru Perera <[email protected]> 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 <[email protected]> > 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 <[email protected]> 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: [email protected]; 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 > [email protected] > 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
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
