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 > >> >>> 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 | 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
