Re: [Architecture] Implementing consent receipt specification in WSO2 Identity Server

2017-09-19 Thread Hasanthi Purnima Dissanayake
Hi Shan,

Along with these detail we save in these tables, we need to  keep a mapping
> to what each PII category means to WSO2 server.


With our current implementation in Identity Server we maintain a
scope-claim mapping in the registry level. For a scope a single or multiple
claims can be mapped and we can define any custom or scope or claim. So
IIUC here we can map PII category with scope. So indirectly we can map PII
category with claims. But at the moment we don't store those scope - claim
mapping in our database. So if we are to map PII category with the scopes
we need to store the scopes in the db level.

Thanks,

Hasanthi Dissanayake

Software Engineer | WSO2

E: hasan...@wso2.com
M :0718407133| http://wso2.com 

On Wed, Sep 20, 2017 at 9:09 AM, Pushpalanka Jayawardhana 
wrote:

> Hi Shan,
>
> Along with these detail we save in these tables, we need to  keep a
> mapping to what each PII category means to WSO2 server.
> In that case we can think of a PII category as a collection of claims.
>
> In IS we already have this concept of collection of claims, where we
> categorize them into a scope. WSO2 APIM already make use of these scopes to
> provide role based access to resources. We can try to make use of scopes in
> the place of PII category to establish this mapping with server claims
> which are actually PII keys. In the 'PII_CATEGORY' table we can keep track
> of this.
>
> Thanks,
>
> On Wed, Sep 13, 2017 at 2:45 PM, Shan Jayathilaka  wrote:
>
>> There is a new regulation called the EU General Data Protection
>> Regulation (GDPR) which replaces the Data Protection Directive 95/46/EC and
>> was designed to harmonize data privacy laws across Europe. GDPR was passed
>> as a regulation on 27th April 2016 and will be effective from 25th May
>> 2018. Regarding to this regulation any organization who is collecting user
>> data must collect data according to the user's consent. Also if an user
>> request about his/her consents about the user data, the data collecting
>> organization must provide those consents regarding to the user. In here we
>> have to record what are the consents of the user to a database. I designed
>> an [1]ER diagram for the database which collects the user consent. Also I
>> attached [2] GDPR Regulation document ,[3] a blog to understand the GDPR
>> and [4] Kantara Consent Receipt Management to this email. I hope they will
>> be helpful to all.
>>
>> *Brief explanation about the database tables*
>>
>>
>>- TRANSACTION_DETAILS: Contains details about the consent receipt id
>>and user identification.
>>
>>
>>- DATA_CONTROLLER: Contains details about the organization which
>>collects the user data.
>>- SERVICES: Contains details about the services provided to the user
>>data.
>>- PURPOSES: Contains details about the purposes to collect the user
>>data.
>>- THIRD_PARTY: Contains details about the third party organizations
>>which take the user data shared by the data controllers.
>>- PII_CATEGORY: Contains details about the personally identifiable
>>information (pii) categories.
>>
>> [1]
>> project_gdpr_new_erd.png
>> 
>> (140K)
>> 
>>
>> [2]
>> http://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=CELEX:32016R0679
>>
>> [3]
>> https://medium.facilelogin.com/understanding-gdpr-9201e1356418
>>
>> [4]
>> https://kantarainitiative.org/confluence/display/infosharing
>> /Consent+Receipt+Specification?preview=/76447870/90604248/
>> DRAFT%20Recommendation%20Consent%20Receipt%20Specification%201_0_0.docx
>>
>> Appreciate your feedback.
>>
>> Regards,
>>
>> Shan Chathusanda Jayathilaka
>> Software Engineer (Intern)
>> WSO2
>>
>> Mobile : +94702062877 <070%20206%202877>
>> Email : sh...@wso2.com
>> LinkedIn : www.linkedin.com/in/shanchathusanda/
>>
>
>
>
> --
> Pushpalanka.
> --
> Pushpalanka Jayawardhana, B.Sc.Eng.(Hons).
> Senior Software Engineer, WSO2 Lanka (pvt) Ltd;  wso2.com/
> Mobile: +94779716248
> Blog: pushpalankajaya.blogspot.com/ | LinkedIn: lk.linkedin.com/in/
> pushpalanka/ | Twitter: @pushpalanka
>
>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture


