Hi

IMHO we should not restrict data publishing to WSO2 BAM and CEP, and our
servers should be able to publish other analytic servers as well. So I
believe adding the PublisherClass will be a good option and this can be an
optional field.

Regards
Suho


On Tue, Jul 22, 2014 at 8:50 PM, Anjana Fernando <[email protected]> wrote:

> Hi Sagara,
>
> Maybe we can have "default" publisher that will be used by the products if
> a specific id is not given, and if needed, clients can give a specific ID,
> as you said, if we have separate BAM and CEP servers and so on. And we
> should not have "datasSourceName", it's a implementation specific property
> for how someone does analytics, and shouldn't be part of the publisher
> config. And also, I'm not sure what this "PublisherClass" is, we shouldn't
> have that, I guess it's a APIM specific thing.
>
> Cheers,
> Anjana.
>
>
> On Tue, Jul 22, 2014 at 11:16 AM, Sagara Gunathunga <[email protected]>
> wrote:
>
>>
>> Please find draft format for analytics.xml or event-publisher-config.xml.
>>
>> <event-publisher-config>
>> <publisher>
>>  <id>bam</id>
>> <enabled>true</enabled>
>> <protocol>thrift</protocol>
>>  <serverURL>tcp://<BAM host IP>:7614/</serverURL>
>> <username>admin</username>
>>  <password>admin</password>
>> <dataSourceName>jdbc/WSO2AM_STATS_DB</dataSourceName>
>>  <publisher>
>> <event-publisher-config>
>>
>> - It is possible to uniquely refer each "publisher" from product specific
>> configurations such as mediator, Valve etc.
>>
>> - In a given product it is possible to configure both CEP and BAM servers
>> separately ( or two BAM/CEP servers)
>>
>> - As we host dashboards with each product now I included <dataSourceName>
>> to refer stat database.
>>
>> - API-M uses "PublisherClass" class to refer publisher implementation
>> class, if same thing possible with all products we can add
>> "<PublisherClass"> element too.
>>
>>
>> Please suggest additions and removals for above format ?
>>
>> @Maninda, Can you please elaborate more on where do we
>> configure Publisher throttling constraints today and current format ? may
>> be we can leverage those settings as well.
>>
>> Thanks !
>>
>>
>>
>>
>>
>> On Tue, Jul 22, 2014 at 7:44 PM, Anjana Fernando <[email protected]> wrote:
>>
>>> 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
>>>
>>
>>
>>
>> --
>> 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
>



-- 

*S. Suhothayan*
Technical Lead & Team Lead of WSO2 Complex Event Processor
 *WSO2 Inc. *http://wso2.com
* <http://wso2.com/>*
lean . enterprise . middleware


*cell: (+94) 779 756 757 | blog: http://suhothayan.blogspot.com/
<http://suhothayan.blogspot.com/>twitter: http://twitter.com/suhothayan
<http://twitter.com/suhothayan> | linked-in:
http://lk.linkedin.com/in/suhothayan <http://lk.linkedin.com/in/suhothayan>*
_______________________________________________
Architecture mailing list
[email protected]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Reply via email to