Re: [Architecture] [C5][APIM] - Publishing API events to gateway via JMS Topic

2017-04-26 Thread Thilini Shanika
Hi Manoj,

Please find my comments inline.

Fetching new apis from APIM core do via database call or REST api?

We are providing a set of REST apis (in API core) for ballerina gateways to
access and fetch API conf, subscription details etc. Following diagram
depicts how the communication happens in between the APIM core, the
gateway, and the broker.

​

I think, we have to think about time to fetch all apis and starting time of
a node. If num of apis increases, the startup time of a node may increase.
This may critical for a containerized environments.
We found some production instances which has around 1000 apis.

Yes. As per the new design, there is a plan of deploying APIs on demand and
this will eliminate the overhead of API deployment delays at server
startup.

On Thu, Apr 27, 2017 at 9:58 AM, Manoj Gunawardena  wrote:

> Fetching new apis from APIM core do via database call or REST api?
> I think, we have to think about time to fetch all apis and starting time
> of a node. If num of apis increases, the startup time of a node may
> increase.
> This may critical for a containerized environments.
> We found some production instances which has around 1000 apis.
>
> On Wed, Apr 26, 2017 at 1:56 PM, Sanjeewa Malalgoda 
> wrote:
>
>> In fully automated containerized environment can we assume we can see
>> node restarts. As i understood nodes come and go(each time we require we
>> start new instance and when its not in use it will terminate). In such
>> scenario having durable subscription or persisting data to local node do
>> not make much difference.
>>
>> But if we are thinking of traditional deployment then we may be able to
>> restart instances and reuse them.
>> @Lakmal, Pubudu any thoughts?
>>
>> Thanks,
>> sanjeewa.
>>
>> On Wed, Apr 26, 2017 at 11:34 AM, Pubudu Gunatilaka 
>> wrote:
>>
>>> On Wed, Apr 26, 2017 at 11:02 AM, Lakmal Warusawithana 
>>> wrote:
>>>


 On Wed, Apr 26, 2017 at 10:51 AM, Manoj Gunawardena 
 wrote:

> Are we going to use durable subscription here? When ever gw node down
> and re start,
> it should fetch messages which add to the topic during the down time.
> In case durable subscription what is the mechanism to create client id
> for each gw.Is that discussed and confirm?
>

 No, we are not going to use durable topic. New gateways (scaling) or if
 we restart a gateway, existing APIs will fetch via API Manager core. Only
 new API (after boot up) notifications are getting via the topic and actual
 API will fetch from the core. ( we can try what sanjeewa mention - getting
 API from the topic - but previous APIs need to fetch from the core)


>>>
>>> When we restart a gateway node, it would be better to fetch only the
>>> updated APIs as well as the new APIs. Restarted gateway has the already
>>> fetched APIs and it is not worth to fetch all the APIs again. We will have
>>> to use durable subscription for this.
>>>
>>> If we consider the container scenario, are we persisting gateway
>>> artifacts? If we are not persisting gateway artifacts and restart the
>>> gateway container, then we need to fetch all the APIs from the core. IMHO
>>> it would better to persist data and load that data at restart as it would
>>> take time to fetch all the APIs from the core.
>>>
>>> Thank you!
>>> --
>>> *Pubudu Gunatilaka*
>>> Committer and PMC Member - Apache Stratos
>>> Software Engineer
>>> WSO2, Inc.: http://wso2.com
>>> mobile : +94774078049 <%2B94772207163>
>>>
>>>
>>> ___
>>> Architecture mailing list
>>> Architecture@wso2.org
>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>
>>>
>>
>>
>> --
>>
>> *Sanjeewa Malalgoda*
>> WSO2 Inc.
>> Mobile : +94713068779 <+94%2071%20306%208779>
>>
>> blog
>> :http://sanjeewamalalgoda.blogspot.com/
>> 
>>
>>
>>
>> ___
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
>
> --
> Manoj Gunawardena
> Tech Lead
> WSO2, Inc.: http://wso2.com
> lean.enterprise.middleware
> Mobile : +94 77 2291643
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 
Thilini Shanika
Senior Software Engineer
WSO2, Inc.; http://wso2.com
20, Palmgrove Avenue, Colombo 3