Re: [Architecture] Implementing consent receipt specification in WSO2 Identity Server

2017-09-19 Thread Pushpalanka Jayawardhana
Hi Shan,

Along with these detail we save in these tables, we need to  keep a mapping
to what each PII category means to WSO2 server.
In that case we can think of a PII category as a collection of claims.

In IS we already have this concept of collection of claims, where we
categorize them into a scope. WSO2 APIM already make use of these scopes to
provide role based access to resources. We can try to make use of scopes in
the place of PII category to establish this mapping with server claims
which are actually PII keys. In the 'PII_CATEGORY' table we can keep track
of this.

Thanks,

On Wed, Sep 13, 2017 at 2:45 PM, Shan Jayathilaka  wrote:

> There is a new regulation called the EU General Data Protection Regulation
> (GDPR) which replaces the Data Protection Directive 95/46/EC and was
> designed to harmonize data privacy laws across Europe. GDPR was passed as
> a regulation on 27th April 2016 and will be effective from 25th May 2018.
> Regarding to this regulation any organization who is collecting user data
> must collect data according to the user's consent. Also if an user request
> about his/her consents about the user data, the data collecting
> organization must provide those consents regarding to the user. In here we
> have to record what are the consents of the user to a database. I designed
> an [1]ER diagram for the database which collects the user consent. Also I
> attached [2] GDPR Regulation document ,[3] a blog to understand the GDPR
> and [4] Kantara Consent Receipt Management to this email. I hope they will
> be helpful to all.
>
> *Brief explanation about the database tables*
>
>
>- TRANSACTION_DETAILS: Contains details about the consent receipt id
>and user identification.
>
>
>- DATA_CONTROLLER: Contains details about the organization which
>collects the user data.
>- SERVICES: Contains details about the services provided to the user
>data.
>- PURPOSES: Contains details about the purposes to collect the user
>data.
>- THIRD_PARTY: Contains details about the third party organizations
>which take the user data shared by the data controllers.
>- PII_CATEGORY: Contains details about the personally identifiable
>information (pii) categories.
>
> [1]
> project_gdpr_new_erd.png
> 
> (140K)
> 
>
> [2]
> http://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=CELEX:32016R0679
>
> [3]
> https://medium.facilelogin.com/understanding-gdpr-9201e1356418
>
> [4]
> https://kantarainitiative.org/confluence/display/
> infosharing/Consent+Receipt+Specification?preview=/
> 76447870/90604248/DRAFT%20Recommendation%20Consent%
> 20Receipt%20Specification%201_0_0.docx
>
> Appreciate your feedback.
>
> Regards,
>
> Shan Chathusanda Jayathilaka
> Software Engineer (Intern)
> WSO2
>
> Mobile : +94702062877 <070%20206%202877>
> Email : sh...@wso2.com
> LinkedIn : www.linkedin.com/in/shanchathusanda/
>



-- 
Pushpalanka.
-- 
Pushpalanka Jayawardhana, B.Sc.Eng.(Hons).
Senior Software Engineer, WSO2 Lanka (pvt) Ltd;  wso2.com/
Mobile: +94779716248
Blog: pushpalankajaya.blogspot.com/ | LinkedIn:
lk.linkedin.com/in/pushpalanka/ | Twitter: @pushpalanka
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture


Re: [Architecture] Webapp server for React based webapps

2017-09-19 Thread SajithAR Ariyarathna
Hi Jo,

On Tue, Sep 12, 2017 at 10:59 AM, Joseph Fonseka  wrote:

> Hi Sajith
>
> +1 For the server, would like to propose adding gzip support as well.
>
> Does the web-server enforce the web-app structure ? If so IMHO it would be
> best not to do that.
>
>  Initial thought was to enforce the directory structure for any web app.
But I understand that for web apps like the Composer, the whole directory
structure won't be necessary. So we can make configuration.yaml,
extensions, i18n, and themes directories optional.

Thanks.

