Re: [Architecture] Load Balancing WSO2 Admin Services
Hi Asela, On Wed, Mar 5, 2014 at 10:55 AM, Asela Pathberiya as...@wso2.com wrote: Hi All, In some Identity Server deployment, there are clients (web applications, Application clients and so on) that talk to admin services in Identity server such as user management, entitlement and s on... To access these admin services, client must be authenticated to Identity Server. We can configure some pre-defined user for the client application and client would always be authenticated to admin service using the defined user. It is not good to authenticate for every requests and populate the contexts, therefore normally authenticated session info (Cookie) would be used by the clients. If we want to achieve high availability and load distribution, you need to load balance the clients requests with clustered Identity server instances. As WSO2 Identity Server (and all WSO2 products) does not support for user session replication across cluster nodes. Therefore we may need to use sticky session with the load balancer.. But If LB only considers the sticky session as the only metric for load balancing, All request would be received to an one node of the cluster.. There would not be any use from other nodes..(no Active-Active nodes) No. All requests will not directed to a single server even we use sticky sessions. Only the requests related to a single session will get routed to the same server. Requests belongs a different session will get routed a different server in the cluster. This is how we've been clustering our products with management consoles. With sticky sessions you will get true load balancing. Thanks, Sameera. Can typical LB (WSO2 ELB, Apache HTTPD) take other metrics for load balancing when sticky session has been configured? Are they intelligent enough ? As I know, user session replications would be supported with Carbon 5.. Till what is the best solution for load balancing the Admin services? I have written some blog about this [1].. which may be helpful. what is in the blog, may not be the best approaches.. [1] http://soasecurity.org/2014/03/04/load-balancing-wso2-admin-services/ Thanks, Asela. -- Thanks Regards, Asela ATL Mobile : +94 777 625 933 -- Sameera Jayasoma, Architect, WSO2, Inc. (http://wso2.com) email: same...@wso2.com blog: http://sameera.adahas.org twitter: https://twitter.com/sameerajayasoma flickr: http://www.flickr.com/photos/sameera-jayasoma/collections Mobile: 0094776364456 Lean . Enterprise . Middleware ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] Meeting minutes for the review of the Jaggery-Pipe and simpleRouter implementation
Hello Everyone,
The updated jaggery-pipe (pipe) and the router implementation is available
at:
https://github.com/splinter/jaggery-pipe
Thank You,
Sameera
On Mon, Feb 17, 2014 at 7:59 PM, Nuwan Bandara nu...@wso2.com wrote:
+1 for the proposal guys. and as chan said if we can use goose for base
stuff lets get that and built on top of that.
Regards,
/Nuwan
On Sun, Feb 16, 2014 at 7:09 AM, Chan duli...@wso2.com wrote:
I would further suggest to merge the simple router to goose.js[1] and
promote a single router as the base. The router module should be improved
for the above mentioned features. We can also remove the authentication and
authorization bits off from goose.js to a middleware component that can be
plugged in. (feel free to name it as jaggery-router since we are following
a convention on naming).
[1] - https://github.com/dulichan/goose.js
On Sun, Feb 16, 2014 at 12:37 PM, Sameera Medagammaddegedara
samee...@wso2.com wrote:
Hello Everyone,
*Description:*
The review looked at the use of the Jaggery-Pipe [3] ( a middleware
implementation like connect.js [1] ) and the simpleRouter plug-in [4] that
will be integrated into the Store and Publisher. These new components will
be used to handle routing and support for additional extension points in
the Store and Publisher.
*Participants*:
*Enterprise Store Team*: Ruchira, Praveena,Tanya, Nadeesha and Sameera
*Mobile Team:* Dulitha (Chan)
*Observations:*
- There is no need to allow users to define multiple routes to a
single handler in one line. This can be handled by defining each route
in
a single line, in order to promote readability
- There is no need to allow users to override a plug-in used in the
pipe
*Actions:*
- The underlying implementation of the simpleRouter needs to be
changed so that it creates a tree structure from each route. This will
allow the definition of multiple route levels;
- /store/asset/:type/:id
- /store/asset/api/:id
- The simpleRouter should operate in two modes: development and
production
- In the development mode the route tree should be constructed
for each request
- In the production mode the route tree should only be built once
- The variables in a route should be defined using : (colons) as
opposed to { (curly braces):
- Current: /store/asset/{type}
- New: /store/asset/:type
- This is the implementation used in other JavaScript routing
frameworks (e.g. Express [2] )
*References*
[1] Connect.js ,URL: http://www.senchalabs.org/connect/
[2] Express.js ,URL: http://expressjs.com/guide.html
[3] Jaggery-Pipe ,URL:https://github.com/splinter/jaggery-pipe
[4] simpleRouter ,URL:
https://github.com/splinter/jaggery-pipe/blob/master/plugins/simpleRouter.js
Thank You,
Sameera
--
Sameera Medagammaddegedara
Software Engineer
Contact:
Email: samee...@wso2.com
Mobile: + 94 077 255 3005
--
Chan (Dulitha Wijewantha)
Software Engineer - Mobile Development
WSO2Mobile
Lean.Enterprise.Mobileware
* ~Email duli...@wso2.com duli...@wso2mobile.com*
* ~Mobile +94712112165 %2B94712112165*
* ~Website dulithawijewantha.com http://dulithawijewantha.com/ *
* ~Blog blog.dulithawijewantha.com
http://dulichan.github.io/chan/*
* ~Twitter @dulitharw https://twitter.com/dulitharw*
--
*Thanks Regards,Nuwan BandaraTechnical Lead; **WSO2 Inc. *
*lean . enterprise . middleware | http://wso2.com http://wso2.com *
*blog : http://nuwanbando.com http://nuwanbando.com; email:
nu...@wso2.com nu...@wso2.com; phone: +1 812 606 7390
%2B1%20812%20606%207390 *
http://www.nuwanbando.com/
--
Sameera Medagammaddegedara
Software Engineer
Contact:
Email: samee...@wso2.com
Mobile: + 94 077 255 3005
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] Meeting minutes for the review of the Jaggery-Pipe and simpleRouter implementation
Hi Sameera,
I have done some changes to the router. I'll contribute them back. This is
regarding the public api of the router.
Cheers~
On Wed, Mar 5, 2014 at 5:38 PM, Sameera Medagammaddegedara
samee...@wso2.com wrote:
Hello Everyone,
The updated jaggery-pipe (pipe) and the router implementation is available
at:
https://github.com/splinter/jaggery-pipe
Thank You,
Sameera
On Mon, Feb 17, 2014 at 7:59 PM, Nuwan Bandara nu...@wso2.com wrote:
+1 for the proposal guys. and as chan said if we can use goose for base
stuff lets get that and built on top of that.
Regards,
/Nuwan
On Sun, Feb 16, 2014 at 7:09 AM, Chan duli...@wso2.com wrote:
I would further suggest to merge the simple router to goose.js[1] and
promote a single router as the base. The router module should be improved
for the above mentioned features. We can also remove the authentication and
authorization bits off from goose.js to a middleware component that can be
plugged in. (feel free to name it as jaggery-router since we are following
a convention on naming).
[1] - https://github.com/dulichan/goose.js
On Sun, Feb 16, 2014 at 12:37 PM, Sameera Medagammaddegedara
samee...@wso2.com wrote:
Hello Everyone,
*Description:*
The review looked at the use of the Jaggery-Pipe [3] ( a middleware
implementation like connect.js [1] ) and the simpleRouter plug-in [4] that
will be integrated into the Store and Publisher. These new components will
be used to handle routing and support for additional extension points in
the Store and Publisher.
*Participants*:
*Enterprise Store Team*: Ruchira, Praveena,Tanya, Nadeesha and Sameera
*Mobile Team:* Dulitha (Chan)
*Observations:*
- There is no need to allow users to define multiple routes to a
single handler in one line. This can be handled by defining each route
in
a single line, in order to promote readability
- There is no need to allow users to override a plug-in used in the
pipe
*Actions:*
- The underlying implementation of the simpleRouter needs to be
changed so that it creates a tree structure from each route. This will
allow the definition of multiple route levels;
- /store/asset/:type/:id
- /store/asset/api/:id
- The simpleRouter should operate in two modes: development and
production
- In the development mode the route tree should be constructed
for each request
- In the production mode the route tree should only be built once
- The variables in a route should be defined using : (colons) as
opposed to { (curly braces):
- Current: /store/asset/{type}
- New: /store/asset/:type
- This is the implementation used in other JavaScript routing
frameworks (e.g. Express [2] )
*References*
[1] Connect.js ,URL: http://www.senchalabs.org/connect/
[2] Express.js ,URL: http://expressjs.com/guide.html
[3] Jaggery-Pipe ,URL:https://github.com/splinter/jaggery-pipe
[4] simpleRouter ,URL:
https://github.com/splinter/jaggery-pipe/blob/master/plugins/simpleRouter.js
Thank You,
Sameera
--
Sameera Medagammaddegedara
Software Engineer
Contact:
Email: samee...@wso2.com
Mobile: + 94 077 255 3005
--
Chan (Dulitha Wijewantha)
Software Engineer - Mobile Development
WSO2Mobile
Lean.Enterprise.Mobileware
* ~Email duli...@wso2.com duli...@wso2mobile.com*
* ~Mobile +94712112165 %2B94712112165*
* ~Website dulithawijewantha.com http://dulithawijewantha.com/ *
* ~Blog blog.dulithawijewantha.com
http://dulichan.github.io/chan/*
* ~Twitter @dulitharw https://twitter.com/dulitharw*
--
*Thanks Regards,Nuwan Bandara Technical Lead; **WSO2 Inc. *
*lean . enterprise . middleware | http://wso2.com http://wso2.com *
*blog : http://nuwanbando.com http://nuwanbando.com; email:
nu...@wso2.com nu...@wso2.com; phone: +1 812 606 7390
%2B1%20812%20606%207390 *
http://www.nuwanbando.com/
--
Sameera Medagammaddegedara
Software Engineer
Contact:
Email: samee...@wso2.com
Mobile: + 94 077 255 3005
--
Chan (Dulitha Wijewantha)
Software Engineer - Mobile Development
WSO2Mobile
Lean.Enterprise.Mobileware
* ~Email duli...@wso2.com duli...@wso2mobile.com*
* ~Mobile +94712112165*
* ~Website dulitha.me http://dulitha.me*
* ~Twitter @dulitharw https://twitter.com/dulitharw*
*~SO @chan http://stackoverflow.com/users/813471/chan*
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
[Architecture] WSO2 Products Tenant Creation Process calls the Reset Password
Hi all I found that our tenant creation process is calling reset password call inside tenant creation process. When we call tenant creation it goes through *persistTenant* call in *TenantPersistor* class. And it calls *persistTenantInUserStore*. In the end of this call it calls for *updateTenantAdminPassword*. By the time Tenant Manager is created the tenant admin and have added the password to the LDAP. So is there a particular reason that we should do this? I cant see any reason that we call the update/reset password at this moment. So IMO we should remove this if no such reason. WDYT? Thanks Regards Danushka Fernando Software Engineer WSO2 inc. http://wso2.com/ Mobile : +94716332729 ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] Load Balancing WSO2 Admin Services
On Wed, Mar 5, 2014 at 3:10 PM, Sameera Jayasoma same...@wso2.com wrote: Hi Asela, On Wed, Mar 5, 2014 at 10:55 AM, Asela Pathberiya as...@wso2.com wrote: Hi All, In some Identity Server deployment, there are clients (web applications, Application clients and so on) that talk to admin services in Identity server such as user management, entitlement and s on... To access these admin services, client must be authenticated to Identity Server. We can configure some pre-defined user for the client application and client would always be authenticated to admin service using the defined user. It is not good to authenticate for every requests and populate the contexts, therefore normally authenticated session info (Cookie) would be used by the clients. If we want to achieve high availability and load distribution, you need to load balance the clients requests with clustered Identity server instances. As WSO2 Identity Server (and all WSO2 products) does not support for user session replication across cluster nodes. Therefore we may need to use sticky session with the load balancer.. But If LB only considers the sticky session as the only metric for load balancing, All request would be received to an one node of the cluster.. There would not be any use from other nodes..(no Active-Active nodes) No. All requests will not directed to a single server even we use sticky sessions. Only the requests related to a single session will get routed to the same server. Requests belongs a different session will get routed a different server in the cluster. This is how we've been clustering our products with management consoles. With sticky sessions you will get true load balancing. Yes.. that is the normal scenario.. As i have mentioned above, There is only one pre-defined user who is authenticated with the admin server. To be clear, please take following examples. 1. OAuth or Entitlement mediator calls to WSO2IS. -- When we configure these mediators, we configure user/password within the mediator. Those user/pass are used to authenticate for every request. Then If, we configure a LB(with sticky session) between ESB and IS, LB can not do the load distribution (No Active-Active) 2. API Gateway calls to Key manager -- AFAIK, API Gateway calls the admin service of the key manager. User/Pass has been configure in the api-manager.xml file. Therefore Gateway always uses same user/pass. Then if we configure a LB(with sticky session) between API Gateway and Key manager , LB can not do the load distribution(No Active-Active) Thanks, Asela. Thanks, Sameera. Can typical LB (WSO2 ELB, Apache HTTPD) take other metrics for load balancing when sticky session has been configured? Are they intelligent enough ? As I know, user session replications would be supported with Carbon 5.. Till what is the best solution for load balancing the Admin services? I have written some blog about this [1].. which may be helpful. what is in the blog, may not be the best approaches.. [1] http://soasecurity.org/2014/03/04/load-balancing-wso2-admin-services/ Thanks, Asela. -- Thanks Regards, Asela ATL Mobile : +94 777 625 933 -- Sameera Jayasoma, Architect, WSO2, Inc. (http://wso2.com) email: same...@wso2.com blog: http://sameera.adahas.org twitter: https://twitter.com/sameerajayasoma flickr: http://www.flickr.com/photos/sameera-jayasoma/collections Mobile: 0094776364456 Lean . Enterprise . Middleware -- Thanks Regards, Asela ATL Mobile : +94 777 625 933 ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] [APIM] Storing configuration for Workflow Executors in Registry
Hi Amila, How different are these workflow configurations from a registry lifecycle configuration? I'm not suggesting that we reuse, but just to understand. Thanks, Senaka. On Thu, Mar 6, 2014 at 11:04 AM, Amila De Silva ami...@wso2.com wrote: Hi, Currently the configuration for Workflow Executors are kept in the api-manager.xml. Due to this design, there'll be a single workflow configuration for an entire deployment and all the tenants have to use the same executors. We are planning to move Workflow Configuration to the registry. A default configuration will be sent with the pack, and it'll get added to the registry when; 1. The pack is first started - (Workflow configuration is created created in the Super Tenant's registry) 2. A new Tenant is Created - (Workflow configuration is created created in the respective Tenant's registry). With this, each tenant will be referring to the configuration stored in their own Registry space. To change the configuration, the Tenant Admin has to log into the admin console and edit the registry resource. -- *Amila De Silva* *Software Engineer* WSO2 Inc. mobile :(+94) 775119302 ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture -- *[image: http://wso2.com] http://wso2.com Senaka Fernando* Senior Technical Lead; WSO2 Inc.; http://wso2.com * Member; Apache Software Foundation; http://apache.org http://apache.orgE-mail: senaka AT wso2.com http://wso2.com**P: +1 408 754 7388; ext: 51736*; *M: +94 77 322 1818 Linked-In: http://linkedin.com/in/senakafernando http://linkedin.com/in/senakafernando*Lean . Enterprise . Middleware ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] [APIM] Storing configuration for Workflow Executors in Registry
On Thu, Mar 6, 2014 at 11:04 AM, Amila De Silva ami...@wso2.com wrote: Hi, Currently the configuration for Workflow Executors are kept in the api-manager.xml. Due to this design, there'll be a single workflow configuration for an entire deployment and all the tenants have to use the same executors. We are planning to move Workflow Configuration to the registry. A default configuration will be sent with the pack, and it'll get added to the registry when; 1. The pack is first started - (Workflow configuration is created created in the Super Tenant's registry) 2. A new Tenant is Created - (Workflow configuration is created created in the respective Tenant's registry). With this, each tenant will be referring to the configuration stored in their own Registry space. To change the configuration, the Tenant Admin has to log into the admin console and edit the registry resource. +1. This will be useful IMO. We can push default workflow configs to some predefined registry location inside tenant space when tenant created as we do for tiers.xml and external store configurations. Also i would like to suggest to use common location to store all tenant specific configurations(tenant specific tier, API RXT, defined sequences). At this moment we store external store related configs also in registry. It would be more convenient if we can keep all tenant specific configurations in one registry path. WDYT? We can parse and load this configuration when publisher get loaded (when we initialized AbstractAPIManager). Thanks. sanjeewa. -- *Amila De Silva* *Software Engineer* WSO2 Inc. mobile :(+94) 775119302 ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture -- *Sanjeewa Malalgoda* Senior Software Engineer WSO2 Inc. Mobile : +94713068779 http://sanjeewamalalgoda.blogspot.com/blog :http://sanjeewamalalgoda.blogspot.com/http://sanjeewamalalgoda.blogspot.com/ ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] [APIM] Storing configuration for Workflow Executors in Registry
Hi Nuwan, Amila, If you for a moment think of a Store/Publisher webapp being a resource (just a logical assumption), is this kind of workflow similar to a registry lifecycle? We shouldn't be looking at the configuration model or what it does today, but the functional similarity. I'm asking these questions to understand whether we should unify the concept of workflow inside the platform to be based on some similar model. Thanks, Senaka. On Thu, Mar 6, 2014 at 11:36 AM, Nuwan Dias nuw...@wso2.com wrote: From what I understand, a registry lifecycle is always associated to a registry resource (only). But workflows are plug-points to various UI actions that you perform on the Store/Publisher webapps. Ex: A user sign-up, API Subscription, etc. Thanks, NuwanD. On Thu, Mar 6, 2014 at 11:28 AM, Senaka Fernando sen...@wso2.com wrote: Hi Amila, How different are these workflow configurations from a registry lifecycle configuration? I'm not suggesting that we reuse, but just to understand. Thanks, Senaka. On Thu, Mar 6, 2014 at 11:04 AM, Amila De Silva ami...@wso2.com wrote: Hi, Currently the configuration for Workflow Executors are kept in the api-manager.xml. Due to this design, there'll be a single workflow configuration for an entire deployment and all the tenants have to use the same executors. We are planning to move Workflow Configuration to the registry. A default configuration will be sent with the pack, and it'll get added to the registry when; 1. The pack is first started - (Workflow configuration is created created in the Super Tenant's registry) 2. A new Tenant is Created - (Workflow configuration is created created in the respective Tenant's registry). With this, each tenant will be referring to the configuration stored in their own Registry space. To change the configuration, the Tenant Admin has to log into the admin console and edit the registry resource. -- *Amila De Silva* *Software Engineer* WSO2 Inc. mobile :(+94) 775119302 ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture -- *[image: http://wso2.com] http://wso2.com Senaka Fernando* Senior Technical Lead; WSO2 Inc.; http://wso2.com * Member; Apache Software Foundation; http://apache.org http://apache.orgE-mail: senaka AT wso2.com http://wso2.com**P: +1 408 754 7388 %2B1%20408%20754%207388; ext: 51736*; *M: +94 77 322 1818 %2B94%2077%20322%201818 Linked-In: http://linkedin.com/in/senakafernando http://linkedin.com/in/senakafernando*Lean . Enterprise . Middleware ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture -- Nuwan Dias Senior Software Engineer - WSO2, Inc. http://wso2.com email : nuw...@wso2.com Phone : +94 777 775 729 ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture -- *[image: http://wso2.com] http://wso2.com Senaka Fernando* Senior Technical Lead; WSO2 Inc.; http://wso2.com * Member; Apache Software Foundation; http://apache.org http://apache.orgE-mail: senaka AT wso2.com http://wso2.com**P: +1 408 754 7388; ext: 51736*; *M: +94 77 322 1818 Linked-In: http://linkedin.com/in/senakafernando http://linkedin.com/in/senakafernando*Lean . Enterprise . Middleware ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Re: [Architecture] [APIM] Storing configuration for Workflow Executors in Registry
Hi Senaka, If we assume a subscription being a resource, then the states it would go through are somewhat similar to stages in a LifeCycle. When a subscription is made a workflow will be triggered (the state will be set to Created) and based on the configuration it will call an external service. The state of the subscription will be changed by several different parties - the subscription creator and several Administrators. Subscription will only become active after the state is changed to Approved. The main difference I see between the workflows we currently have and a registry life cycle is the ability for several parties to do the state changes. On Thu, Mar 6, 2014 at 11:49 AM, Senaka Fernando sen...@wso2.com wrote: Hi Nuwan, Amila, If you for a moment think of a Store/Publisher webapp being a resource (just a logical assumption), is this kind of workflow similar to a registry lifecycle? We shouldn't be looking at the configuration model or what it does today, but the functional similarity. I'm asking these questions to understand whether we should unify the concept of workflow inside the platform to be based on some similar model. Thanks, Senaka. On Thu, Mar 6, 2014 at 11:36 AM, Nuwan Dias nuw...@wso2.com wrote: From what I understand, a registry lifecycle is always associated to a registry resource (only). But workflows are plug-points to various UI actions that you perform on the Store/Publisher webapps. Ex: A user sign-up, API Subscription, etc. Thanks, NuwanD. On Thu, Mar 6, 2014 at 11:28 AM, Senaka Fernando sen...@wso2.com wrote: Hi Amila, How different are these workflow configurations from a registry lifecycle configuration? I'm not suggesting that we reuse, but just to understand. Thanks, Senaka. On Thu, Mar 6, 2014 at 11:04 AM, Amila De Silva ami...@wso2.com wrote: Hi, Currently the configuration for Workflow Executors are kept in the api-manager.xml. Due to this design, there'll be a single workflow configuration for an entire deployment and all the tenants have to use the same executors. We are planning to move Workflow Configuration to the registry. A default configuration will be sent with the pack, and it'll get added to the registry when; 1. The pack is first started - (Workflow configuration is created created in the Super Tenant's registry) 2. A new Tenant is Created - (Workflow configuration is created created in the respective Tenant's registry). With this, each tenant will be referring to the configuration stored in their own Registry space. To change the configuration, the Tenant Admin has to log into the admin console and edit the registry resource. -- *Amila De Silva* *Software Engineer* WSO2 Inc. mobile :(+94) 775119302 ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture -- *[image: http://wso2.com] http://wso2.com Senaka Fernando* Senior Technical Lead; WSO2 Inc.; http://wso2.com * Member; Apache Software Foundation; http://apache.org http://apache.orgE-mail: senaka AT wso2.com http://wso2.com**P: +1 408 754 7388 %2B1%20408%20754%207388; ext: 51736*; *M: +94 77 322 1818 %2B94%2077%20322%201818 Linked-In: http://linkedin.com/in/senakafernando http://linkedin.com/in/senakafernando*Lean . Enterprise . Middleware ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture -- Nuwan Dias Senior Software Engineer - WSO2, Inc. http://wso2.com email : nuw...@wso2.com Phone : +94 777 775 729 ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture -- *[image: http://wso2.com] http://wso2.com Senaka Fernando* Senior Technical Lead; WSO2 Inc.; http://wso2.com * Member; Apache Software Foundation; http://apache.org http://apache.orgE-mail: senaka AT wso2.com http://wso2.com**P: +1 408 754 7388 %2B1%20408%20754%207388; ext: 51736*; *M: +94 77 322 1818 %2B94%2077%20322%201818 Linked-In: http://linkedin.com/in/senakafernando http://linkedin.com/in/senakafernando*Lean . Enterprise . Middleware ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture -- *Amila De Silva* *Software Engineer* WSO2 Inc. mobile :(+94) 775119302 ___ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