E-mail: tgtshan...@gmail.com
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture


Re: [Architecture] [C5][APIM] - Publishing API events to gateway via JMS Topic

2017-04-26 Thread Manoj Gunawardena
Fetching new apis from APIM core do via database call or REST api?
I think, we have to think about time to fetch all apis and starting time of
a node. If num of apis increases, the startup time of a node may increase.
This may critical for a containerized environments.
We found some production instances which has around 1000 apis.

On Wed, Apr 26, 2017 at 1:56 PM, Sanjeewa Malalgoda 
wrote:

> In fully automated containerized environment can we assume we can see node
> restarts. As i understood nodes come and go(each time we require we start
> new instance and when its not in use it will terminate). In such scenario
> having durable subscription or persisting data to local node do not make
> much difference.
>
> But if we are thinking of traditional deployment then we may be able to
> restart instances and reuse them.
> @Lakmal, Pubudu any thoughts?
>
> Thanks,
> sanjeewa.
>
> On Wed, Apr 26, 2017 at 11:34 AM, Pubudu Gunatilaka 
> wrote:
>
>> On Wed, Apr 26, 2017 at 11:02 AM, Lakmal Warusawithana 
>> wrote:
>>
>>>
>>>
>>> On Wed, Apr 26, 2017 at 10:51 AM, Manoj Gunawardena 
>>> wrote:
>>>
 Are we going to use durable subscription here? When ever gw node down
 and re start,
 it should fetch messages which add to the topic during the down time.
 In case durable subscription what is the mechanism to create client id
 for each gw.Is that discussed and confirm?

>>>
>>> No, we are not going to use durable topic. New gateways (scaling) or if
>>> we restart a gateway, existing APIs will fetch via API Manager core. Only
>>> new API (after boot up) notifications are getting via the topic and actual
>>> API will fetch from the core. ( we can try what sanjeewa mention - getting
>>> API from the topic - but previous APIs need to fetch from the core)
>>>
>>>
>>
>> When we restart a gateway node, it would be better to fetch only the
>> updated APIs as well as the new APIs. Restarted gateway has the already
>> fetched APIs and it is not worth to fetch all the APIs again. We will have
>> to use durable subscription for this.
>>
>> If we consider the container scenario, are we persisting gateway
>> artifacts? If we are not persisting gateway artifacts and restart the
>> gateway container, then we need to fetch all the APIs from the core. IMHO
>> it would better to persist data and load that data at restart as it would
>> take time to fetch all the APIs from the core.
>>
>> Thank you!
>> --
>> *Pubudu Gunatilaka*
>> Committer and PMC Member - Apache Stratos
>> Software Engineer
>> WSO2, Inc.: http://wso2.com
>> mobile : +94774078049 <%2B94772207163>
>>
>>
>> ___
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
>
> --
>
> *Sanjeewa Malalgoda*
> WSO2 Inc.
> Mobile : +94713068779 <+94%2071%20306%208779>
>
> blog :http://sanjeewamalalgoda.
> blogspot.com/ 
>
>
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 
Manoj Gunawardena
Tech Lead
WSO2, Inc.: http://wso2.com
lean.enterprise.middleware
Mobile : +94 77 2291643
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture


Re: [Architecture] [C5][APIM] - Publishing API events to gateway via JMS Topic

2017-04-26 Thread Pubudu Gunatilaka
On Wed, Apr 26, 2017 at 1:11 PM, Lakmal Warusawithana 
wrote:

>
>
> On Wed, Apr 26, 2017 at 11:34 AM, Pubudu Gunatilaka 
> wrote:
>
>> On Wed, Apr 26, 2017 at 11:02 AM, Lakmal Warusawithana 
>> wrote:
>>
>>>
>>>
>>> On Wed, Apr 26, 2017 at 10:51 AM, Manoj Gunawardena 
>>> wrote:
>>>
 Are we going to use durable subscription here? When ever gw node down
 and re start,
 it should fetch messages which add to the topic during the down time.
 In case durable subscription what is the mechanism to create client id
 for each gw.Is that discussed and confirm?