> Thanks & Regards
> Jo
>
>
>
>
>
>
> On Tue, Sep 12, 2017 at 10:13 AM, Chanaka Jayasena 
> wrote:
>
>> Hi Sajith,
>>
>> +1 for the web server. We will be able to replace the MS4J service inside
>> carbon-apimgt with this one when it's available.
>>
>> Following are some of my suggestions and thoughts.
>>
>> Can we put the public/images/logo.png and public/css/styles.css in the
>> default theme ?
>>
>> I believe the extensions are stand alone js files. In APIM case it will
>> be useful to add a new page to the store app. But we will have to write the
>> react app client side routing to pick the extension as a new route.
>>
>>
>> thanks,
>> Chanaka
>>
>> On Mon, Sep 11, 2017 at 3:35 PM, SajithAR Ariyarathna 
>> wrote:
>>
>>> Hi All,
>>>
>>> We are in the process of developing $subject. Tentatively this webapp
>>> server is named as "Carbon UI Server".
>>>
>>> # Major goals of this webapp server are following:
>>>
>>>- Enforcing security measures.
>>>   - Setting proper cache headers
>>>   - Setting recommended security related HTTP headers
>>>   - Protection against file system navigation through URLs
>>>- Defining a structure for webapps.
>>>   - Requirement is to properly define places to put page(s),
>>>   themes, UI extensions, and internalization language files in the 
>>> webapp.
>>>- Proper routeing for SPA apps.
>>>   - For SPA apps, index.html should be served for any request for a
>>>   page.
>>>
>>> # Proposing directory structure:
>>>
>>> - Webapps will be placed in /wso2//d
>>> eployments/reactapps/
>>>
>>> - Structure of a webapp:
>>>
>>> 
>>> ├── configuration.yaml
>>> │
>>> ├── extensions
>>> │   ├── widgets
>>> │   │   ├── line-chart/
>>> │   │   ├── bar-chart/
>>> │   │   └── calendar/
>>> │   │   ├── bundle.js
>>> │   │   ├── styles.css
>>> │   │   └── widget.json
>>> │   │
>>> │   └── device-types
>>> │   ├── andoid/
>>> │   ├── ios/
>>> │   └── ardino/
>>> │   └── ports.json
>>> ├── i18n
>>> │   ├── fr.properties
>>> │   └── en.properties
>>> │
>>> ├── pages
>>> │   └── index.html
>>> │
>>> ├── public
>>> │   ├── images
>>> │   │   └── logo.png
>>> │   ├── css
>>> │   │   └── styles.css
>>> │   └── js
>>> │   └── bundle.js
>>> │
>>> └── themes
>>> ├── dark/
>>> └── light
>>> ├── js
>>> │   └── some.js
>>> └── css
>>> └── styles.css
>>>
>>>
>>> - configuration.yaml will contain configurations of the web app (e.g.
>>> app context path, custom security headers). These configurations should be
>>> able to add/override through the deployment.yaml file.
>>>
>>> - extensions directory contains UI extensions. There can be multiple
>>> types of extensions and they are categorized accordingly into
>>> sub-directories inside the extensions directory. Each extension should
>>> be wrapped with a directory (the name of the directory will be the name of
>>> the extension), and placed inside the relevant type. Thus, the fully
>>> qualified name of an extension will be : (e.g.
>>> widgets:line-chart)
>>>
>>> - i18n directory will bear the internalization language files.
>>>
>>> - public directory contains any client-side resources of the app.
>>>
>>> - themes directory contains the themes of the app. Each theme should be
>>> put inside a sub-directory.
>>>
>>>
>>> # URL patterns:
>>>
>>>- Pages
>>>   - /path/to/page (e.g.
>>>   https://localhost:9292/pets-store/home
>>>   )
>>>- Resources of the app
>>>   - /public/app/
>>>   (e.g. https://localhost:9292/pets-store/public/app/images/logo.png
>>>   )
>>>   - Resources of an extension
>>>   - 
>>> /public/extensions///
>>>   (e.g. https://localhost:9292/pets-store/public/extensions/widgets/
>>>   calendar/styles.css)
>>>   - Resources of a theme
>>>   - 
>>> /public/themes//
>>>   (e.g. https://localhost:9292/pets-store/public/themes/light/css/st
>>>   yles.css)
>>>
>>>
>>> WDYT?
>>>
>>> Thanks.
>>> --
>>> Sajith Janaprasad Ariyarathna
>>> Senior Software Engineer; WSO2, Inc.;  http://wso2.com/
>>> 
>>>
>>
>>
>>
>> --
>> Chanaka Jayasena
>> Associate Tech Lead,
>> email: 

