On Thu, Jul 24, 2014 at 1:00 PM, Sriskandarajah Suhothayan <[email protected]> wrote:
> > > > On Thu, Jul 24, 2014 at 12:23 PM, Chamil Jeewantha <[email protected]> > wrote: > >> >> >> >> 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. >> > No. I meant the server endpoints, E.g BAM or CEP > Do we have any difference between BAM and CEP regarding data publishing? Doesn't this represent by the URL field of the stream configuration (URL/PORT is different for those two products)? Why we need to externally configure whether its BAM or CEP? I think there is no problem to define per stream config entries in the config file. We may put the stream definition in to the same config as a CDATA field (in case annotations are not preferred) as well. Another alternative is we can have, entry per Server (BAM/CEP), Within Server we define multiple streams. This will give the chance of enable/disable per stream level or server level. WDYT? <analytics> <analyticServer> <enabled>true</enabled> <url></url> <protocol></protocol> <streams> <stream id="id"> <enabled>true</enabled> <definition><![CDATA[ --------- The Stream Definition------- ]]></definition> </stream> <stream> <enabled>false</enabled> </stream> </streams> </analyticServer> </analytics> > >>> >>>> 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? >> > > +1 for trying it out as an intern project or having it as a convenient > option, but we cant standardise this without a proper performance test > >> >>> 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 >> >> > > > -- > > *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
