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. 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. - Not every product will have features to support Jaggery applications. 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. 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