Re: [Architecture] [EI] Dynamically Routing Messages to Message Stores

2017-09-19 Thread Thishani Lucas
Hi Godwin,

Yes we can do that.

Thanks.

On Tue, Sep 19, 2017 at 11:40 AM, Godwin Shrimal  wrote:

> Hi Thishani,
>
> Can we support property such as below?
>
> 
>
> Thanks
> Godwin
>
>
> On Mon, Sep 18, 2017 at 12:08 PM, Thishani Lucas 
> wrote:
>
>> Hi Maninda,
>>
>> Thank you for your suggestion. Yes i thought of following Property
>> Mediator. But instead of introducing a new attribute called 'expression'
>> like in the Property Mediator, I plan to allow the Store Mediator to take
>> both the path expression and the string value. Then we can have a logic to
>> differentiate between a hard-coded store name and a path expression i.e if
>> the value is enclosed by curly braces, then it is an expression. This way we
>> can maintain the backward compatibility.
>>
>> Thank you.
>>
>> On Mon, Sep 18, 2017 at 11:39 AM, Maninda Edirisooriya 
>> wrote:
>>
>>> Hi Thishani,
>>>
>>> You can follow the same way the expressions/values spacified in Property
>>> Mediator in [1]. Then it will maintain the consistency in ESB space and you
>>> can simply reusing the existing functionality.
>>>
>>> [1] https://docs.wso2.com/display/ESB500/Property+Mediator
>>>
>>> Thanks.
>>>
>>>
>>> *Maninda Edirisooriya*
>>> Senior Software Engineer
>>>
>>> *WSO2, Inc.*lean.enterprise.middleware.
>>>
>>> *Blog* : http://maninda.blogspot.com/
>>> *E-mail* : mani...@wso2.com
>>> *Skype* : @manindae
>>> *Twitter* : @maninda
>>>
>>> On Mon, Sep 18, 2017 at 10:37 AM, Thishani Lucas 
>>> wrote:
>>>
 The current store mediator implementation allows the name of the
 message store to which the messages should be sent, to be given as a
 hard-coded string value. The requirement is to route the messages
 dynamically i.e without giving the hard-coded name, derive the name from
 the message context. To enable this, the message store name attribute of
 the store mediator should be allowed to take a path expression as a value.
 But also there should be a way to differentiate between a string value and
 an expression.

 According to the existing implementation, the store mediator is defined
 as follows.

 

 But with my implementation, the user will be able to extract the name
 from the message context and set it to message store as shown below.

 

 Please provide your suggestions on this feature.

 --
 Regards,

 *Thishani Lucas*
 *Software Engineer*
 *WSO2 Lanka (Private) Limited**: http://wso2.com *
 *lean.enterprise.middle-ware*

 *Tel: +94 77 2556931 <077%20255%206931> *

 *LinkedIn: https://www.linkedin.com/in/thishani-lucas/
 *

 

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


>>>
>>
>>
>> --
>> Regards,
>>
>> *Thishani Lucas*
>> *Software Engineer*
>> *WSO2 Lanka (Private) Limited**: http://wso2.com *
>> *lean.enterprise.middle-ware*
>>
>> *Tel: +94 77 2556931 <+94%2077%20255%206931> *
>>
>> *LinkedIn: https://www.linkedin.com/in/thishani-lucas/
>> *
>>
>> 
>>
>> ___
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
>
> --
> *Godwin Amila Shrimal*
> Associate Technical Lead
> WSO2 Inc.; http://wso2.com
> lean.enterprise.middleware
>
> mobile: *+94772264165*
> linkedin: *http://lnkd.in/KUum6D *
> twitter: https://twitter.com/godwinamila
> 
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 
Regards,

*Thishani Lucas*
*Software Engineer*
*WSO2 Lanka (Private) Limited**: http://wso2.com *
*lean.enterprise.middle-ware*

*Tel: +94 77 2556931 *

*LinkedIn: https://www.linkedin.com/in/thishani-lucas/
*


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