>>>
>>> No, we are not going to use durable topic. New gateways (scaling) or if
>>> we restart a gateway, existing APIs will fetch via API Manager core. Only
>>> new API (after boot up) notifications are getting via the topic and actual
>>> API will fetch from the core. ( we can try what sanjeewa mention - getting
>>> API from the topic - but previous APIs need to fetch from the core)
>>>
>>>
>>
>> When we restart a gateway node, it would be better to fetch only the
>> updated APIs as well as the new APIs. Restarted gateway has the already
>> fetched APIs and it is not worth to fetch all the APIs again. We will have
>> to use durable subscription for this.
>>
>
> How often can gateway restart happen? In container wold no restarts but
> destroy and re-create.
>
>
I was refering to the VM scenario in this case. Restarts could occur when
we apply patches.


>
>> If we consider the container scenario, are we persisting gateway
>> artifacts? If we are not persisting gateway artifacts and restart the
>> gateway container, then we need to fetch all the APIs from the core. IMHO
>> it would better to persist data and load that data at restart as it would
>> take time to fetch all the APIs from the core.
>>
>
>
> IMO persisting give lots of management overheads. Better not to persist
> anything in the gateway. At the moment we thought not to write ballerina
> artifacts (apis) to disk, fetch it from the core and keep it in memory and
> pass to ballerina service apis to create services.
>
>

If we are keeping ballerina artifacts in memory, then we have to fetch all
the APIs from the core. Then we don't need durable subscriptions. As
pointed out during the offline discussion, we are now moving towards tenant
based deployments and there won't be higher number of APIs per tenant.
Also, APIs can be deployed per gateways.

Thank you!
-- 
*Pubudu Gunatilaka*
Committer and PMC Member - Apache Stratos
Software Engineer
WSO2, Inc.: http://wso2.com
mobile : +94774078049 <%2B94772207163>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture


Re: [Architecture] [C5][APIM] - Publishing API events to gateway via JMS Topic

2017-04-26 Thread Lakmal Warusawithana
On Wed, Apr 26, 2017 at 2:42 PM, Pubudu Gunatilaka  wrote:

>
> On Wed, Apr 26, 2017 at 1:11 PM, Lakmal Warusawithana 
> wrote:
>
>>
>>
>> On Wed, Apr 26, 2017 at 11:34 AM, Pubudu Gunatilaka 
>> wrote:
>>
>>> On Wed, Apr 26, 2017 at 11:02 AM, Lakmal Warusawithana 
>>> wrote:
>>>


 On Wed, Apr 26, 2017 at 10:51 AM, Manoj Gunawardena 
 wrote:

> Are we going to use durable subscription here? When ever gw node down
> and re start,
> it should fetch messages which add to the topic during the down time.
> In case durable subscription what is the mechanism to create client id
> for each gw.Is that discussed and confirm?
>

 No, we are not going to use durable topic. New gateways (scaling) or if
 we restart a gateway, existing APIs will fetch via API Manager core. Only
 new API (after boot up) notifications are getting via the topic and actual
 API will fetch from the core. ( we can try what sanjeewa mention - getting
 API from the topic - but previous APIs need to fetch from the core)


>>>
>>> When we restart a gateway node, it would be better to fetch only the
>>> updated APIs as well as the new APIs. Restarted gateway has the already
>>> fetched APIs and it is not worth to fetch all the APIs again. We will have
>>> to use durable subscription for this.
>>>
>>
>> How often can gateway restart happen? In container wold no restarts but
>> destroy and re-create.
>>
>>
> I was refering to the VM scenario in this case. Restarts could occur when
> we apply patches.
>

Even in VM deployments people are now using blue/green, canary software
updates not required restart IMO.


