Now, since this is just to contain the publisher information, shouldn't it
be something like "event-publisher-config.xml"? .. when we say
"analytics.xml", it gives an idea like it's a configuration for whole of
analytics operations, like a config for some analyzing operation settings.
Anyways, this will just contain the settings required to connect to an
event receiver, that is the hosts, the secure/non-secure ports etc.. After
this, we can create an OSGi service, which will expose an API to just
create a DataPublisher for you.

Cheers,
Anjana.


On Tue, Jul 22, 2014 at 6:26 AM, Sagara Gunathunga <[email protected]> wrote:

>
>
>
> On Tue, Jul 22, 2014 at 2:06 PM, Afkham Azeez <[email protected]> wrote:
>
>> analytics.xml seems like a better name.
>>
>
> +1
>
>>
>>
>> On Tue, Jul 22, 2014 at 1:51 PM, Srinath Perera <[email protected]> wrote:
>>
>>> These events can go to BAM or CEP.
>>>
>>> Shall we go with analytics.xml file instead of a bam.xml file? Sagara,
>>> can you send the content for current bam.xml file to this thread so we can
>>> finalise the content.
>>>
>>
> Current bam.xml files is only used with AS and contains following two
> lines to control AS service/web-app stat publishing in global level.
>
> <WebappDataPublishing>disable</WebappDataPublishing>
> <ServiceDataPublishing>disable</ServiceDataPublishing>
>
> I will send draft design for new analytics.xml file soon.
>
> Thanks !
>
>
>
>>
>>> that will mean BPS, ESB, API-M needs to fix this (may be with BAM
>>> toolbox improvements). Also, when decided Shammi, MB training project needs
>>> to use this too.
>>>
>>> WDYT?
>>>
>>> --Srinath
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Tue, Jul 22, 2014 at 1:43 PM, Afkham Azeez <[email protected]> wrote:
>>>
>>>> The correct approach is to introduce a bam.xml config. BAM is optional,
>>>> hence we should avoid BAM specific configs to the carbon.xml.
>>>>
>>>> Azeez
>>>>
>>>>
>>>> On Mon, Jul 21, 2014 at 9:52 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
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> *Afkham Azeez*
>>>> Director of Architecture; WSO2, Inc.; http://wso2.com
>>>> Member; Apache Software Foundation; http://www.apache.org/
>>>> * <http://www.apache.org/>*
>>>> *email: **[email protected]* <[email protected]>
>>>> * cell: +94 77 3320919 <%2B94%2077%203320919> blog: *
>>>> *http://blog.afkham.org* <http://blog.afkham.org>
>>>> *twitter: **http://twitter.com/afkham_azeez*
>>>> <http://twitter.com/afkham_azeez>
>>>> * linked-in: **http://lk.linkedin.com/in/afkhamazeez
>>>> <http://lk.linkedin.com/in/afkhamazeez>*
>>>>
>>>> *Lean . Enterprise . Middleware*
>>>>
>>>
>>>
>>>
>>> --
>>> ============================
>>> Director, Research, WSO2 Inc.
>>> Visiting Faculty, University of Moratuwa
>>> Member, Apache Software Foundation
>>> Research Scientist, Lanka Software Foundation
>>> Blog: http://srinathsview.blogspot.com twitter:@srinath_perera
>>> Site: http://people.apache.org/~hemapani/
>>> Photos: http://www.flickr.com/photos/hemapani/
>>> Phone: 0772360902
>>>
>>
>>
>>
>> --
>> *Afkham Azeez*
>> Director of Architecture; WSO2, Inc.; http://wso2.com
>> Member; Apache Software Foundation; http://www.apache.org/
>> * <http://www.apache.org/>*
>> *email: **[email protected]* <[email protected]>
>> * cell: +94 77 3320919 <%2B94%2077%203320919> blog: *
>> *http://blog.afkham.org* <http://blog.afkham.org>
>> *twitter: **http://twitter.com/afkham_azeez*
>> <http://twitter.com/afkham_azeez>
>> * linked-in: **http://lk.linkedin.com/in/afkhamazeez
>> <http://lk.linkedin.com/in/afkhamazeez>*
>>
>> *Lean . Enterprise . Middleware*
>>
>
>
>
> --
> 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
>
>


-- 
*Anjana Fernando*
Senior Technical Lead
WSO2 Inc. | http://wso2.com
lean . enterprise . middleware
_______________________________________________
Architecture mailing list
[email protected]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Reply via email to