Hi All,

Sorry if I am distracting the thread.

The important facts when designing this solution:

1. It should be similar looking of  master-datasources.xml
2. We should consider the Data streams as similar to the databases in
master-datasources.xml
3. Like we have separate entries in master-datasources.xml per database, We
should have a config entry per each stream.
4. The streamId is the property that should be referred by the code.
5. The stream name, version, url, username, password, enable/disable,
description should be the parameters per entry.
6. There can be one global enable/disable field for entire file to disable
all the bam stream publishes.
7. The name bam-streams.xml (like master-datasources.xml) seems better for
me.


How the streams are accessed from the code?

There should be a publisher OSGI Service with a method "publish" which
accepts an annotated POJO. This service will read the bam-streams.xml and
do the work accordingly.

example:

@Stream(id="monitoring.connector)
public class ConnectorMonitoringEvent{

    private long timestamp;

    @Column(name = "catalinaConnectorName", order = 2)
    private String connectorName;

    @Column(name = "connectorId", order = 1, type = DataType.STRING)
    private int id;

    //getters & setters

}

calling the OSGI Service:

ConnectorMonitoringEvent event = new ConnectorMonitoringEvent();
PublisherHolder.getPublisher().publish(event);    // PublisherHolder is a
service component which listen to BAM Publisher osgi service.


For the BAM based AS monitoring solution I have used the following XML
configuration. The file is repository/conf/etc/bam-publisher.xml. Its here
just as an example for what I'm talking about.

<?xml version="1.0" encoding="UTF-8" ?>
<bamPublisher>
    <streams>
        <stream id="monitoring.connector">
            <enabled>true</enabled>
            <streamName>monitoring.connector</streamName>
            <nickName>BAM.Monitoring.Connector.Publisher</nickName>
            <streamVersion>0.0.1</streamVersion>
            <username>admin</username>
            <password>admin</password>
            <receiverUrl>ssl://localhost:7711</receiverUrl>
            <description>Connector details are published to this
stream</description>
        </stream>
        <stream id="monitoring.webapp.resource">
            <enabled>true</enabled>
            <streamName>monitoring.webapp.resource</streamName>
            <nickName>BAM.Monitoring.WebApp.Resource.Publisher</nickName>
            <streamVersion>0.0.2</streamVersion>
            <username>admin</username>
            <password>admin</password>
            <receiverUrl>ssl://localhost:7711</receiverUrl>
            <description>Webapp Resource details are published to this
stream</description>
        </stream>
        <stream id="monitoring.webapp.calls">
            <enabled>true</enabled>
            <streamName>monitoring.webapp.calls</streamName>
            <nickName>BAM.Monitoring.WebApp.Calls.Publisher</nickName>
            <streamVersion>0.0.1</streamVersion>
            <username>admin</username>
            <password>admin</password>
            <receiverUrl>ssl://localhost:7711</receiverUrl>
            <description>Webapp Call details are published to this
stream</description>
        </stream>
    </streams>
</bamPublisher>


On Thu, Jul 24, 2014 at 7:28 AM, Nuwan Bandara <[email protected]> wrote:

>
>
>
> On Wed, Jul 23, 2014 at 1:43 AM, Lasantha Fernando <[email protected]>
> wrote:
>
>> Hi all,
>>
>>
>> On 23 July 2014 11:07, Sagara Gunathunga <[email protected]> wrote:
>>
>>>
>>>
>>>
>>> On Wed, Jul 23, 2014 at 10:43 AM, Sriskandarajah Suhothayan <
>>> [email protected]> wrote:
>>>
>>>>
>>>>
>>>>
>>>> On Wed, Jul 23, 2014 at 10:41 AM, Sriskandarajah Suhothayan <
>>>> [email protected]> wrote:
>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Wed, Jul 23, 2014 at 9:32 AM, Srinath Perera <[email protected]>
>>>>> wrote:
>>>>>
>>>>>> How about event-pulblisher.xml? I think we do not put config to our
>>>>>> config files usually? Need to be consistent about this.
>>>>>> +1 Giving and id for each publisher and a default
>>>>>>
>>>>>> +1
>>>>>
>>>>>
>>>>>>  As Anjana said dataSourceName name should not be here.
>>>>>> Shall we add a publisher class when a customer asks for it?
>>>>>>
>>>>> I'm ok with that, but the proper abstractions should be available in
>>>> the implementation to handle this.
>>>>
>>>
>>>  +1 I'm agree with Suho. Unless we have a proper design and exact idea
>>> how to support this we can't add it easily in future when ever customers
>>> demand for this. Other important thing is API-M is already done this
>>> abstraction and one step ahead so where they define publisher class ? Since
>>> this is a publisher related concern I don't think spreading publisher
>>> configuration into two files ( event-pulblisher.xml and api-manger.xml)
>>> is a good idea.
>>>
>>> Why don't we make this an optional element  ? product already support
>>> for above abstraction can use this element while others can ignore it for
>>> the time being.
>>>
>>
>>
>> Had a look at the publisher class of API manager and it seems to be quite
>> specific to APIM. It implements
>> org.wso2.carbon.apimgt.usage.publisher.APIMgtUsageDataPublisher which seems
>> to be specific to APIM.
>>
>> If we are planning to let each product implement their own publisher as
>> an option, I think it is better if we create the proper
>> interfaces/abstractions now itself. The interface used by APIM does not
>> seem to be generic enough to be used by other products IMHO. So +1 to get
>> the proper abstractions in place for the publisher class.
>>
>
> +1,
>
> The type of things being published is deferent from the product to product
> so letting each product defining the publisher class is sensible.
>
> Regards,
> /Nuwan
>
>
>>
>> Thanks,
>> Lasantha
>>
>>
>>> Thanks !
>>>
>>>>
>>>>
>>>>>> +1 to create an OSGI service to find the current publisher. (Nandika
>>>>>> also proposed this yesterday).
>>>>>>
>>>>>> --Srinath
>>>>>>
>>>>>>
>>>>>> On Tue, Jul 22, 2014 at 11:07 PM, Sriskandarajah Suhothayan <
>>>>>> [email protected]> wrote:
>>>>>>
>>>>>>> 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 <%28%2B94%29%20779%20756%20757> | 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>*
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> ============================
>>>>>> 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
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>>
>>>>> *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 <%28%2B94%29%20779%20756%20757> | 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>*
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>>
>>>> *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 <%28%2B94%29%20779%20756%20757> | 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>*
>>>>
>>>
>>>
>>>
>>> --
>>> 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
>>>
>>>
>>
>>
>> --
>> *Lasantha Fernando*
>> Software Engineer - Data Technologies Team
>> WSO2 Inc. http://wso2.com
>>
>> email: [email protected]
>> mobile: (+94) 71 5247551
>>
>> _______________________________________________
>> 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
>
>


-- 
K.D. Chamil Jeewantha
Associate Technical Lead
WSO2, Inc.;  http://wso2.com
Mobile: +94716813892
_______________________________________________
Architecture mailing list
[email protected]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Reply via email to