>
>>
>>> If we consider the container scenario, are we persisting gateway
>>> artifacts? If we are not persisting gateway artifacts and restart the
>>> gateway container, then we need to fetch all the APIs from the core. IMHO
>>> it would better to persist data and load that data at restart as it would
>>> take time to fetch all the APIs from the core.
>>>
>>
>>
>> IMO persisting give lots of management overheads. Better not to persist
>> anything in the gateway. At the moment we thought not to write ballerina
>> artifacts (apis) to disk, fetch it from the core and keep it in memory and
>> pass to ballerina service apis to create services.
>>
>>
>
> If we are keeping ballerina artifacts in memory, then we have to fetch all
> the APIs from the core. Then we don't need durable subscriptions. As
> pointed out during the offline discussion, we are now moving towards tenant
> based deployments and there won't be higher number of APIs per tenant.
> Also, APIs can be deployed per gateways.
>
> Thank you!
> --
> *Pubudu Gunatilaka*
> Committer and PMC Member - Apache Stratos
> Software Engineer
> WSO2, Inc.: http://wso2.com
> mobile : +94774078049 <%2B94772207163>
>
>


-- 
Lakmal Warusawithana
Director - Cloud Architecture; WSO2 Inc.
Mobile : +94714289692
Blogs : https://medium.com/@lakwarus/
http://lakmalsview.blogspot.com/
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture


Re: [Architecture] [C5][APIM] - Publishing API events to gateway via JMS Topic

2017-04-26 Thread Lakmal Warusawithana
On Wed, Apr 26, 2017 at 11:34 AM, Pubudu Gunatilaka 
wrote:

> On Wed, Apr 26, 2017 at 11:02 AM, Lakmal Warusawithana 
> wrote:
>
>>
>>
>> On Wed, Apr 26, 2017 at 10:51 AM, Manoj Gunawardena 
>> wrote:
>>
>>> Are we going to use durable subscription here? When ever gw node down
>>> and re start,
>>> it should fetch messages which add to the topic during the down time.
>>> In case durable subscription what is the mechanism to create client id
>>> for each gw.Is that discussed and confirm?
>>>
>>
>> No, we are not going to use durable topic. New gateways (scaling) or if
>> we restart a gateway, existing APIs will fetch via API Manager core. Only
>> new API (after boot up) notifications are getting via the topic and actual
>> API will fetch from the core. ( we can try what sanjeewa mention - getting
>> API from the topic - but previous APIs need to fetch from the core)
>>
>>
>
> When we restart a gateway node, it would be better to fetch only the
> updated APIs as well as the new APIs. Restarted gateway has the already
> fetched APIs and it is not worth to fetch all the APIs again. We will have
> to use durable subscription for this.
>

How often can gateway restart happen? In container wold no restarts but
destroy and re-create.


>
> If we consider the container scenario, are we persisting gateway
> artifacts? If we are not persisting gateway artifacts and restart the
> gateway container, then we need to fetch all the APIs from the core. IMHO
> it would better to persist data and load that data at restart as it would
> take time to fetch all the APIs from the core.
>


IMO persisting give lots of management overheads. Better not to persist
anything in the gateway. At the moment we thought not to write ballerina
artifacts (apis) to disk, fetch it from the core and keep it in memory and
pass to ballerina service apis to create services.


>
> Thank you!
> --
> *Pubudu Gunatilaka*
> Committer and PMC Member - Apache Stratos
> Software Engineer
> WSO2, Inc.: http://wso2.com
> mobile : +94774078049 <%2B94772207163>
>
>


-- 
Lakmal Warusawithana
Director - Cloud Architecture; WSO2 Inc.
Mobile : +94714289692
Blogs : https://medium.com/@lakwarus/
http://lakmalsview.blogspot.com/
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture


Re: [Architecture] Validate Authorization headers for Oauth endpoints

2017-04-26 Thread Johann Nallathamby
How about "/oauth2/introspect" endpoint?

On Wed, Apr 26, 2017 at 9:25 AM, Harsha Thirimanna  wrote:

