On Thu, Jul 24, 2014 at 11:42 AM, Sriskandarajah Suhothayan <[email protected]> wrote:
> > > > On Thu, Jul 24, 2014 at 11:31 AM, Chamil Jeewantha <[email protected]> > wrote: > >> 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 >> > +1 > > 2. We should consider the Data streams as similar to the databases in >> master-datasources.xml >> > -1 no Streams are like tables and stream-endpoints are like databases, > hence Sagara's suggested xml is more suitable. > Is it rest endpoint, thrift endpoint etc... you meant by Stream-endpoint? If so, yes We can have the protocol as a field. The publisher will take care of the endpoint. AFAIK, Only streams with thrift are considered when publishing stat to BAM/CEP till now in wso2 products. > > >> 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. >> > So what about the stream definition ? > I am thinking the definition can be generated using the POJO annotations. Its one time task hence no serious performance impact. > > >> 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. >> >> -1 this should not be BAM specific, what about sending events to CEP? > Srinath's suggestion for the name is more suitable. > Agreed considering the CEP. > >> 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 >> >> } >> > This is just a easy way of sending the data (for customers/extensions), > but this should not be the standard within WSO2 components as it will be > inefficient and will introduce performance degradation. > I know this is a performance sensitive context. But there are many ways of improving annotation performance. i.e. caching annotation details at the load time etc... Before just saying this is performance killer, We have to see how much the performance impact. I think this is worth implementing as an Intern project. WDYT? > > Regards > Suho > > >> 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 >> >> > > > -- > > *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>* > -- 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
