+1 for unified publisher strategy with a "Publisher Source". Then we can unify for whatever the external data publisher from that component which may even be different from our BAM or CEP. There we have to define,
1. Publisher name : Unique name for the publisher 2. Publisher URL : contains protocol, host and port. Should be able to enter load balancing URLs and fail over URLs. 3. Credentials : Username/Password or Access tokens which can be encrypted with secure vault 4. Publisher throttling constraints : Maximum message size, maximum publisher throughput, publisher queue sizes, message timeouts etc. which we currently do in a separate configuration locations. And also we can make this data publisher source, a deployable artifact as the data sources which enables the configuration to be given from the CApp directly. *Maninda Edirisooriya* Senior Software Engineer *WSO2, Inc.*lean.enterprise.middleware. *Blog* : http://maninda.blogspot.com/ *E-mail* : [email protected] *Skype* : @manindae *Twitter* : @maninda On Tue, Jul 22, 2014 at 12:41 AM, Sanjeewa Malalgoda <[email protected]> wrote: > +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 > >
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