Re: [Architecture] MB4 active-passive clustering implementation

2017-09-19 Thread Asanka Abeyweera
Hi all,

We have decided to change the default deployment configurations with the HA
active passive implementation[1], We now have two options for
"deployment/mode" [2][3]. They are,

   - standalone - This is the simplest mode a broker can be started. The
   node will assume that message store is not shared with another node.
   Therefore it will not try to coordinate with other nodes (possibly
   non-existent) to provide HA. This is the *default* configuration used.
   - clustered - Broker node will run in HA mode (active/passive).

WDYT?

[1] https://github.com/wso2/andes/pull/921
[2] https://github.com/wso2/andes/pull/923
[3] https://github.com/wso2/carbon-business-messaging/pull/585

On Fri, Aug 18, 2017 at 3:32 PM, Asanka Abeyweera  wrote:

> Hi Abimaran,
>
> On Fri, Aug 18, 2017 at 2:44 PM, Abimaran Kugathasan 
> wrote:
>
>> Hi Asanka,
>>
>> We are embedding MB components into APIM and for minimum HA in API
>> Manager, there will be two active nodes. So will MB components/features
>> decide which node should be active and passive based on start up order
>> initially?
>>
>
> Yes, the MB component will decide on the active node.
>
>
>>
>> Also, are you expecting a client to send messages to both nodes (multi
>> cast) and passive MB nodes will reject them? Because in API Manager
>> perspective both node as active, so there could be a chance to configure a
>> gateway with active MB node as failover node.
>>
>
> No, the clients don't have to publish messages to both node. You can
> configure the broker URL with failover options. If the client connects to
> the passive node first it will get rejected and try to connect to the
> second node in the broker list. After connecting to the active node clients
> can resume publishing messages. Therefore it will not be an issue even if
> you connect to the pssive node first.
>
> WDYT?
>
>
>> On Thu, Aug 17, 2017 at 4:45 PM, Asanka Abeyweera 
>> wrote:
>>
>>> Hi all,
>>>
>>> I am working on implementing active-passive clustering on top of the new
>>> MB4 architecture. Current message delivery implementation in MB4 is not
>>> capable to work in a multi-node environment. If we run more than one node
>>> concurrently, messages can be duplicated since all nodes start delivering
>>> messages available for a queue in the message store. We have to make the
>>> MB4 nodes cluster aware to rectify this behavior.
>>> High-level design
>>>
>>> We are planning to use the available RDBMS leader election mechanism to
>>> decide on the active node. All the non-leader nodes will be passive nodes
>>> and will reject all incoming requests. The clients should be configured
>>> with failover URLs so that they can failover to the active node from
>>> passive nodes.
>>>
>>> Tasks to do when the active node becomes passive
>>>
>>>1.
>>>
>>>Enable rejecting all requests to broker node except the CLOSE-OK
>>>2.
>>>
>>>Close existing AMQ connections (both publishing and consuming)
>>>
>>>
>>> Tasks to do when the passive node becomes active
>>>
>>>1.
>>>
>>>Start accepting all requests to broker node
>>>
>>>
>>> The assumption here is the active components like the Inbound disruptor,
>>> outbound disruptor, delivery task managers will stop working (consuming
>>> resources) when the incoming requests are stopped and subscriptions are
>>> removed in passive nodes.
>>>
>>>
>>>
>>>-
>>>
>>>Filtering message events will be handled by “InboundEventGatekeeper”.
>>>-
>>>
>>>DeliveryHandler will also be modified to stop delivering messages
>>>when a node becomes passive.
>>>-
>>>
>>>All the connections will be closed using the server connection
>>>registry
>>>
>>>
>>> Suggestions and feedback are appreciated.
>>>
>>> --
>>> Asanka Abeyweera
>>> Senior Software Engineer
>>> WSO2 Inc.
>>>
>>> Phone: +94 712228648 <+94%2071%20222%208648>
>>> Blog: a5anka.github.io
>>>
>>> 
>>>
>>> ___
>>> Architecture mailing list
>>> Architecture@wso2.org
>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>
>>>
>>
>>
>> --
>> Thanks
>> Abimaran Kugathasan
>> Senior Software Engineer - API Technologies
>>
>> Email : abima...@wso2.com
>> Mobile : +94 773922820 <+94%2077%20392%202820>
>>
>> 
>> 
>>   
>> 
>>
>>
>> ___
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
>
> --
> Asanka Abeyweera
> Senior Software Engineer
> WSO2 Inc.
>
> Phone: +94 712228648 <+94%2071%20222%208648>
> Blog: a5anka.github.io
>
> 
>