> On Wed, Apr 26, 2017 at 9:07 AM, Asela Pathberiya  wrote:
>
>>
>>
>> On Tue, Apr 25, 2017 at 3:34 PM, Harsha Thirimanna 
>> wrote:
>>
>>>
>>>
>>> On Tue, Apr 25, 2017 at 3:04 PM, Asela Pathberiya 
>>> wrote:
>>>


 On Tue, Apr 25, 2017 at 2:52 PM, Harsha Thirimanna 
 wrote:

>
> On Tue, Apr 25, 2017 at 2:00 PM, Asela Pathberiya 
> wrote:
>
>>
>>
>> On Tue, Apr 25, 2017 at 12:44 PM, Harsha Thirimanna > > wrote:
>>
>>>
>>> On Tue, Apr 25, 2017 at 12:38 PM, Nuwan Dias 
>>> wrote:
>>>
 Hi Gayan,

 What are you trying to achieve by moving the client-secret
 validation logic to the interceptor from the jax-rs layer?

>>>
>>> ​Actually, we have separate layer to pass the secured API in IS and
>>> it is common service that can be used for any product. AppManager also
>>> using that.
>>> In here also Gayan is trying to get the security check into that
>>> common layer instead of allowing to go into the next level to validate
>>> headers.  ​
>>>
>>
>> Are we going to use common basic authentication handler  ?
>>
>
> ​This feature is already done in IS 5.3.0 as a common point to handle
> authentication and authorization per resources as in [1].​
>
> [1] http://harshathirimanna.blogspot.com/2016/11/authenticat
> ion-authorization-common.html
>
>>
>> BTW;  Client credentials can be received as url param..  Are we
>> validating them in here ?  If it is not;  Why are we introducing two
>> validation points for same ?
>>
>> ​If we have our own way to pass authentication details,​ then we have
> to write an authentication handler to that and register.
>

 This is according to the OAuth2 spec...  It meant that we need another
 handler implementation to do it or can we use existing authentication
 handler ?

>>>
>>> ​What i meant was that we can write custom handler as well to here. ​
>>>
>> Yes.  if it is;  it must be shipped by default.
>>
> ​Gayan will do that with this implementation. ​
>
>>
>>
>>>
>>>
>>>


>
>
>
>> Actually I do not see much use of changing the current validation
>> model.
>>
> ​This is for all the APIs in IS to handle authentication/authorization
> in common way​ and decouple it with implementation of each.
>

>
>
>>
>> Thanks,
>> Asela.
>>
>>
>>>
>>>
>>>
 Since both run on the same JVM, doesn't the overhead of the process
 remain the same, irrespective of where it runs?

 Thanks,
 NuwanD.

 On Tue, Apr 25, 2017 at 12:27 PM, Gayan Gunawardana  wrote:

> Hi All,
>
> In Oauth /token endpoint and /revoke endpoint
>
> https://localhost:9443/oauth2/token
> https://localhost:9443/oauth2/revoke
>
> required authorization with client key, client secret in basic
> auth headers. Currently in implementation we validate those headers 
> after
> serving request to JAX-RS endpoints. Basically /token, /revoke 
> endpoints
> are unsecured. There is significant amount of processing happen even 
> for
> wrong client secret.
>
> Since we have REST API  interceptor layer In IS 5.3.0  can we use
> it to validate client credentials ? We may need to plug an additional
> authenticator to validate client key, client secret in basic auth 
> headers.
> This authenticator may conflict with basic authenticator because
> both authenticators validate basic auth credentials different way. 
> There
> are two approaches to avoid the conflict.
>
> *#option 01 *
> Increase the priority of newly added authenticator and check the
> context inside authenticator canHandle.
>
> *#option 01 *
> Increase the priority of newly added authenticator and check
> existence of oauth application from client key.
>
> WDYT?
>
> --
> Gayan Gunawardana
> Software Engineer; WSO2 Inc.; http://wso2.com/
> Email: ga...@wso2.com
> Mobile: +94 (71) 8020933
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


 --
 Nuwan Dias

 Software Architect - WSO2, Inc. http://wso2.com
 

