+1 for having unified publisher carbon component. How about define data publisher source in the same way we do for data sources. Then in product level we need to provide publisher source(ex when configure stats through config). So each component might able to do JNDI look up for publisher source and publish events to it(in APIM stats component, In ESB mediation stats component). WDYT?
Thanks, sanjeewa. On Mon, Jul 21, 2014 at 9:58 AM, Nuwan Bandara <[email protected]> wrote: > Right now API-M is the biggest customer from BAM, mainly because people > need API statistics and also API-M is quite easy to configure with BAM. +1 > for having a unified statistics publishing component at carbon level. We > have a growing interest in knowing stats for ESB/AS//BPS/MB so +1 for > having a common component. > > Having said that each product has different analytics use-cases, in API-M > people need to see API stats, in ESB mediation stats / TPSes / Latency etc, > in MB number of queues / topics / consumer throughput etc. So what we want > is not just a server stats publishing component. IMO there should be away > to customize this based on the product too. Maybe the server publishers > everything, and we have different toolboxes and execution plans in BAM and > CEP side. > > Regards, > /Nuwan > > > On Mon, Jul 21, 2014 at 12:22 PM, Sagara Gunathunga <[email protected]> > wrote: > >> >> Right now each of our product use it's own way to define BAM server >> profiles, it would be nice if we can follow an unified process when >> configuring BAM servers and to enable/disable server level data publishing. >> FYI these are some of the approaches used by our products. >> >> >> ESB - Through BAM server profile UI and no configuration file. >> >> AS - Use bam.xml to enable disable server level data publishing and >> Webapp/Service Data Publishing UI for server configuration. >> >> >> BPS - Through bps.xml and writing a BAMServerProfile.xml file. >> >> API-M - Through api-manager.xml file. >> >> >> >> IMHO we can unified this process among all the servers up to some extend, >> as an example >> >> 1. Configuring BAM server details - urls, user name, password >> 2. Globally enable and disable data publishing >> 3. Name of the stat database >> 4. Publishing protocol and it's configuration >> >> I have two suggestion on this. >> >> >> a.) As BAM publishing is common for most of the product define new >> element called <Analytic> under carbon.xml to hold above common >> configurations. >> >> b.) Alternatively define bam.xml file to hold above common >> configurations. >> >> >> WDYT ? >> >> >> NOTE - I only considered BAM but I guess we can consider CEP as well. >> >> >> Thanks ! >> -- >> 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 >> >> > > > -- > > > *Thanks & Regards,* > * Nuwan Bandara | Senior Technical Lead - Solutions Architecture, WSO2 > Inc.+1 812.606.7390 <%2B1%20812.606.7390> | +1 650.745.4499 Ext 4210 > <%2B1%20650.745.4499%20Ext%204210> | http://nuwanbando.com > <http://nuwanbando.com> * <http://www.nuwanbando.com/> > > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- *Sanjeewa Malalgoda* WSO2 Inc. Mobile : +94713068779 <http://sanjeewamalalgoda.blogspot.com/>blog :http://sanjeewamalalgoda.blogspot.com/ <http://sanjeewamalalgoda.blogspot.com/>
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