-- 
Asanka Abeyweera
Associate Technical Lead
WSO2 Inc.

Phone: +94 712228648
Blog: a5anka.github.io

Re: [Architecture] [EI] Dynamically Routing Messages to Message Stores

2017-09-19 Thread Godwin Shrimal
Hi Thishani,

Can we support property such as below?



Thanks
Godwin


On Mon, Sep 18, 2017 at 12:08 PM, Thishani Lucas  wrote:

> Hi Maninda,
>
> Thank you for your suggestion. Yes i thought of following Property
> Mediator. But instead of introducing a new attribute called 'expression'
> like in the Property Mediator, I plan to allow the Store Mediator to take
> both the path expression and the string value. Then we can have a logic to
> differentiate between a hard-coded store name and a path expression i.e if
> the value is enclosed by curly braces, then it is an expression. This way we
> can maintain the backward compatibility.
>
> Thank you.
>
> On Mon, Sep 18, 2017 at 11:39 AM, Maninda Edirisooriya 
> wrote:
>
>> Hi Thishani,
>>
>> You can follow the same way the expressions/values spacified in Property
>> Mediator in [1]. Then it will maintain the consistency in ESB space and you
>> can simply reusing the existing functionality.
>>
>> [1] https://docs.wso2.com/display/ESB500/Property+Mediator
>>
>> Thanks.
>>
>>
>> *Maninda Edirisooriya*
>> Senior Software Engineer
>>
>> *WSO2, Inc.*lean.enterprise.middleware.
>>
>> *Blog* : http://maninda.blogspot.com/
>> *E-mail* : mani...@wso2.com
>> *Skype* : @manindae
>> *Twitter* : @maninda
>>
>> On Mon, Sep 18, 2017 at 10:37 AM, Thishani Lucas 
>> wrote:
>>
>>> The current store mediator implementation allows the name of the message
>>> store to which the messages should be sent, to be given as a hard-coded
>>> string value. The requirement is to route the messages dynamically i.e
>>> without giving the hard-coded name, derive the name from the message
>>> context. To enable this, the message store name attribute of the store
>>> mediator should be allowed to take a path expression as a value. But also
>>> there should be a way to differentiate between a string value and an
>>> expression.
>>>
>>> According to the existing implementation, the store mediator is defined
>>> as follows.
>>>
>>> 
>>>
>>> But with my implementation, the user will be able to extract the name
>>> from the message context and set it to message store as shown below.
>>>
>>> 
>>>
>>> Please provide your suggestions on this feature.
>>>
>>> --
>>> Regards,
>>>
>>> *Thishani Lucas*
>>> *Software Engineer*
>>> *WSO2 Lanka (Private) Limited**: http://wso2.com *
>>> *lean.enterprise.middle-ware*
>>>
>>> *Tel: +94 77 2556931 <077%20255%206931> *
>>>
>>> *LinkedIn: https://www.linkedin.com/in/thishani-lucas/
>>> *
>>>
>>> 
>>>
>>> ___
>>> Architecture mailing list
>>> Architecture@wso2.org
>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>
>>>
>>
>
>
> --
> Regards,
>
> *Thishani Lucas*
> *Software Engineer*
> *WSO2 Lanka (Private) Limited**: http://wso2.com *
> *lean.enterprise.middle-ware*
>
> *Tel: +94 77 2556931 <+94%2077%20255%206931> *
>
> *LinkedIn: https://www.linkedin.com/in/thishani-lucas/
> *
>
> 
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 
*Godwin Amila Shrimal*
Associate Technical Lead
WSO2 Inc.; http://wso2.com
lean.enterprise.middleware

mobile: *+94772264165*
linkedin: *http://lnkd.in/KUum6D *
twitter: https://twitter.com/godwinamila

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