Re: [Architecture] [C5][APIM] - Publishing API events to gateway via JMS Topic

2017-04-26 Thread Sanjeewa Malalgoda
In fully automated containerized environment can we assume we can see node
restarts. As i understood nodes come and go(each time we require we start
new instance and when its not in use it will terminate). In such scenario
having durable subscription or persisting data to local node do not make
much difference.

But if we are thinking of traditional deployment then we may be able to
restart instances and reuse them.
@Lakmal, Pubudu any thoughts?

Thanks,
sanjeewa.

On Wed, Apr 26, 2017 at 11:34 AM, Pubudu Gunatilaka 
wrote:

> On Wed, Apr 26, 2017 at 11:02 AM, Lakmal Warusawithana 
> wrote:
>
>>
>>
>> On Wed, Apr 26, 2017 at 10:51 AM, Manoj Gunawardena 
>> wrote:
>>
>>> Are we going to use durable subscription here? When ever gw node down
>>> and re start,
>>> it should fetch messages which add to the topic during the down time.
>>> In case durable subscription what is the mechanism to create client id
>>> for each gw.Is that discussed and confirm?
>>>
>>
>> No, we are not going to use durable topic. New gateways (scaling) or if
>> we restart a gateway, existing APIs will fetch via API Manager core. Only
>> new API (after boot up) notifications are getting via the topic and actual
>> API will fetch from the core. ( we can try what sanjeewa mention - getting
>> API from the topic - but previous APIs need to fetch from the core)
>>
>>
>
> When we restart a gateway node, it would be better to fetch only the
> updated APIs as well as the new APIs. Restarted gateway has the already
> fetched APIs and it is not worth to fetch all the APIs again. We will have
> to use durable subscription for this.
>
> If we consider the container scenario, are we persisting gateway
> artifacts? If we are not persisting gateway artifacts and restart the
> gateway container, then we need to fetch all the APIs from the core. IMHO
> it would better to persist data and load that data at restart as it would
> take time to fetch all the APIs from the core.
>
> Thank you!
> --
> *Pubudu Gunatilaka*
> Committer and PMC Member - Apache Stratos
> Software Engineer
> WSO2, Inc.: http://wso2.com
> mobile : +94774078049 <%2B94772207163>
>
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 

*Sanjeewa Malalgoda*
WSO2 Inc.
Mobile : +94713068779

blog
:http://sanjeewamalalgoda.blogspot.com/

___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture


Re: [Architecture] [C5][APIM] - Publishing API events to gateway via JMS Topic

2017-04-26 Thread Pubudu Gunatilaka
On Wed, Apr 26, 2017 at 11:02 AM, Lakmal Warusawithana 
wrote:

>
>
> On Wed, Apr 26, 2017 at 10:51 AM, Manoj Gunawardena 
> wrote:
>
>> Are we going to use durable subscription here? When ever gw node down and
>> re start,
>> it should fetch messages which add to the topic during the down time.
>> In case durable subscription what is the mechanism to create client id
>> for each gw.Is that discussed and confirm?
>>
>
> No, we are not going to use durable topic. New gateways (scaling) or if we
> restart a gateway, existing APIs will fetch via API Manager core. Only new
> API (after boot up) notifications are getting via the topic and actual API
> will fetch from the core. ( we can try what sanjeewa mention - getting API
> from the topic - but previous APIs need to fetch from the core)
>
>

When we restart a gateway node, it would be better to fetch only the
updated APIs as well as the new APIs. Restarted gateway has the already
fetched APIs and it is not worth to fetch all the APIs again. We will have
to use durable subscription for this.

If we consider the container scenario, are we persisting gateway artifacts?
If we are not persisting gateway artifacts and restart the gateway
container, then we need to fetch all the APIs from the core. IMHO it would
better to persist data and load that data at restart as it would take time
to fetch all the APIs from the core.

Thank you!
-- 
*Pubudu Gunatilaka*
Committer and PMC Member - Apache Stratos
Software Engineer
WSO2, Inc.: http://wso2.com
mobile : +94774078049 <%2B94772207163>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture