Re: [Architecture] RFC: Video and Image Processing Support in WSO2 Platform

[Rajith Roshan]

gt;>
>>>>>
>>>>>
>>>>> On Mon, Aug 15, 2016 at 4:14 PM, Sanjiva Weerawarana >>>> > wrote:
>>>>>
>>>>>> Looks good!
>>>>>>
>>>>>> In terms of test data we can take the video cameras in the LK Palm
>>>>>> Grove lobby as an input source to play around with people analysis. For
>>>>>> vehicles we can plop a camera pointing to Duplication Road and get plenty
>>>>>> of data :-).
>>>>>>
>>>>>> I guess we should do some small experiments to see how things work.
>>>>>>
>>>>>> Sanjiva.
>>>>>>
>>>>>> On Wed, Aug 10, 2016 at 3:02 PM, Srinath Perera 
>>>>>> wrote:
>>>>>>
>>>>>>> Attached document list some of the initial ideas about the topic.
>>>>>>> Anusha is exploring some of the ideas as an intern project.
>>>>>>>
>>>>>>> Please comment and help ( specially if you have worked on this area
>>>>>>> or has tried out things)
>>>>>>>
>>>>>>>
>>>>>>> Thanks
>>>>>>> Srinath
>>>>>>>
>>>>>>> --
>>>>>>> 
>>>>>>> Srinath Perera, Ph.D.
>>>>>>>http://people.apache.org/~hemapani/
>>>>>>>http://srinathsview.blogspot.com/
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Sanjiva Weerawarana, Ph.D.
>>>>>> Founder, CEO & Chief Architect; WSO2, Inc.;  http://wso2.com/
>>>>>> email: sanj...@wso2.com; office: (+1 650 745 4499 | +94  11 214
>>>>>> 5345) x5700; cell: +94 77 787 6880 | +1 408 466 5099; voip: +1 650
>>>>>> 265 8311
>>>>>> blog: http://sanjiva.weerawarana.org/; twitter: @sanjiva
>>>>>> Lean . Enterprise . Middleware
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> 
>>>>> Srinath Perera, Ph.D.
>>>>>http://people.apache.org/~hemapani/
>>>>>http://srinathsview.blogspot.com/
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>>
>>>> Anusha Jayasundara
>>>> Intern Software Engineer
>>>> WSO2
>>>> +94711920369
>>>>
>>>> ___
>>>> Architecture mailing list
>>>> Architecture@wso2.org
>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>>
>>>>
>>>
>>>
>>> --
>>> Geesara Prathap Kulathunga
>>> Software Engineer
>>> WSO2 Inc; http://wso2.com
>>> Mobile : +940772684174
>>>
>>>
>>
>>
>> --
>>
>> Anusha Jayasundara
>> Intern Software Engineer
>> WSO2
>> +94711920369
>>
>> ___
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
>
> --
> /sumedha
> m: +94 773017743
> b :  bit.ly/sumedha
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 
Rajith Roshan
Software Engineer, WSO2 Inc.
Mobile: +94-72-642-8350 <%2B94-71-554-8430>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

[Architecture] [APIM] Life cycle Management

[Rajith Roshan]

Hi all,

Life cycle is an integral part in any product. Each SOA governance related
artifacts can have their own life cycle. Capabilities provided in order to
manage life cycles not only allow you to properly organize your assets but
also provides many extensibilities (For ex through custom executors)

RequirementCurrent API life cycle of API manager completely depends  on the
life cycle implementation provided by the registry. Since we are moving
away from the registry concept we need a completely new life cycle
management framework which cater for life cycle management within API
Manager and should be able to ship with other products which require life
cycle management.

Proposed SolutionThe basic idea is to completely decouple the life cycle
framework from the system to which its provide life cycle capabilities. I.e
the system which uses life cycle will not change the behavior of the life
cycle framework and only vice versa will be applicable. The framework
should exist independent of the asset type to which it provides life cycle
capability




The mapping should be maintained by asset type in order to associate with
life cycle data. To be more specific in database schema level each asset
type should update their tables (add extra columns to maintain mapping with
life cycle data) in order to map  life cycle data.

The external systems which uses life cycle service should connect with the
service in order to have a unique life cycle id which is generated by the
service. This id should be stored in the external system in order to
maintain the mapping (Each asset should have its own life cycle id). On the
other hand life cycle framework will also store this id in order to provide
all the life cycle related operations for a particular asset.



Basically, we will be providing a class (ManagedLifecycle) with all the
required basic operations. Any asset which requires life cycle management
can extend this class.
Further this can be extended to support features like check list items as
well
Features supported

   -

   Custom Inputs - User should  provide with the capability in order to
   save custom values per each state, which can be passed to executors .
   - Executors - Which are custom classes executed during life cycle state
   change operation


Please provide you valuable inputs.

Thanks!
Rajith

-- 
Rajith Roshan
Software Engineer, WSO2 Inc.
Mobile: +94-72-642-8350 <%2B94-71-554-8430>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [APIM] Life cycle Management

[Rajith Roshan]

>
> Hi,
>
please find the images below

> On Mon, Oct 10, 2016 at 3:16 PM, Rajith Roshan  wrote:
>
>> Hi all,
>>
>> Life cycle is an integral part in any product. Each SOA governance
>> related artifacts can have their own life cycle. Capabilities provided in
>> order to manage life cycles not only allow you to properly organize your
>> assets but also provides many extensibilities (For ex through custom
>> executors)
>>
>> RequirementCurrent API life cycle of API manager completely depends  on
>> the life cycle implementation provided by the registry. Since we are moving
>> away from the registry concept we need a completely new life cycle
>> management framework which cater for life cycle management within API
>> Manager and should be able to ship with other products which require life
>> cycle management.
>>
>> Proposed SolutionThe basic idea is to completely decouple the life cycle
>> framework from the system to which its provide life cycle capabilities. I.e
>> the system which uses life cycle will not change the behavior of the life
>> cycle framework and only vice versa will be applicable. The framework
>> should exist independent of the asset type to which it provides life cycle
>> capability
>>
>>
>> ​
>>
>>
>> The mapping should be maintained by asset type in order to associate with
>> life cycle data. To be more specific in database schema level each asset
>> type should update their tables (add extra columns to maintain mapping with
>> life cycle data) in order to map  life cycle data.
>>
>> The external systems which uses life cycle service should connect with
>> the service in order to have a unique life cycle id which is generated
>> by the service. This id should be stored in the external system in order to
>> maintain the mapping (Each asset should have its own life cycle id). On the
>> other hand life cycle framework will also store this id in order to provide
>> all the life cycle related operations for a particular asset.
>>
>>
>> ​
>>
>> Basically, we will be providing a class (ManagedLifecycle) with all the
>> required basic operations. Any asset which requires life cycle management
>> can extend this class.
>> Further this can be extended to support features like check list items as
>> well
>> Features supported
>>
>>-
>>
>>Custom Inputs - User should  provide with the capability in order to
>>save custom values per each state, which can be passed to executors .
>>- Executors - Which are custom classes executed during life cycle
>>state change operation
>>
>>
>> Please provide you valuable inputs.
>>
>> Thanks!
>> Rajith
>>
>> --
>> Rajith Roshan
>> Software Engineer, WSO2 Inc.
>> Mobile: +94-72-642-8350 <%2B94-71-554-8430>
>>
>


-- 
Rajith Roshan
Software Engineer, WSO2 Inc.
Mobile: +94-72-642-8350 <%2B94-71-554-8430>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [APIM] Life cycle Management

[Rajith Roshan]

Hi,

The current implementation keeps the data in a separate database. For now
life cycle  component has its own data source. I think its better to read
the data source name from a configuration so the tables related to life
cycle operations can be populated in an existing database as well. For ex:
if the config specifies the AM _DB then these tables will be created in API
Manager database, without using separate database.

Thanks!
Rajith

On Mon, Oct 10, 2016 at 3:49 PM, Prasanna Dangalla 
wrote:

>
> Hi Rajith,
>
> On Mon, Oct 10, 2016 at 3:30 PM, Rajith Roshan  wrote:
>
>> Hi,
>>>
>> please find the images below
>>
>>> On Mon, Oct 10, 2016 at 3:16 PM, Rajith Roshan  wrote:
>>>
>>>> Hi all,
>>>>
>>>> Life cycle is an integral part in any product. Each SOA governance
>>>> related artifacts can have their own life cycle. Capabilities provided in
>>>> order to manage life cycles not only allow you to properly organize your
>>>> assets but also provides many extensibilities (For ex through custom
>>>> executors)
>>>>
>>>> RequirementCurrent API life cycle of API manager completely depends
>>>>  on the life cycle implementation provided by the registry. Since we are
>>>> moving away from the registry concept we need a completely new life cycle
>>>> management framework which cater for life cycle management within API
>>>> Manager and should be able to ship with other products which require life
>>>> cycle management.
>>>>
>>>> Proposed SolutionThe basic idea is to completely decouple the life
>>>> cycle framework from the system to which its provide life cycle
>>>> capabilities. I.e the system which uses life cycle will not change the
>>>> behavior of the life cycle framework and only vice versa will be
>>>> applicable. The framework should exist independent of the asset type to
>>>> which it provides life cycle capability
>>>>
>>>>
>>>> ​
>>>>
>>>>
>>>> The mapping should be maintained by asset type in order to associate
>>>> with life cycle data. To be more specific in database schema level each
>>>> asset type should update their tables (add extra columns to maintain
>>>> mapping with life cycle data) in order to map  life cycle data.
>>>>
>>>> The external systems which uses life cycle service should connect with
>>>> the service in order to have a unique life cycle id which is generated
>>>> by the service. This id should be stored in the external system in order to
>>>> maintain the mapping (Each asset should have its own life cycle id). On the
>>>> other hand life cycle framework will also store this id in order to provide
>>>> all the life cycle related operations for a particular asset.
>>>>
>>>>
>>>> ​
>>>>
>>>> Basically, we will be providing a class (ManagedLifecycle) with all the
>>>> required basic operations. Any asset which requires life cycle management
>>>> can extend this class.
>>>> Further this can be extended to support features like check list items
>>>> as well
>>>> Features supported
>>>>
>>>>-
>>>>
>>>>Custom Inputs - User should  provide with the capability in order
>>>>to save custom values per each state, which can be passed to executors .
>>>>- Executors - Which are custom classes executed during life cycle
>>>>state change operation
>>>>
>>>>
>>>> Please provide you valuable inputs.
>>>>
>>>> Thanks!
>>>> Rajith
>>>>
>>>> --
>>>> Rajith Roshan
>>>> Software Engineer, WSO2 Inc.
>>>> Mobile: +94-72-642-8350 <%2B94-71-554-8430>
>>>>
>>>
>>
>>
>> --
>> Rajith Roshan
>> Software Engineer, WSO2 Inc.
>> Mobile: +94-72-642-8350 <%2B94-71-554-8430>
>>
>> ___
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
> Since this proposed feature is running separately, are we keeping the db
> tables in a separate database? If so, we can separate them from products
> and bind them to the feature. IMHO it will be an advantage.
>
> Regards,
>
> *Prasanna Dangalla*
> Senior Software Engineer, WSO2, Inc.; http://wso2.com/
> lean.enterprise.middleware
>
>
> *cell: +94 718 11 27 51*
> *twitter: @prasa77*
>
>


-- 
Rajith Roshan
Software Engineer, WSO2 Inc.
Mobile: +94-72-642-8350 <%2B94-71-554-8430>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [APIM] Life cycle Management

[Rajith Roshan]

Hi Chamila,

Thanks for pointing this out. I think its better to change the execute api
of Executor interface to throw an exception rather than returning a Boolean
value. So the custom error message can be passed to the UI as well.

Thanks!
Rajith

On Fri, Oct 21, 2016 at 10:23 AM, Chamila Adhikarinayake 
wrote:

> Hi Rajith,
>
> One of the limitation we saw with the existing executor implementation is
> its limitation in throwing the exception ( executor method does not throw
> exceptions and only return a boolean) . Are you planning to change it?
> Chamila
>
> On Mon, Oct 10, 2016 at 3:16 PM, Rajith Roshan  wrote:
>
>> Hi all,
>>
>> Life cycle is an integral part in any product. Each SOA governance
>> related artifacts can have their own life cycle. Capabilities provided in
>> order to manage life cycles not only allow you to properly organize your
>> assets but also provides many extensibilities (For ex through custom
>> executors)
>>
>> RequirementCurrent API life cycle of API manager completely depends  on
>> the life cycle implementation provided by the registry. Since we are moving
>> away from the registry concept we need a completely new life cycle
>> management framework which cater for life cycle management within API
>> Manager and should be able to ship with other products which require life
>> cycle management.
>>
>> Proposed SolutionThe basic idea is to completely decouple the life cycle
>> framework from the system to which its provide life cycle capabilities. I.e
>> the system which uses life cycle will not change the behavior of the life
>> cycle framework and only vice versa will be applicable. The framework
>> should exist independent of the asset type to which it provides life cycle
>> capability
>>
>>
>>
>>
>> The mapping should be maintained by asset type in order to associate with
>> life cycle data. To be more specific in database schema level each asset
>> type should update their tables (add extra columns to maintain mapping with
>> life cycle data) in order to map  life cycle data.
>>
>> The external systems which uses life cycle service should connect with
>> the service in order to have a unique life cycle id which is generated
>> by the service. This id should be stored in the external system in order to
>> maintain the mapping (Each asset should have its own life cycle id). On the
>> other hand life cycle framework will also store this id in order to provide
>> all the life cycle related operations for a particular asset.
>>
>>
>>
>> Basically, we will be providing a class (ManagedLifecycle) with all the
>> required basic operations. Any asset which requires life cycle management
>> can extend this class.
>> Further this can be extended to support features like check list items as
>> well
>> Features supported
>>
>>-
>>
>>Custom Inputs - User should  provide with the capability in order to
>>save custom values per each state, which can be passed to executors .
>>- Executors - Which are custom classes executed during life cycle
>>state change operation
>>
>>
>> Please provide you valuable inputs.
>>
>> Thanks!
>> Rajith
>>
>> --
>> Rajith Roshan
>> Software Engineer, WSO2 Inc.
>> Mobile: +94-72-642-8350 <%2B94-71-554-8430>
>>
>> ___
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
>
> --
> Regards,
> Chamila Adhikarinayake
> Software Engineer
> WSO2, Inc.
> Mobile - +94712346437
> Email  - chami...@wso2.com
> Blog  -  http://helpfromadhi.blogspot.com/
>



-- 
Rajith Roshan
Software Engineer, WSO2 Inc.
Mobile: +94-72-642-8350 <%2B94-71-554-8430>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

[Architecture] [C5][APIM] Full Text Search

[Rajith Roshan]

Hi all,

We are currently evaluating how to perform full text search at the database
level for C5 based API Manager. We will be evaluating this for different
types of databases to find their implementation complexities and
limitations.
Other option available for us to use indexing based approach (use Solr)

*Database full text search *
*Pros*

   - Less complications when using container based approach
   - Clustering will require only database syncing.
   - No need to maintain and ship external search engine.

*Cons*

   - Implementation may vary significantly based on the database type
   - There can be limitation in full text search for particular database
   types (For ex: mysql full text support only prefix search)
   - Queries will differ based on database type
   - Document search will not be available, because they are stored as
   blobs


*Indexing based approach *
*Pros*

   - Document search
   - Search will be efficient (No need to access database)

*Cons*

   - Since indexing data is written to file system , when going for
   container based approach we would require mechanisms to file system mounting
   - Syncing indexers in a cluster would require something similar to
   existing C4 based registry architecture (use of REG_LOG table)
   - Maintaining (for ex: Version updates) and shipping external search
   engine.

Your valuable input regrading this is highly appreciated.

Thanks!
Rajith

-- 
Rajith Roshan
Software Engineer, WSO2 Inc.
Mobile: +94-72-642-8350 <%2B94-71-554-8430>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [C5][APIM] Full Text Search

[Rajith Roshan]

Hi Malith,

Thanks for your input. I have changed the jmeter scripts according to you
instructions.
I was using a oracle docker instance in my local machine. I have changed it
to a remote oracle database. Now the latency is much less. I will share all
the performance numbers once I have finished collecting them for oracle,
mssql, mysql and postgres databases.

Thanks!
Rajith

On Tue, Jan 24, 2017 at 9:46 AM, Malith Jayasinghe  wrote:

> @Rajith
>
> As per the offline discussion we had regarding the performance evaluation
> (using JMETER) of the two methods:
> - use 2 separate thread groups for evaluating the performance of 2 DB
> based search methods
> - run each thread group sequentially
> - run the test for a longer period under different concurrency level and
> record the latency and TPS
>
> With regard to the long latencies you are noticing, we need to figure out
> if this is related to the database query/queries or something else. To do a
> quick test: simply log the execution time of the query/queries. If the
> execution times are high (or have spikes) then we can try to optimize the
> DB query. Otherwise we have to do some further investigations.
>
> Thanks
>
> Malith
>
>
>
>
>
>
> On Sat, Jan 14, 2017 at 10:43 PM, Nuwan Dias  wrote:
>
>> File system based indexers bring new challenges in the container world.
>> It also poses challenges in HA (multinode) and multi regional deployments.
>> Therefore if we're selecting a solr indexing approach, the only practical
>> solution is to go with a solr server based architecture.
>>
>> Even with a solr server assisted architecture, we still have complexities
>> when dealing with multi regional deployments. Also since API artifacts
>> reside in the database, if we're loading search results from an index, we
>> have to sync the permissions of the artifacts in the index too. Plus this
>> makes the deployment complex.
>>
>> Given the complexities that have to be addressed in an indexing solution,
>> I'd prefer to opt with the DB based search at least to start off with.
>> Since APIs and their permissions are both maintained in the DB, it would be
>> much simple if the search also works on that. Unlike in C4 this database
>> will only have data of 1 tenant. Hence we're not expecting the API count to
>> be in the thousands. Therefore I think searching through the database
>> should be feasible.
>>
>> Thanks,
>> NuwanD.
>>
>> On Sat, 14 Jan 2017 at 8:27 am, Chandana Napagoda 
>> wrote:
>>
>>> Hi Rajith,
>>>
>>> I believe indexing based approach is more suitable for any search
>>> solution because its design is to support fast search results. If you use
>>> database search, you have to use multiple DB indexes to improve search
>>> performance, and that will reduce the performance of insert operations.
>>>
>>> I think, REG_LOG kind of history table is not necessary for APIM
>>> product, since it is totally aware of the APIM artifacts(APIs, Docs, forum
>>> posts) and you can directly connect to the DB[1] from the text search
>>> engine and index the resources. As per the Solr documentation, it is
>>> capable of importing only the new additions(delta) for indexing.
>>>
>>> [1]. https://cwiki.apache.org/confluence/display/solr/Uploading+
>>> Structured+Data+Store+Data+with+the+Data+Import+Handler
>>>
>>> Regards,
>>> Chandana
>>>
>>>
>>> On Fri, Jan 13, 2017 at 11:44 AM, Rajith Roshan 
>>> wrote:
>>>
>>> Hi all,
>>>
>>> We are currently evaluating how to perform full text search at the
>>> database level for C5 based API Manager. We will be evaluating this for
>>> different types of databases to find their implementation complexities and
>>> limitations.
>>> Other option available for us to use indexing based approach (use Solr)
>>>
>>> *Database full text search *
>>> *Pros*
>>>
>>>- Less complications when using container based approach
>>>- Clustering will require only database syncing.
>>>- No need to maintain and ship external search engine.
>>>
>>> *Cons*
>>>
>>>- Implementation may vary significantly based on the database type
>>>- There can be limitation in full text search for particular
>>>database types (For ex: mysql full text support only prefix search)
>>>- Queries will differ based on database type
>>>- Document search will not be available, because they are stored as
>&g

Re: [Architecture] [C5][APIM] Full Text Search

[Rajith Roshan]

Hi all,

We have integrated full text search to the api manager C5 server. We
implemented full text search and attribute search for Oracle, MsSQL, MySQL,
Postgres, and H2.

*Full text search *: Search will be done for apis regardless of the
attribute of the api. Full text indexes will be created for AM_API table.
The indexes will include the columns which will be used in the full text
search. The indexing and querying process differ from database to database.
Sample curl full text query would be as follows

"curl  -H "Authorization: Basic YWRtaW46YWRtaW4="
http://127.0.0.1:9090/api/am/store/v0.10/apis?*query="test*
&offset=1&limit=10""

*Attribute search* : This will be used to search APIS based on their
attributes (metadata). This is implemented as usual SQL "Like" queries.
Sample curl command would be as follows.

"curl  -H "Authorization: Basic YWRtaW46YWRtaW4="
http://127.0.0.1:9090/api/am/store/v0.10/apis?
*query="name:test,version:8.0.0*&offset=1&limit=10""

We have carried out latency test for MsSQL [1], Oracle [2], Postgres [3],
and MySQL [4] databases using different number of APIS and with different
concurrency levels .
Even for 10,000 API s all the databases shows manageable latency (10,000
APIS can be a very rare case for single tenant).

Please share your thoughts on the latency for full text search and
attribute search

[1] -
https://docs.google.com/a/wso2.com/spreadsheets/d/1fhwz5T-cIZzhpgs2Np6eQIeBN2yyB55EgWLXGtXjABg/edit?usp=sharing
[2] -
https://docs.google.com/a/wso2.com/spreadsheets/d/18qW6OeH9d7VFq1d6GaCRFQV09I9rbmmJq0EVrTqwb-M/edit?usp=sharing
[3] -
https://docs.google.com/a/wso2.com/spreadsheets/d/11okKYYeAz8OY7_2VAYnlqbwh79sog5bkplnZEsnPeQo/edit?usp=sharing
[4] -
https://docs.google.com/a/wso2.com/spreadsheets/d/1r0b9YlEGZ5VTFbPatTW14WBLBoDB7l6ecmK7arqS4KA/edit?usp=sharing


Thanks!
Rajith

On Tue, Jan 24, 2017 at 1:10 PM, Malith Jayasinghe  wrote:

> Ok. You could also consider writing a small micro bench-mark and get the
> performance numbers (instead of testing this using an external load
> generator). This will minimize the impact of other components/layers on the
> results.
>
> On Tue, Jan 24, 2017 at 9:56 AM, Rajith Roshan  wrote:
>
>> Hi Malith,
>>
>> Thanks for your input. I have changed the jmeter scripts according to you
>> instructions.
>> I was using a oracle docker instance in my local machine. I have changed
>> it to a remote oracle database. Now the latency is much less. I will share
>> all the performance numbers once I have finished collecting them for
>> oracle, mssql, mysql and postgres databases.
>>
>> Thanks!
>> Rajith
>>
>> On Tue, Jan 24, 2017 at 9:46 AM, Malith Jayasinghe 
>> wrote:
>>
>>> @Rajith
>>>
>>> As per the offline discussion we had regarding the performance
>>> evaluation (using JMETER) of the two methods:
>>> - use 2 separate thread groups for evaluating the performance of 2 DB
>>> based search methods
>>> - run each thread group sequentially
>>> - run the test for a longer period under different concurrency level and
>>> record the latency and TPS
>>>
>>> With regard to the long latencies you are noticing, we need to figure
>>> out if this is related to the database query/queries or something else. To
>>> do a quick test: simply log the execution time of the query/queries. If the
>>> execution times are high (or have spikes) then we can try to optimize the
>>> DB query. Otherwise we have to do some further investigations.
>>>
>>> Thanks
>>>
>>> Malith
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Sat, Jan 14, 2017 at 10:43 PM, Nuwan Dias  wrote:
>>>
>>>> File system based indexers bring new challenges in the container world.
>>>> It also poses challenges in HA (multinode) and multi regional deployments.
>>>> Therefore if we're selecting a solr indexing approach, the only practical
>>>> solution is to go with a solr server based architecture.
>>>>
>>>> Even with a solr server assisted architecture, we still have
>>>> complexities when dealing with multi regional deployments. Also since API
>>>> artifacts reside in the database, if we're loading search results from an
>>>> index, we have to sync the permissions of the artifacts in the index too.
>>>> Plus this makes the deployment complex.
>>>>
>>>> Given the complexities that have to be addressed in an indexing
>>>> solution, I'd prefer to opt with the DB based search at least to start off
>>>> w

Re: [Architecture] [VOTE] Release WSO2 API Manager 2.1.0 RC4

[Rajith Roshan]

Hi,

Tested API manager with third party key manager.

[+] Stable - go ahead and release


Thanks!
Rajith

On Tue, Jan 31, 2017 at 12:23 PM, Anuruddha Liyanarachchi <
anurudd...@wso2.com> wrote:

> Hi,
>
> Tested following:
>
> 1. Websocket API create, publish and invocation.
> 2. SOAP endpoint API create, publish and invocation.
>
> [+] Stable - go ahead and release
>
> On Mon, Jan 30, 2017 at 10:28 PM, Malintha Amarasinghe  > wrote:
>
>> Hi All,
>>
>> This is the 4th Release Candidate of WSO2 API Manager 2.1.0
>>
>> Please download, test the product and vote. The vote will be open for 72
>> hours or as needed.
>>
>> Source and distribution
>>
>> Run-time : https://github.com/wso2/product-apim/releases/download/v2.
>> 1.0-rc4/wso2am-2.1.0-RC4.zip
>> Analytics : https://github.com/wso2/anal
>> ytics-apim/releases/download/v2.1.0-rc3/wso2am-analytics-2.1.0-RC3.zip
>> Tooling : https://github.com/wso2/devstudio-tooling-apim/releases/ta
>> g/v2.1.0-rc2
>>
>>
>> This release fixes the following issues:
>> Runtime : https://wso2.org/jira/issues/?filter=13623
>> Analytics : https://wso2.org/jira/issues/?filter=13624
>> Tooling : https://wso2.org/jira/browse/DEVTOOLAPI-1
>>
>>
>> Please vote as follows.
>> [+] Stable - go ahead and release
>> [-] Broken - do not release (explain why)
>>
>> Thanks,
>> - WSO2 API Manager Team -
>>
>> --
>> Malintha Amarasinghe
>> Software Engineer
>> *WSO2, Inc. - lean | enterprise | middleware*
>> http://wso2.com/
>>
>> Mobile : +94 712383306 <+94%2071%20238%203306>
>>
>> ___
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
>
> --
> *Thanks and Regards,*
> Anuruddha Lanka Liyanarachchi
> Software Engineer - WSO2
> Mobile : +94 (0) 712762611
> Tel  : +94 112 145 345
> a nurudd...@wso2.com
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 
Rajith Roshan
Software Engineer, WSO2 Inc.
Mobile: +94-72-642-8350 <%2B94-71-554-8430>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [APIM 3.0.0][C5] Permission model : Visibility and subscription availability

[Rajith Roshan]

Hi,

AFAIU we apply permission for API entity. API does not know anything about
publisher and store. The permission model (Role/group based ) should handle
the visibility at the store and publisher. The permission assigned to API
should be generic. There should not be separate permissions for publisher
and store in the API. If we are keeping  two sets of permission for API,
then we are binding the API entity to publisher and store. I think that is
not a good design.

Thanks!
Rajith

On Wed, Mar 15, 2017 at 10:47 AM, Pubudu Gunatilaka 
wrote:

> Hi,
>
> Based on the recent queries we got, users try to bring the tenancy model
> for managing APIs. For an example there can be two developers who create
> APIs for two departments such as marketing and enginnering. Basic idea is
> that those APIs are only visible for particular group in store which we can
> achieve. On the other hand same thing is expected in publisher side as well.
>
> Only concern I see here is whether we support this kind of a separation in
> APIM 3.0.
>
> Thank you!
>
>
> On Wed, Mar 15, 2017 at 9:54 AM Roshan Wijesena  wrote:
>
>>
>> On Wed, Mar 15, 2017 at 12:48 AM, Uvindra Dias Jayasinha <
>> uvin...@wso2.com> wrote:
>>
>> How can we support this by only sticking to the new permission model? We
>> need to make the API visible in the store side but hide it on the publisher
>> side(other publisher users).
>>
>>
>> As I understood, your requirement is to hide an API from other developers
>> in publisher but in the store that should be visible to everyone is it? In
>> that case, if other publishers log into the store they still can see other
>> APIs no?
>>
>>
>> --
>> Roshan Wijesena.
>> Senior Software Engineer-WSO2 Inc.
>> Mobile: *+94719154640 <+94%2071%20915%204640>*
>> Email: ros...@wso2.com
>> *WSO2, Inc. :** wso2.com <http://wso2.com/>*
>> lean.enterprise.middleware.
>> ___
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
> --
> *Pubudu Gunatilaka*
> Committer and PMC Member - Apache Stratos
> Software Engineer
> WSO2, Inc.: http://wso2.com
> mobile : +94774078049
>
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 
Rajith Roshan
Software Engineer, WSO2 Inc.
Mobile: +94-72-642-8350 <%2B94-71-554-8430>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [APIM][C5] API Editor Application

[Rajith Roshan]

Hi,


On Wed, May 17, 2017 at 11:44 AM, Tharika Madurapperuma 
wrote:

> Hi all,
>
>   In API Manager, we will be exposing an application called the API
> Editor which is basically a subset of the API Publisher. The Editor
> application is *run locally* in the API developers machine and is used
> primarily for API *testing purposes*.
>
> What can be done through the Editor Application?
>
>
>- APIs will be created and stored in the local file system.
>
>   The file structure of the created API will be,
>
>   [image: Inline image 1]
>
>  where *--* is the folder in
> which the configuration files for the API are stored. The Endpoints folder
> contains the api level endpoints for the API.
>
>- API level endpoints are used instead of global endpoints.
>- After creating and testing an API from within the API Editor, the
>API developer can export the API to the Publisher.
>- It supports API import and export.
>
> Is it necessary to support import feature on the editor. Is there a valid
use case to import apis into editor.

>
>-
>- The API can be exported as a zip file and it contains the above file
>structure.
>
> Appreciate your thoughts and concerns.
>
> Thanks,
> Tharika.
>
> --
> *Tharika Madurapperuma*
> Software Engineer | WSO2, Inc.
>
> Email : thar...@wso2.com
> Mobile : +94777875624 <+94%2077%20787%205624>
> Web : http://wso2.com
>
> <http://wso2.com/signature>
>



-- 
Rajith Roshan
Software Engineer, WSO2 Inc.
Mobile: +94-7 <%2B94-71-554-8430>17-064-214
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [MB] Best Approach to write unit tests for DAO Layer ?

[Rajith Roshan]

;>>>>>>>> On Thu, May 18, 2017 at 10:23 AM, Pamod Sylvester <
>>>>>>>>>>>>>> pa...@wso2.com> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Hi All,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> When unit testing DAO layers what will be the best approach
>>>>>>>>>>>>>>> we should be using ? some of the approaches would be the 
>>>>>>>>>>>>>>> following,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 1. Use an in-memory database ? (h2,Derby or HSSQLDB)
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> *Pros*
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>  - Easy to configure
>>>>>>>>>>>>>>>  - SQL query executions will be covered
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> *Cons*
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>  - As mention in [1] tests will be specific to cover only
>>>>>>>>>>>>>>> the features covered specific to the database which is being 
>>>>>>>>>>>>>>> used (i.e h2)
>>>>>>>>>>>>>>>  - Could also be thought of as an anti pattern for unit
>>>>>>>>>>>>>>> tests (though it's an in-memory database this could be 
>>>>>>>>>>>>>>> considered as an
>>>>>>>>>>>>>>> external system)
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 2. Mock DB instance
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> *Pros*
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> - Since the control is on our side we could overcome the
>>>>>>>>>>>>>>> cons mentioned in the 1st approach.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> *Cons*
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> - Could make the implementation more complex in comparison
>>>>>>>>>>>>>>> to the 1st approach
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Currently IMO option 1 would be a better option. Since
>>>>>>>>>>>>>>> currently our code is based on ANSI SQL and we don't have 
>>>>>>>>>>>>>>> triggers, PLSQL
>>>>>>>>>>>>>>> (which will be database specific syntax which will require us 
>>>>>>>>>>>>>>> to do mocks).
>>>>>>>>>>>>>>> thoughts ? will there be a better option ?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> [1] https://blog.jooq.org/tag/unit-testing/
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>> Pamod
>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>> *Pamod Sylvester *
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> *WSO2 Inc.; http://wso2.com <http://wso2.com>*
>>>>>>>>>>>>>>> cell: +94 77 7779495 <+94%2077%20777%209495>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> *Manuri Amaya Perera*
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> *Software Engineer*
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> *WSO2 Inc.*
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> *Blog: http://manuriamayaperera.blogspot.com
>>>>>>>>>>>>>> <http://manuriamayaperera.blogspot.com>*
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> --
>>>>>>>>>>>>> *Hasitha Abeykoon*
>>>>>>>>>>>>> Senior Software Engineer; WSO2, Inc.; http://wso2.com
>>>>>>>>>>>>> *cell:* *+94 719363063*
>>>>>>>>>>>>> *blog: **abeykoon.blogspot.com* <http://abeykoon.blogspot.com>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>> Thanks & Regards,
>>>>>>>>>>>>
>>>>>>>>>>>> Fazlan Nazeem
>>>>>>>>>>>>
>>>>>>>>>>>> *Senior Software Engineer*
>>>>>>>>>>>>
>>>>>>>>>>>> *WSO2 Inc*
>>>>>>>>>>>> Mobile : +94772338839
>>>>>>>>>>>> <%2B94%20%280%29%20773%20451194>
>>>>>>>>>>>> fazl...@wso2.com
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> Ramith Jayasinghe
>>>>>>>>>>> Technical Lead
>>>>>>>>>>> WSO2 Inc., http://wso2.com
>>>>>>>>>>> lean.enterprise.middleware
>>>>>>>>>>>
>>>>>>>>>>> E: ram...@wso2.com
>>>>>>>>>>> P: +94 777542851 <+94%2077%20754%202851>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>>
>>>>>>>>>> *Manuri Amaya Perera*
>>>>>>>>>>
>>>>>>>>>> *Software Engineer*
>>>>>>>>>>
>>>>>>>>>> *WSO2 Inc.*
>>>>>>>>>>
>>>>>>>>>> *Blog: http://manuriamayaperera.blogspot.com
>>>>>>>>>> <http://manuriamayaperera.blogspot.com>*
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Ramith Jayasinghe
>>>>>>>>> Technical Lead
>>>>>>>>> WSO2 Inc., http://wso2.com
>>>>>>>>> lean.enterprise.middleware
>>>>>>>>>
>>>>>>>>> E: ram...@wso2.com
>>>>>>>>> P: +94 777542851 <+94%2077%20754%202851>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Asanka Abeyweera
>>>>>>>> Senior Software Engineer
>>>>>>>> WSO2 Inc.
>>>>>>>>
>>>>>>>> Phone: +94 712228648 <071%20222%208648>
>>>>>>>> Blog: a5anka.github.io
>>>>>>>>
>>>>>>>> <https://wso2.com/signature>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> *Pamod Sylvester *
>>>>>>>
>>>>>>> *WSO2 Inc.; http://wso2.com <http://wso2.com>*
>>>>>>> cell: +94 77 7779495 <+94%2077%20777%209495>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Pumudu Ruhunage
>>>>>> Software Engineer | WSO2 Inc
>>>>>> M: +94 779 664493  | http://wso2.com
>>>>>> <https://wso2.com/signature>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Asanka Abeyweera
>>>>> Senior Software Engineer
>>>>> WSO2 Inc.
>>>>>
>>>>> Phone: +94 712228648 <+94%2071%20222%208648>
>>>>> Blog: a5anka.github.io
>>>>>
>>>>> <https://wso2.com/signature>
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Sanjiva Weerawarana, Ph.D.
>>>> Founder, CEO & Chief Architect; WSO2, Inc.;  http://wso2.com/
>>>> email: sanj...@wso2.com; office: (+1 650 745 4499 <(650)%20745-4499> |
>>>> +94  11 214 5345) x5700; cell: +94 77 787 6880 <+94%2077%20787%206880>
>>>> | +1 408 466 5099 <(408)%20466-5099>; voip: +1 650 265 8311
>>>> <(650)%20265-8311>; twitter: @sanjiva
>>>> Lean . Enterprise . Middleware
>>>>
>>>
>>>
>>>
>>> --
>>> Regards,
>>> Uvindra
>>>
>>> Mobile: 33962
>>>
>>> ___
>>> Architecture mailing list
>>> Architecture@wso2.org
>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>
>>>
>>
>>
>> --
>> Malaka.
>> --
>> Malaka Gangananda - Software Engineer | WSO2
>> Email : mala...@wso2.com
>> Mobile : +94713564340 <071%20356%204340>
>> Web : http://wso2.com
>>   <http://wso2.com/signature>
>>
>> ___
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
>
> --
>
> Dharshana Warusavitharana
> Associate Technical Lead
> WSO2 Inc. http://wso2.com
> email : dharsha...@wso2.com 
> Tel  : +94 11 214 5345
> Fax :+94 11 2145300 <+94%2011%202%20145300>
> cell : +94770342233 <+94%2077%20034%202233>
> blog : http://dharshanaw.blogspot.com
>
> lean . enterprise . middleware
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 
Rajith Roshan
Software Engineer, WSO2 Inc.
Mobile: +94-7 <%2B94-71-554-8430>17-064-214
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [APIM][C5] Multi Environment support with API difference for API Manager

[Rajith Roshan]

t;>>>>>   - Sample deployment.yaml
>>>>>>   -
>>>>>>
>>>>>>   wso2.carbon.apimgt.environments:
>>>>>> environmentName: Default
>>>>>> environments:
>>>>>> - host: dev.sample.com:9292
>>>>>>   loginTokenPath: /login/token
>>>>>>   label: Development
>>>>>>
>>>>>>
>>>>>>
>>>>> What's he dfference between environmentName and environments.label?
>>>>> (If environmentName represents the current environment, souldn't it
>>>>> be one of environments.labels?)
>>>>>
>>>>> Thanks,
>>>>> Bhathiya
>>>>>
>>>>>>
>>>>>>-
>>>>>>
>>>>>>
>>>>>>
>>>>>> - host: prod.sample.com:9292
>>>>>>   loginTokenPath: /login/token
>>>>>>   label: Production
>>>>>>
>>>>>>   1. Serve environments' details as JSON.
>>>>>>   - Browser then render a list of environments.
>>>>>>2. Send request with user credentials to the proper environment
>>>>>>to login.
>>>>>>3. The environment read its deployment.yaml to know the name of
>>>>>>itself and set cookies with appending the name to the cookie name.
>>>>>>
>>>>>> [1] https://github.com/wso2/carbon-apimgt/issues/4690
>>>>>> [2] https://github.com/wso2/carbon-apimgt/pull/4679
>>>>>>
>>>>>>
>>>>>> Appreciate any suggestions.
>>>>>> Thanks
>>>>>>
>>>>>> Best regards
>>>>>>
>>>>>> --
>>>>>> *Renuka Fernando*
>>>>>> Software Engineering Intern | WSO2 Inc
>>>>>>
>>>>>> Email : ren...@wso2.com
>>>>>> Mobile : +94 76 667 8752 <076%20667%208752>
>>>>>> Web : http://wso2.com
>>>>>> <http://wso2.com/signature>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> *Bhathiya Jayasekara*
>>>>> *Associate Technical Lead,*
>>>>> *WSO2 inc., http://wso2.com <http://wso2.com>*
>>>>>
>>>>> *Phone: +94715478185 <+94%2071%20547%208185>*
>>>>> *LinkedIn: http://www.linkedin.com/in/bhathiyaj
>>>>> <http://www.linkedin.com/in/bhathiyaj>*
>>>>> *Twitter: https://twitter.com/bhathiyax
>>>>> <https://twitter.com/bhathiyax>*
>>>>> *Blog: http://movingaheadblog.blogspot.com
>>>>> <http://movingaheadblog.blogspot.com/>*
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Chamin Dias
>>>> Mobile : 0716097455 <071%20609%207455>
>>>> Email : cham...@wso2.com
>>>> LinkedIn : https://www.linkedin.com/in/chamindias
>>>>
>>>>
>>>
>>>
>>> --
>>> *Pubudu Gunatilaka*
>>> Committer and PMC Member - Apache Stratos
>>> Senior Software Engineer
>>> WSO2, Inc.: http://wso2.com
>>> mobile : +94774078049 <%2B94772207163>
>>>
>>>
>>
>>
>> --
>> *Renuka Fernando*
>> Software Engineering Intern | WSO2 Inc
>>
>> Email : ren...@wso2.com
>> Mobile : +94 76 667 8752 <076%20667%208752>
>> Web : http://wso2.com
>> <http://wso2.com/signature>
>>
>
>
>
> --
> *Bhathiya Jayasekara*
> *Associate Technical Lead,*
> *WSO2 inc., http://wso2.com <http://wso2.com>*
>
> *Phone: +94715478185 <+94%2071%20547%208185>*
> *LinkedIn: http://www.linkedin.com/in/bhathiyaj
> <http://www.linkedin.com/in/bhathiyaj>*
> *Twitter: https://twitter.com/bhathiyax <https://twitter.com/bhathiyax>*
> *Blog: http://movingaheadblog.blogspot.com
> <http://movingaheadblog.blogspot.com/>*
>



-- 
Rajith Roshan
Senior Software Engineer, WSO2 Inc.
Mobile: +94-7 <%2B94-71-554-8430>17-064-214
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [APIM][C5] Multi Environment support with API difference for API Manager

[Rajith Roshan]

  - Sample deployment.yaml
>>>>>>>   -
>>>>>>>
>>>>>>>   wso2.carbon.apimgt.environments:
>>>>>>> environmentName: Default
>>>>>>> environments:
>>>>>>> - host: dev.sample.com:9292
>>>>>>>   loginTokenPath: /login/token
>>>>>>>   label: Development
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> What's he dfference between environmentName and environments.label?
>>>>>> (If environmentName represents the current environment, souldn't it
>>>>>> be one of environments.labels?)
>>>>>>
>>>>>> Thanks,
>>>>>> Bhathiya
>>>>>>
>>>>>>>
>>>>>>>-
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> - host: prod.sample.com:9292
>>>>>>>   loginTokenPath: /login/token
>>>>>>>   label: Production
>>>>>>>
>>>>>>>   1. Serve environments' details as JSON.
>>>>>>>   - Browser then render a list of environments.
>>>>>>>2. Send request with user credentials to the proper environment
>>>>>>>to login.
>>>>>>>3. The environment read its deployment.yaml to know the name of
>>>>>>>itself and set cookies with appending the name to the cookie name.
>>>>>>>
>>>>>>> [1] https://github.com/wso2/carbon-apimgt/issues/4690
>>>>>>> [2] https://github.com/wso2/carbon-apimgt/pull/4679
>>>>>>>
>>>>>>>
>>>>>>> Appreciate any suggestions.
>>>>>>> Thanks
>>>>>>>
>>>>>>> Best regards
>>>>>>>
>>>>>>> --
>>>>>>> *Renuka Fernando*
>>>>>>> Software Engineering Intern | WSO2 Inc
>>>>>>>
>>>>>>> Email : ren...@wso2.com
>>>>>>> Mobile : +94 76 667 8752 <076%20667%208752>
>>>>>>> Web : http://wso2.com
>>>>>>> <http://wso2.com/signature>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> *Bhathiya Jayasekara*
>>>>>> *Associate Technical Lead,*
>>>>>> *WSO2 inc., http://wso2.com <http://wso2.com>*
>>>>>>
>>>>>> *Phone: +94715478185 <+94%2071%20547%208185>*
>>>>>> *LinkedIn: http://www.linkedin.com/in/bhathiyaj
>>>>>> <http://www.linkedin.com/in/bhathiyaj>*
>>>>>> *Twitter: https://twitter.com/bhathiyax
>>>>>> <https://twitter.com/bhathiyax>*
>>>>>> *Blog: http://movingaheadblog.blogspot.com
>>>>>> <http://movingaheadblog.blogspot.com/>*
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Chamin Dias
>>>>> Mobile : 0716097455 <071%20609%207455>
>>>>> Email : cham...@wso2.com
>>>>> LinkedIn : https://www.linkedin.com/in/chamindias
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> *Pubudu Gunatilaka*
>>>> Committer and PMC Member - Apache Stratos
>>>> Senior Software Engineer
>>>> WSO2, Inc.: http://wso2.com
>>>> mobile : +94774078049 <%2B94772207163>
>>>>
>>>>
>>>
>>>
>>> --
>>> *Renuka Fernando*
>>> Software Engineering Intern | WSO2 Inc
>>>
>>> Email : ren...@wso2.com
>>> Mobile : +94 76 667 8752 <076%20667%208752>
>>> Web : http://wso2.com
>>> <http://wso2.com/signature>
>>>
>>
>>
>>
>> --
>>
>> *Sanjeewa Malalgoda*
>> WSO2 Inc.
>> Mobile : +94713068779 <+94%2071%20306%208779>
>>
>> <http://sanjeewamalalgoda.blogspot.com/>blog
>> :http://sanjeewamalalgoda.blogspot.com/
>> <http://sanjeewamalalgoda.blogspot.com/>
>>
>>
>>
>
>
> --
> Thanks
> Abimaran Kugathasan
> Senior Software Engineer - API Technologies
>
> Email : abima...@wso2.com
> Mobile : +94 773922820 <+94%2077%20392%202820>
>
> <http://stackoverflow.com/users/515034>
> <http://lk.linkedin.com/in/abimaran>
> <http://www.lkabimaran.blogspot.com/>  <https://github.com/abimarank>
> <https://twitter.com/abimaran>
>
>


-- 
Rajith Roshan
Senior Software Engineer, WSO2 Inc.
Mobile: +94-7 <%2B94-71-554-8430>17-064-214
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [APIM] [C5] Implementing Multi-Attribute Search for Publisher

[Rajith Roshan]

Hi Menuka

On Mon, Nov 13, 2017 at 2:45 PM, Menuka Warushavithana 
wrote:

> Hi all,
>
> I'm working on implementing a CLI application for importing and exporting
> APIs between different API environments [1] as for my internship project --
> where I need to query APIs (from the publisher) with respect to the name of
> the API *AND *the version of the API.
>
> Example: name:sampleapi&version:1.0.0
>
> However, as of now, APIM 3.0.0 Publisher supports full text search only.
> Therefore I started implementing multi-attribute search for Publisher in
> API Manager 3.0.0 and opened a pull request [2]. I have not touched the
> database layer for this implementation since there needs to be a review of
> the design for this particular feature.
>
In the DAO layer attribute search is supported[1] . You can call the same
method from the publisher impl layer.

> My concerns are as follows.
>
>- Should there be a limit to the number of attributes? i.e. Do we need
>to support a query like 
> "name:sampleapi&version:1.0.0&provider:admin&LifeCycleStatus:created"
>where four attributes are used for querying?
>
> Yes, the method[1] is written in way to support this type of queries.

>
>- Even though the character  '&' is used for separating fields (for
>clear representation), it's confusing to use '&' in the URL as it's used
>for separating GET parameters. So what should be the delimiter to be used
>in place of '&' ? [ I'm suggesting "," (the comma) ]
>   - Example: 'name:sampleapi,version:1.0.0,provider:admin,
>   LifeCycleStatus:created'
>- Do the changes I have made in [2] need to be altered so that it can
>be used to support further use cases?
>
>
> Suggestions are appreciated.
>
> [1] https://github.com/menuka94/product-apim-tooling/
> tree/master/import-export-cli
> [2] https://github.com/wso2/carbon-apimgt/pull/4712
>

[1] -
https://github.com/wso2/carbon-apimgt/blob/master/components/apimgt/org.wso2.carbon.apimgt.core/src/main/java/org/wso2/carbon/apimgt/core/dao/impl/ApiDAOImpl.java#L464


>
>
> Thanks and Regards
>
> *Menuka Warushavithana*
> *Software Engineering Intern*
> *WSO2*
>
> *Moblie:  + <%2B%2094%2011%202145345%20%C2%A0Ext.%205737> 94 77
> 6979690*
> *LinkedIn:   **https://www.linkedin.com/in/menukawarushavithana/
> <https://www.linkedin.com/in/menukawarushavithana/>*
> *GitHub:  **https://github.com/menuka94/
> <https://github.com/menuka94/>*
>
>
>


-- 
Rajith Roshan
Senior Software Engineer, WSO2 Inc.
Mobile: +94-7 <%2B94-71-554-8430>17-064-214
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Base paths to use for the APIs exposed from carbon-auth

[Rajith Roshan]

Hi

On Mon, Jan 8, 2018 at 7:53 PM, Pubudu Gunatilaka  wrote:

> Hi Malintha,
>
> Shouldn't we adhere to the existing APIs [1], [2] in Identity Server 5.x
> at the moment? Otherwise, users who have written applications based on the
> existing APIs won't be able to migrate easily. If I am not mistaken, C5
> based Identity Server is based on carbon-auth.
>
Yes, agree with Pubudu. If customers have written client applications based
on the existing apis, then they will have to release a new version of their
client application when they are migrating to new APIM 3.0

>
> [1] - https://docs.wso2.com/display/IS540/apidocs/OAuth2-dynamic-
> client-registration/#!/operations#OAuthDCR#registerApplication
> <https://docs.wso2.com/display/IS540/apidocs/OAuth2-dynamic-client-registration/#!/operations%23OAuthDCR%23registerApplication>
> [2] - https://docs.wso2.com/display/IS540/SCIM+2.0+REST+APIs
>
> Thank you!
>
> On Mon, Jan 8, 2018 at 7:34 PM, Malintha Amarasinghe 
> wrote:
>
>> - apim-group, +architecture
>> On Mon, Jan 8, 2018 at 7:21 PM, Malintha Amarasinghe 
>> wrote:
>>
>>> Hi All,
>>>
>>> The carbon-auth [1] component we are currently working on exposing a set
>>> of APIs for authentication/authorization purposes. This is to propose a set
>>> of base paths to be used on those APIs.
>>>
>>> As a convention we have been using below format when defining base paths
>>> for the currently available REST APIs in API Manager:
>>>
>>> /api/**/**/v**
>>>
>>> eg: /api/am/publisher/v1.0
>>>
>>> Below are the suggested basepaths:
>>>
>>> 1. Client Registration and Management REST API
>>> /api/auth/dcr/v1.0
>>>
>>> 2. OAuth REST API
>>> /api/auth/oauth/v1.0
>>>
>>> 3. SCIM REST API
>>> /api/auth/scim/v1.0
>>>
>>> 4. Scope Registration REST API
>>> /api/auth/scope-registration/v1.0
>>>
>>> 5. Token Introspection REST API
>>> /api/auth/introspect/v1.0
>>>
>>>
>>> *Note:* I have used "auth" instead of the product name.
>>>
>>> Appreciate your thoughts on this.
>>>
>>> [1] https://github.com/wso2/carbon-auth
>>>
>>> Thanks!
>>> Malintha
>>>
>>> --
>>> Malintha Amarasinghe
>>> *WSO2, Inc. - lean | enterprise | middleware*
>>> http://wso2.com/
>>>
>>> Mobile : +94 712383306 <+94%2071%20238%203306>
>>>
>>
>>
>>
>> --
>> Malintha Amarasinghe
>> *WSO2, Inc. - lean | enterprise | middleware*
>> http://wso2.com/
>>
>> Mobile : +94 712383306 <+94%2071%20238%203306>
>>
>> ___
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
>
> --
> *Pubudu Gunatilaka*
> Committer and PMC Member - Apache Stratos
> Senior 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
>
>


-- 
Rajith Roshan
Senior Software Engineer, WSO2 Inc.
Mobile: +94-7 <%2B94-71-554-8430>17-064-214
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

[Architecture] [G-Reg] Enabling G-Reg Publisher and Store in separate cluster domains

[Rajith Roshan]

Hi all,

*Problem*

In present conditions Governance registry publisher and store can only be
configured in the same cluster domain. Retrieving the actual resource
content from the "Cache Backed" registry when resources are submitted for
indexing can be identified as the bottleneck for this limitation.

So the updated data in the publisher is not available at the store if they
are in separate cluster domains.This is due to cache registry being
populated with stale data which are not updated.

Basic flow of resource retrieving for indexing process is shown below .


​

*Requirement*

Enable governance registry Store and publisher to be configured in separate
cluster domains . For example configure Publisher in internal server and
Store in DMZ.

*Proposed Solution*

 Requirement is  to get the resources from the embedded registry avoiding
cache backed registry when resources are submitted for indexing. So the
updated resources will be available which enables publisher and store to be
configure in separate cluster domains.

Following are the two sub tasks of the proposed solution.

   1. Remove the resource from cache which is to be indexed.

  This can be achieved by including the resource path
as a no cached path in the  "registry context". This will invalidate
caching for all instances of indexing process. So the resources will be
directly fetched from embedded registry.

  2. Adding a property to the indexing configuration of the
registry.xml .

   This property can be enabled or disabled using
registry.xml which will enable or disable caching based on the custom
requirement. When there is no requirement to have Publisher and Store in
separate cluster domains this property can be set to false. So the
resources will be fetched from cache registry. If it is set to true
resources will be fetched from embedded registry.

Suggestions and feed backs are welcome.

Thanks!
Rajith

-- 
Rajith Roshan
Software Engineer, WSO2 Inc.
Mobile: +94-72-642-8350 <%2B94-71-554-8430>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [G-Reg] Enabling G-Reg Publisher and Store in separate cluster domains

[Rajith Roshan]

Hi all,

Step 1 of the proposed solution is modified based on the feed backs .

On Tue, Sep 15, 2015 at 11:52 AM, Isuruwan Herath  wrote:

> Hi Rajith,
>
> On Tue, Sep 15, 2015 at 10:19 AM, Rajith Roshan  wrote:
>
>> Hi all,
>>
>> *Problem*
>>
>> In present conditions Governance registry publisher and store can only be
>> configured in the same cluster domain. Retrieving the actual resource
>> content from the "Cache Backed" registry when resources are submitted for
>> indexing can be identified as the bottleneck for this limitation.
>>
>> So the updated data in the publisher is not available at the store if
>> they are in separate cluster domains.This is due to cache registry being
>> populated with stale data which are not updated.
>>
>> Basic flow of resource retrieving for indexing process is shown below .
>>
>>
>> ​
>>
>> *Requirement*
>>
>> Enable governance registry Store and publisher to be configured in
>> separate cluster domains . For example configure Publisher in internal
>> server and Store in DMZ.
>>
>> *Proposed Solution*
>>
>>  Requirement is  to get the resources from the embedded registry avoiding
>> cache backed registry when resources are submitted for indexing. So the
>> updated resources will be available which enables publisher and store to be
>> configure in separate cluster domains.
>>
>> Following are the two sub tasks of the proposed solution.
>>
>>1. Add the path of the resource to be fetched for indexing as a no
>>cache path.
>>
>>   This can be achieved by including the resource path
>> as a no cached path in the  "registry context". So the resources will be
>> directly fetched from embedded registry only for indexing process.
>>
>
>
>>   2. Adding a property to the indexing configuration of the
>> registry.xml .
>>
>>This property can be enabled or disabled using
>> registry.xml which will enable or disable caching based on the custom
>> requirement. When there is no requirement to have Publisher and Store in
>> separate cluster domains this property can be set to false. So the
>> resources will be fetched from cache registry. If it is set to true
>> resources will be fetched from embedded registry.
>>
>> Suggestions and feed backs are welcome.
>>
>> Thanks!
>> Rajith
>>
>> --
>> Rajith Roshan
>> Software Engineer, WSO2 Inc.
>> Mobile: +94-72-642-8350 <%2B94-71-554-8430>
>>
>> _______
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
>
> --
> Isuruwan Herath
> Technical Lead
>
> Contact: +94 776 273 296
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 
Rajith Roshan
Software Engineer, WSO2 Inc.
Mobile: +94-72-642-8350 <%2B94-71-554-8430>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

[Architecture] [G-Reg] Introducing Local Cache to store local registry path resources in distributed setup

[Rajith Roshan]

Hi all,

*Problem*

The Registry space provided to each product contains three major partitions.

   - *Local Repository* : Used to store configuration and run time data
   that is local to the server. This partition is not to be shared with
   multiple servers and can be browsed under /_system/local in the registry
   browser.
   - *Configuration Repository* : Used to store product-specific
   configuration. This partition can be shared across multiple instances of
   the same product. (eg: sharing G-Reg configuration across a G-Reg cluster)
   and can be browsed under /_system/config in the registry browser.
   - *Governance Repository* : Used to store configuration and data that
   are shared across the whole platform. This typically includes services,
   service descriptions, endpoints or data sources and can be browsed under
   /_system/governance in the registry browser.


Currently all the resources to be stored in Local, Config, and Governance
registry paths are stored in a single cache instance (with cache id :
REG_CACHE_BACKED_ID).

When clustering is enabled for a node this cache switch to distributed mode
and this results in a distributed Local registry path, which is not the
recommended behavior (Local registry path should not be shared with other
nodes).


*Proposed Solution*

Implement two cache instances to store the registry resources.

   1. Local cache - All the resources that are not  stored in the sub
   directories of the "/_System/config" and "/_System/governance" are stored
   in this cache. This cache instance will not be switched to distributed mode
   in a clustered setup.
   2. Distributed cache - This cache will store all the resources under the
   root directories of "/_System/config" and "/_System/governance". This cache
   instance will be switched to distributed mode in a clustered setup.


Thanks!
Rajith

-- 
Rajith Roshan
Software Engineer, WSO2 Inc.
Mobile: +94-72-642-8350 <%2B94-71-554-8430>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [G-Reg] Introducing Local Cache to store local registry path resources in distributed setup

[Rajith Roshan]

Hi Danesh,

On Thu, Oct 22, 2015 at 9:11 AM, Danesh Kuruppu  wrote:

> Hi Rajith,
>
> +1 for approach. This fix will also address the issue [1].
>

Could not verify whether this is the root cause for the above issue. The
issue remains the same even after introducing the new cache instance.  The
cause of the issue needs to be identified. Apart from the workaround
provided in the jira, this can also be avoided by log in from the other
node after few minutes creating the tenant.

>
> One more suggestion,
>
> Shall we make only the mounted registry goes to the distributed cache.
> rather storing both config and governance registry. IMO we need distributed
> cache only for the mounted registries. for example. If we mounted only the
> governance registry. we need to enable distribute cache only for the
> governance registry. We can keep our config registry also in local cache.
>
> Any thoughts on this please.
>

+1 for the idea. Since target mount path can be defined in numerous ways
(for ex: /_system/governance can be mounted to  /_system/governance/dev or
 /_system/nodes) then resources in those paths only will be distributed.

>
> Thanks
> Danesh
>
> 1. https://wso2.org/jira/browse/CARBON-14224
>
> On Tue, Oct 20, 2015 at 7:59 PM, Rajith Roshan  wrote:
>
>> Hi all,
>>
>> *Problem*
>>
>> The Registry space provided to each product contains three major
>> partitions.
>>
>>- *Local Repository* : Used to store configuration and run time data
>>that is local to the server. This partition is not to be shared with
>>multiple servers and can be browsed under /_system/local in the registry
>>browser.
>>- *Configuration Repository* : Used to store product-specific
>>configuration. This partition can be shared across multiple instances of
>>the same product. (eg: sharing G-Reg configuration across a G-Reg cluster)
>>and can be browsed under /_system/config in the registry browser.
>>- *Governance Repository* : Used to store configuration and data that
>>are shared across the whole platform. This typically includes services,
>>service descriptions, endpoints or data sources and can be browsed under
>>/_system/governance in the registry browser.
>>
>>
>> Currently all the resources to be stored in Local, Config, and Governance
>> registry paths are stored in a single cache instance (with cache id :
>> REG_CACHE_BACKED_ID).
>>
>> When clustering is enabled for a node this cache switch to distributed
>> mode and this results in a distributed Local registry path, which is not
>> the recommended behavior (Local registry path should not be shared with
>> other nodes).
>>
>>
>> *Proposed Solution*
>>
>> Implement two cache instances to store the registry resources.
>>
>>1. Local cache - All the resources that are not  stored in the sub
>>directories of the "/_System/config" and "/_System/governance" are stored
>>in this cache. This cache instance will not be switched to distributed 
>> mode
>>in a clustered setup.
>>2. Distributed cache - This cache will store all the resources under
>>the root directories of "/_System/config" and "/_System/governance". This
>>cache instance will be switched to distributed mode in a clustered setup.
>>
>>
>> Thanks!
>> Rajith
>>
>> --
>> Rajith Roshan
>> Software Engineer, WSO2 Inc.
>> Mobile: +94-72-642-8350 <%2B94-71-554-8430>
>>
>> _______
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
>
> --
>
> Danesh Kuruppu
> Software Engineer
> WSO2 Inc,
> Mobile: +94 (77) 1690552
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>
Thanks!
Rajith

-- 
Rajith Roshan
Software Engineer, WSO2 Inc.
Mobile: +94-72-642-8350 <%2B94-71-554-8430>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [GREG] Improving the REST Service artifact handling capability in Governance Center

[Rajith Roshan]

Hi Madawa,

By adding this handler we will have consistency when creating a soap
service manually specifying the wsdl url (which invokes
SOAPServiceMediaTypeHandler) and creating a rest service manually
specifying the wadl/swagger url.
And it will also import additional schemas and create the respective
endpoints as well (when WADLProcessor and SwaggerProcessor are used). So
this will enable better dependency visualization as well.

+1

Further, current implementation will import wadl content to the registry,
if the wadl url is given when creating a soap service. It is better to,
only import the wadl content when creating rest service through your newly
introduced handler. WDYT ?

Thanks!
Rajith

On Mon, Apr 18, 2016 at 2:11 PM, Madawa Soysa  wrote:

> Hi Shazni,
>
> In addition, all the handling logic for Swagger and WADL documents will be
> done using the existing swagger and WADL processor methods. Implementation
> of new media type handler will be needed to invoke these methods when a
> rest service artifact is added through the Governance Center Publisher.
>
> Regards,
> Madawa.
>
> On Mon, Apr 18, 2016 at 2:05 PM, Madawa Soysa  wrote:
>
>> Hi Shazni,
>>
>> Thank you for the feedback.
>>
>> Actually, I'm trying to implement a media type handler when *adding a
>> REST service artifact* through the Governance Center Publisher.
>>
>> Currently, there is no media type handler to handle manually added rest
>> service artifacts through the publisher and these are handled by the
>> default handler. That's why I suggested implementing a media type handler
>> as similar to the SOAP Service media type handler.
>>
>> Regards,
>> Madawa.
>>
>>
>> On Sun, Apr 17, 2016 at 7:48 AM, Shazni Nazir  wrote:
>>
>>> Hi Madawa,
>>>
>>> IMO, we do not need a separate media type handler for this. Reason being
>>> a media type handler for a REST call doesn't seem correct. Rather what we
>>> need is a method to take the URL etc to utilize the methods in WADL and
>>> swagger processor. WDYT??
>>>
>>> Using existing swagger and WADL processor however seems the right
>>> approach for consistency without rewriting all the code again.
>>>
>>> Shazni Nazeer
>>> Mob : +94 37331
>>> LinkedIn : http://lk.linkedin.com/in/shazninazeer
>>> Blog : http://shazninazeer.blogspot.com
>>>
>>> On Fri, Apr 8, 2016 at 12:22 AM, Madawa Soysa  wrote:
>>>
>>>> Hi,
>>>>
>>>> I have started improving the REST Service artifact handling capability
>>>> in GREG[1] <https://wso2.org/jira/browse/REGISTRY-3532>. In the
>>>> current implementation, when a REST Service is added manually and if a
>>>> Swagger or WADL resource URL is given, the resource will not get uploaded
>>>> to the system and the relevant associations will not get created. The
>>>> purpose of this improvement is to fix the above issue.
>>>>
>>>> My approach to solving this issue is by writing a separate media type
>>>> handler to handle REST service artifact and use existing swagger and WADL
>>>> processors to import the specified resource. Any suggestions and feedback
>>>> are appreciated.
>>>>
>>>>
>>>> [1] - https://wso2.org/jira/browse/REGISTRY-3532
>>>>
>>>> Regards,
>>>> Madawa
>>>> --
>>>>
>>>> Madawa Soysa / Software Engineer
>>>> mada...@wso2.com / +94714616050
>>>>
>>>> WSO2 Inc.
>>>> lean.enterprise.middleware
>>>>
>>>> [image: Twitter]  <https://twitter.com/madawa_rc> [image:
>>>> LinkedIn]  <https://www.linkedin.com/in/madawasoysa>  [image: Github]
>>>> <https://github.com/madawas> [image: Tumblr]
>>>> <http://madawas.tumblr.com/>
>>>>
>>>> ___
>>>> Architecture mailing list
>>>> Architecture@wso2.org
>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>>
>>>>
>>>
>>> ___
>>> Architecture mailing list
>>> Architecture@wso2.org
>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>
>>>
>>
>>
>> --
>>
>> Madawa Soysa / Software Engineer
>> mada...@wso2.com / +94714616050
>>
>> WSO2 Inc.
>> lean.enterprise.middleware
>>
>> [image: Twitter]  <h

[Architecture] [Dev] WSO2 Governance Registry 5.3.0 Released !!

[Rajith Roshan]

WSO2 Governance Registry team is pleased to announce the release of WSO2
Governance Registry 5.3.0.!

WSO2 Governance Registry provides end-to-end governance for enterprises. IT
professionals can streamline application development, testing and
deployment processes, as well as manage service lifecycles and assets using
WSO2 Governance Registry. The community and social aspects of WSO2
Governance Registry will act as an enabler for collaboration between
distributed teams, converting traditional human-centric tasks into key
assets of the governance process. It also includes business runtime
governance requirements through its interoperability with well-known
external monitoring and reporting applications.

WSO2 Governance Registry allows you to

   - Store, manage and search any kind of enterprise asset, including
   services, APIs, policies, projects or applications. You can extend the
   predefined asset metadata or create your own
   - Ability to navigate through asset classifications and taxonomies.
   - Access and manage assets via a REST API, supporting the integration
   with enterprise initiative such as DevOps
   - Describe relationships between assets such as dependencies, usage or
   associations and perform impact analysis
   - Attach custom life cycle to assets and engage custom actions when an
   asset transitions from one state to the next
   - Secure the access to assets via a fine-grained permission model
   - Leverage social tools such as ratings and comments to enable better
   communication between asset providers and consumers
   - Notify users of any asset changes via email or a notification system
   of your choice
   - Integrate with mediation engines such as WSO2 Enterprise Service Bus
   or others via UDDI and REST for dynamic discovery of services and APIs
   endpoints


For more information on WSO2 Governance Registry and to download the
product please visit http://wso2.com/products/governance-registry. Also,
take a look at the online product documentation

and quick start guide
.

How to Run

   1.

   Extract the downloaded zip
   
   2.

   Go to the bin directory in the extracted folder
   3.

   Run the wso2server.sh or wso2server.bat as appropriate
   4.

   Launch a web browser and navigate to https://localhost:9443/carbon to
   access the admin console
   5.

   Navigate to https://localhost:9443/publisher to access the publisher web
   app
   6.

   Navigate to https://localhost:9443/store to access the store web app
   7.

   Use "admin", "admin" as the username and password to login as an admin



WSO2 Governance Registry 5.3.0 includes following features, improvements
and bug fixes.

Features

List of features done in G-Reg 5.3.0


Improvements

List of improvements done in G-Reg 5.3.0


Bug Fixes

List of bug Fixes done in G-Reg 5.3.0


Key Features of WSO2 Governance Registry

SOA Governance

   -

   Strong searching/filtering capabilities using taxonomy support
   -

   Multiple categorization support for assets.
   -

   Enhanced searching and filtering capabilities (with  "AND" "OR"
   operations)
   -

   WSDL visualization in Governance Center
   -

   Per asset permission management in Governance Center.
   -

   Enhanced Governance Rest API.
   -

   Flexible service registry for any type of services including REST
   services, JSON services, SOAP services and Thrift services
   -

   Govern all aspects of services including service descriptions, service
   consumption, service usage, service discovery, service lifecycle management
   and service policies
   -

   Service and application discovery for third-party servers
   -

   Dependency management and impact analysis
   -

   Graphical visualization (dependency graphs) of artifacts with associated
   resources and dependent artifacts enabling users to perform impact analysis
   when changes are made to an artifact
   -

   Policy management for both design-time and run-time
   -

   Comprehensive lifecycle management
   -

   Act as a policy store for any Policy Enforcement Point (PEP) including
   WSO2 Enterprise Service Bus and WSO2 Application Server
   -

   User notification and alert management supported with the ability to use
   email templates
   -

   Role based authentication and authorization leveraging information
   stored in common user repositories such as
   -

   LDAP or MS Active Directory
   -

   Auditing, logging and reporting



Configuration Governance

   -

   Govern any kind of server/system configuration
   -

   Version and revision management with checkpointing & rollback
   -

   Full lifecycle management spa

[Architecture] [Dev] [Announce] WSO2 API Manager 3.0.0-M25 Released!

[Rajith Roshan]

The WSO2 API Manager team is pleased to announce the release of API Manager
3.0.0-M25. It's now available to download.
Distribution

   - wso2apim-3.0.0-M25
   
<https://github.com/wso2/product-apim/releases/download/v3.0.0-m25/wso2apim-3.0.0-m25.zip>
   - wso2apim-gateway-3.0.0-M25
   
<https://github.com/wso2/product-apim/releases/download/v3.0.0-m25/wso2apim-gateway-3.0.0-m25.zip>

Documentation

   - WSO2 API Manager 3.0.0 <https://docs.wso2.com/display/AM300/>

Following list contains all the features, improvements and bug fixes
available with this milestone.
Bug Fixes

   - Product-APIM Bug fixses
   
<https://github.com/wso2/product-apim/issues?q=is%3Aissue+milestone%3A3.0.0-m25+is%3Aclosed>

List of Open Issues

   - Open Issues for Product-APIM
   
<https://github.com/wso2/product-apim/issues?q=is%3Aopen+is%3Aissue+label%3A3.0.0+label%3AType%2FBug>

How To Contribute

Your feedback is most welcome!
Mailing Lists

Join our mailing list and collaborate with the developers directly.

Developer List : d...@wso2.org | Subscribe | Mail Archive
<http://mail.wso2.org/mailarchive/dev/>

   - User Forum : StackOverflow
   <https://stackoverflow.com/questions/tagged/wso2-am>

Reporting Issues

We encourage you to report issues, improvements and feature requests
regarding WSO2 API Manager through WSO2 API Manager GIT Issues
<https://github.com/wso2/product-apim/issues>.

~ WSO2 API Manager Team ~


-- 
Rajith Roshan
Senior Software Engineer, WSO2 Inc.
Mobile: +94-7 <%2B94-71-554-8430>17-064-214
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

[Architecture] [Dev] [Announce] WSO2 API Manager 3.0.0-M26 Released!

[Rajith Roshan]

The WSO2 API Manager team is pleased to announce the release of API Manager
3.0.0-M26. It's now available to download.
Distribution

   - wso2apim-3.0.0-M26
   
<https://github.com/wso2/product-apim/releases/download/v3.0.0-m26/wso2apim-3.0.0-m26.zip>
   - wso2apim-gateway-3.0.0-M26
   
<https://github.com/wso2/product-apim/releases/download/v3.0.0-m26/wso2apim-gateway-3.0.0-m26.zip>

Documentation

   - WSO2 API Manager 3.0.0 <https://docs.wso2.com/display/AM300/>

Following list contains all the features, improvements and bug fixes
available with this milestone.
Bug Fixes

   - Product-APIM Bug fixses
   
<https://github.com/wso2/product-apim/issues?q=is%3Aissue+milestone%3A3.0.0-m26+is%3Aclosed>

List of Open Issues

   - Open Issues for Product-APIM
   
<https://github.com/wso2/product-apim/issues?q=is%3Aopen+is%3Aissue+label%3A3.0.0+label%3AType%2FBug>

How To Contribute

Your feedback is most welcome!
Mailing Lists

Join our mailing list and collaborate with the developers directly.

Developer List : d...@wso2.org | Subscribe | Mail Archive
<http://mail.wso2.org/mailarchive/dev/>

   - User Forum : StackOverflow
   <https://stackoverflow.com/questions/tagged/wso2-am>

Reporting Issues

We encourage you to report issues, improvements and feature requests
regarding WSO2 API Manager through WSO2 API Manager GIT Issues
<https://github.com/wso2/product-apim/issues>.

~ WSO2 API Manager Team ~


-- 
Rajith Roshan
Senior Software Engineer, WSO2 Inc.
Mobile: +94-7 <%2B94-71-554-8430>17-064-214
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Adding custom attributes to Applications in API Store

[Rajith Roshan]

Hi all

On Thu, Apr 19, 2018 at 9:19 AM, Nuwan Dias  wrote:

> We don't have an application search capability right now right? If so I
> don't think we should be adding such a feature. Because its unlikely
> someone will have so many apps to search from.
>
> Some of the usages of these properties that I could think are (based on
> some replies as well).
>
> 1. The need to publish these data to third party key managers when
> generating application keys.
> 2. The need to publish these data to application/subscription related
> workflows.
> 3. The need to access these data at the API Gateway when processing a
> request (we could probably use the JWT for this).
>

So based on the usages of these attributes , and analyzing some of the use
cases , I think better option is to have set of predefined key values for
these application attributes. Giving the api consumer to add the both key ,
value pairs is meaning less because none of the key manager, gateway,
workflows etc would not know how to process those values, if api consumer
add what ever the values they have in mind as keys.
I think we should have way to configure the set of predefined keys , where
UI will read the config and render the keys as text fields so api consumer
can provide values to those keys.
With fixed set of pre configured attributes and we can also provide
flexibility to define both key value pairs to the api consumer as well.

>
> Anyhow, Vithursa let's take these requirements step by step. First lets
> work on the design and implementation of saving these data against the
> Application.
>
> On Thu, Apr 19, 2018 at 7:12 AM, Prasanna Dangalla 
> wrote:
>
>> Hi Vithursa,
>>
>> Is there a possibilty of adding a functionality to search applications
>> using custom attibutes. IMO this will aslo be a valied use case.
>>
>> Thanks
>> Prasanna
>>
>> On Thu, Apr 19, 2018 at 5:35 AM Ishara Cooray  wrote:
>>
>>> Hi Vithursa,
>>>
>>> IMO you also need to have *another user story to delete applications
>>> with custom attributes *where you need to make sure application is
>>> successfully deleted from the application list along with its custom
>>> attributes.
>>>
>>> Thanks & Regards,
>>> Ishara Cooray
>>> Senior Software Engineer
>>> Mobile : +9477 262 9512
>>> WSO2, Inc. | http://wso2.com/
>>> Lean . Enterprise . Middleware
>>>
>>> On Thu, Apr 19, 2018 at 1:54 AM, Nuwan Dias  wrote:
>>>
>>>> Based on what Youcef has mentioned, we would need to include these
>>>> additional properties on the JWT perhaps so that they can be accessed by
>>>> the Gateway upon validating an access token.
>>>>
>>>> On Wed, Apr 18, 2018 at 11:38 PM, Youcef HILEM >>> > wrote:
>>>>
>>>>> Hi,
>>>>>  for this feature.
>>>>> I do not have access to the document [1] but we wish to develop
>>>>> mediations
>>>>> reinforcing access control to APIs according to these metadata (example
>>>>> (key: client-contract, value: contractx), ie : association between
>>>>> client-id
>>>>> & client-contract-id).
>>>>> Thanks
>>>>> Youcef HILEM
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Sent from: http://wso2-oxygen-tank.10903.
>>>>> n7.nabble.com/WSO2-Architecture-f62919.html
>>>>> ___
>>>>> Architecture mailing list
>>>>> Architecture@wso2.org
>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Nuwan Dias
>>>>
>>>> Software Architect - 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
>>>>
>>>>
>>> ___
>>> Architecture mailing list
>>> Architecture@wso2.org
>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>
>> --
>> *Prasanna Dangalla*
>> Senior Software Engineer, WSO2, Inc.; http://wso2.com/
>> lean.enterprise.middleware
>>
>>
>> *cell: +94 718 11 27 51*
>> *twitter: @prasa77*
>>
>> ___
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
>
> --
> Nuwan Dias
>
> Software Architect - 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
>
>


-- 
Rajith Roshan
Senior Software Engineer, WSO2 Inc.
Mobile: +94-7 <%2B94-71-554-8430>17-064-214
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] APIM Micro Gateway Cli Functionality and Structure

[Rajith Roshan]

;
> This would be a limitation. Running any custom mediation sequences in the
> micro gw will not be supported.
>
>>
>>>- *micro-gw build (with inputs label name)*
>>>   - This command build single balx out of all APIs belongs to given
>>>   label. If docker/kubernetes configurations specified, then
>>>   archive will be generated. This archive will embeds bre, generated 
>>> balx
>>>   which someone can take and run without configuring anything.
>>>   - This command also outputs APIs which have updated and commands
>>>   which are available to run in target folder
>>>- *micro-gw run (with label name)*
>>>   - This command will use to run the balx generated for given label.
>>>
>>> Please share your suggestions and improvements.
>>>
>>>
>>> Thanks,
>>> Harsha
>>> --
>>> Harsha Kumara
>>> Associate Technical Lead, WSO2 Inc.
>>> Mobile: +94775505618
>>> Blog:harshcreationz.blogspot.com
>>>
>>
>>
>>
>> --
>> *Sanjeewa Malalgoda*
>> WSO2 Inc.
>> Mobile : +94 712933253
>>
>> <http://sanjeewamalalgoda.blogspot.com/>blog
>> :http://sanjeewamalalgoda.blogspot.com/
>> <http://sanjeewamalalgoda.blogspot.com/>
>>
>>
>>
>
>
> --
> Thanks and Regards,
>
> Isuru H.
> +94 716 358 048* <http://wso2.com/>*
>
>
>

-- 
Rajith Roshan
Senior Software Engineer, WSO2 Inc.
Mobile: +94-7 17-064-214
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [VOTE] Release of WSO2 API Manager Microgateway Toolkit 2.5.0 RC2

[Rajith Roshan]

Hi All,

Tested below scenarios.


   1. Default version of API
   2. Subscription validation for jwt token
   3. Subscription validation for oauth2 token
   4. Scope validation for oauth2 token
   5. Scope validation for jwt token
   6. Basic ballerina service generation for APIs

No blockers found.

[+] Stable - go ahead and release

Thanks!


On Fri, Jul 6, 2018 at 1:03 PM Malintha Amarasinghe 
wrote:

> Tested below scenarios:
>
> 1. Testing API invocation with an OAuth2 access token and JWT token
> generated from Store.
> 2. Response caching.
> 3. Disabling HTTP/HTTPs transports per API (Publisher manage page).
> 4. Testing code generation and API invocation with wildcard resources,
> path, and query parameter combinations and check whether params are
> properly sent to backend upon invocation.
> 5. Tested load balanced and failover endpoints.
>
> [+] Stable - go ahead and release
>
> Thanks!
>
>
> On Fri, Jul 6, 2018 at 7:41 PM, Rukshan Premathunga 
> wrote:
>
>> Hi All,
>>
>> We are pleased to announce the second release candidate of WSO2 API
>> Manager Microgateway Toolkit 2.5.0.
>>
>> This release fixes the following issues.
>>
>>- Fixes: product-microgateway
>>
>> <https://github.com/wso2/product-microgateway/issues?q=is%3Aissue+milestone%3A2.5.0+is%3Aclosed>
>>
>> Distribution : 
>> *https://github.com/wso2/product-microgateway/releases/download/v2.5.0-rc2/wso2am-micro-gw-toolkit-2.5.0-RC2.zip
>> <https://github.com/wso2/product-microgateway/releases/download/v2.5.0-rc2/wso2am-micro-gw-toolkit-2.5.0-RC2.zip>*
>>
>> Please download, test the product and vote.
>>
>> [+] Stable - go ahead and release
>> [-] Broken - do not release (explain why)
>>
>> Thanks,
>> WSO2 API Manager Team
>>
>> --
>> Rukshan Chathuranga.
>> WSO2, Inc.
>> +94711822074
>>
>
>
>
> --
> Malintha Amarasinghe
> *WSO2, Inc. - lean | enterprise | middleware*
> http://wso2.com/
>
> Mobile : +94 712383306
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>


-- 
Rajith Roshan
Senior Software Engineer, WSO2 Inc.
Mobile: +94-7 17-064-214
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Dynamic backend endpoint definition for APIs in API micro gateway

[Rajith Roshan]

Hi Malintha/Chamila

On Thu, Jun 28, 2018 at 12:11 AM Malintha Amarasinghe 
wrote:

> Hi Chamila,
>
> A small suggestion for the implementation: I think this will be relatively
> easier if we define a function to get a particular config from env variable
> name (input 1) or from the default value (input 2) (if env variable is not
> defined). Then we can use this function name straight in the codegen
> templates. I think the function can be defined in the ballerina lib sources
> in the gateway core so that can be reused easily.
>

We already has the function in [1]. For me this feature is a simple three
line fix to call this function in httpEndpoint.mustache,
failoverEndpoin.mustache and lbEndpoint.mustache  template files :)

Thanks!
Rajith

[1] -
https://github.com/wso2/product-microgateway/blob/master/components/micro-gateway-core/src/main/ballerina/gateway/utils/utils.bal#L293


>
> Thanks!
>
> On Thu, Jun 28, 2018 at 12:18 PM, Chamila Adhikarinayake <
> chami...@wso2.com> wrote:
>
>> Hi All,
>>
>> I'm implementing a dynamic backend endpoint feature which will provide
>> users the capability to define dedicated backends for the same API.
>>
>>
>>
>>
>>
>> This feature is a bit similar to what we have in API Manager where we
>> define endpoints with variables and resolve it during the runtime (say we
>> set backend endpoint as http://{uri.var.host}:{uri.var.port}/apis/weather
>> and resolve them using system variables, etc).
>>
>> Similarly, We plan to provide a method to override the backend endpoint
>> uri from the API. But this method doesn't depend on whether the URL is
>> defined with template structure (with {uri.var.host}, etc).
>>
>> For example, If there is an API with TestAPI and version 1.0, we could
>> define *TestAPI-1.0.prod.**ep* , *TestAPI-1.0.sand.ep* as environment
>> variables, value in the TOML format or as command-line parameters and
>> override the existing related endpoint during the startup time. If the
>> properties are not provided, then we use endpoint defined in the API as the
>> default endpoint.
>>
>> This way, a user can start the micro-gateway with the default backend
>> endpoint or he can override it during the startup time. This will give the
>> capability to call dedicated endpoints for each environment
>>
>> Chamila.
>>
>> --
>> Regards,
>> Chamila Adhikarinayake
>> WSO2, Inc.
>> Mobile - +94712346437
>> Email  - chami...@wso2.com
>> Blog  -  http://helpfromadhi.blogspot.com/
>>
>> ___
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
>
> --
> Malintha Amarasinghe
> *WSO2, Inc. - lean | enterprise | middleware*
> http://wso2.com/
>
> Mobile : +94 712383306
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>


-- 
Rajith Roshan
Senior Software Engineer, WSO2 Inc.
Mobile: +94-717-064-214
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Dynamic backend endpoint definition for APIs in API micro gateway

[Rajith Roshan]

Hi Malintha,
On Tue, Jul 17, 2018 at 9:09 PM Malintha Amarasinghe 
wrote:

> Hi Rajith,
>
> We are using a similar method (retrieveConfig),
> https://github.com/wso2/product-microgateway/blob/master/components/micro-gateway-cli/src/main/resources/templates/httpEndpoint.mustache#L2
>
> Bdw, what is the use of instanceId in getConfigValue method? Other than
> that, those two methods are the same it seems.
>
Its the main heading of the configuration. For ex: consider the following
conf . In here the instanceId means the "JWTConfig" is the instanceID.

ex :
[JWTConfig]
   audience = "sample"
   subject = "sample"


>
> Thanks!
>
> On Tue, Jul 17, 2018 at 11:54 PM, Rajith Roshan  wrote:
>
>> Hi Malintha/Chamila
>>
>> On Thu, Jun 28, 2018 at 12:11 AM Malintha Amarasinghe 
>> wrote:
>>
>>> Hi Chamila,
>>>
>>> A small suggestion for the implementation: I think this will be
>>> relatively easier if we define a function to get a particular config from
>>> env variable name (input 1) or from the default value (input 2) (if env
>>> variable is not defined). Then we can use this function name straight in
>>> the codegen templates. I think the function can be defined in the ballerina
>>> lib sources in the gateway core so that can be reused easily.
>>>
>>
>> We already has the function in [1]. For me this feature is a simple three
>> line fix to call this function in httpEndpoint.mustache,
>> failoverEndpoin.mustache and lbEndpoint.mustache  template files :)
>>
>> Thanks!
>> Rajith
>>
>> [1] -
>> https://github.com/wso2/product-microgateway/blob/master/components/micro-gateway-core/src/main/ballerina/gateway/utils/utils.bal#L293
>>
>>
>>>
>>> Thanks!
>>>
>>> On Thu, Jun 28, 2018 at 12:18 PM, Chamila Adhikarinayake <
>>> chami...@wso2.com> wrote:
>>>
>>>> Hi All,
>>>>
>>>> I'm implementing a dynamic backend endpoint feature which will provide
>>>> users the capability to define dedicated backends for the same API.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> This feature is a bit similar to what we have in API Manager where we
>>>> define endpoints with variables and resolve it during the runtime (say we
>>>> set backend endpoint as http://{uri.var.host}:{uri.var.port}/apis/weather
>>>> and resolve them using system variables, etc).
>>>>
>>>> Similarly, We plan to provide a method to override the backend endpoint
>>>>  uri from the API. But this method doesn't depend on whether the URL
>>>> is defined with template structure (with {uri.var.host}, etc).
>>>>
>>>> For example, If there is an API with TestAPI and version 1.0, we could
>>>> define *TestAPI-1.0.prod.**ep* , *TestAPI-1.0.sand.ep* as environment
>>>> variables, value in the TOML format or as command-line parameters and
>>>> override the existing related endpoint during the startup time. If the
>>>> properties are not provided, then we use endpoint defined in the API as the
>>>> default endpoint.
>>>>
>>>> This way, a user can start the micro-gateway with the default backend
>>>> endpoint or he can override it during the startup time. This will give the
>>>> capability to call dedicated endpoints for each environment
>>>>
>>>> Chamila.
>>>>
>>>> --
>>>> Regards,
>>>> Chamila Adhikarinayake
>>>> WSO2, Inc.
>>>> Mobile - +94712346437
>>>> Email  - chami...@wso2.com
>>>> Blog  -  http://helpfromadhi.blogspot.com/
>>>>
>>>> ___
>>>> Architecture mailing list
>>>> Architecture@wso2.org
>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>>
>>>>
>>>
>>>
>>> --
>>> Malintha Amarasinghe
>>> *WSO2, Inc. - lean | enterprise | middleware*
>>> http://wso2.com/
>>>
>>> Mobile : +94 712383306
>>> ___
>>> Architecture mailing list
>>> Architecture@wso2.org
>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>
>>
>>
>> --
>> Rajith Roshan
>> Senior Software Engineer, WSO2 Inc.
>> Mobile: +94-717-064-214
>>
>> ___
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
>
> --
> Malintha Amarasinghe
> *WSO2, Inc. - lean | enterprise | middleware*
> http://wso2.com/
>
> Mobile : +94 712383306
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>


-- 
Rajith Roshan
Senior Software Engineer, WSO2 Inc.
Mobile: +94-7 17-064-214
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [AM] Securing APIs using Mutal SSL

[Rajith Roshan]

Hi Megala,
On Tue, Sep 11, 2018 at 9:16 PM Megala Uthayakumar  wrote:

> Hi All,
>
> I am currently working on $subject for APIM 2.x. Currently all the APIs
> are protected with oauth2 token, with this feature, the API
> creators/publishers will be given the flexibility to select different
> options to secure their APIs (i.e. Options can be oauth2, mutal ssl or
> both). Userstory for this feature can be found at [1]
>
> *Option 1  - oauth2*
> This will follow the same old flow when invoking the API.
>
> *Option 2 - Mutual SSL*
> If this option is selected, the authentication will be handled in the
> transport level and in the handler level, we do not need to do the
> authentication explicitily.
>
> *Option 3 - oauth2 and mutal SSL*
> The authentication will be handled in transport level as well as in
> handler level.
>
> In the above options, option 2 has some unclear areas that need to be
> sorted out.
>
> *How to handle the scope validation*
> Authentication will be handled with the client certificates, however for
> scope handling we need role/scope information(i.e. authorization
> information). As per specification[2], it seems attribute certificate is
> used for this purpose, which incudes the authorization information. However
> it seems it seems there seems to be no proper support for such certificate
> as of [3]. In that case, we may need to get the scope information from the
> public certificate, may be we could use certificate extension for that
> purpose, however seems we do not have a standard extension for the relevant
> purpose.
>
AFAIK there is no standard certificate extension to save scope values, If
we use wso2 proprietary certificate extension attribute , then users with
valid CA signed  x509 certificate won't be able to access the APIs. Or if
use proprietary attribute for scopes users will have to generate
certificates with those extension attributes.

>
> *How to support client certificates upload*
> When we support mutual SSL, we may need to provide the way to upload the
> client certificates. For this we can make use of the same way we have used
> for dynamic ssl certification handling for backend. Similar to sender,
> dynamic ssl certification is supported for listeners as well. Hence we
> could use the similar implementation to support this usecase.
>
> *Application subscription and related functionalities and a**nalytics
> related functionalities*
> We retrieve the subscription information from the authenticated token.
> Since we do not have any token's involved, subscription and related
> functionalities will not work.
> Analytics related functionalities need to be verified as well in the same
> flow.
>
In mutual ssl flow we will have  to skip the subscription validation, since
there is no valid subscription. Subscription related analytics and
throttling should also be skipped.

>
> *Modification Store API Console*
> With this feature, we may need to consider the modifications that need to
> be done to swagger API console in store to support calling APIs with mutual
> SSL.
>
> Currently I am working on POC setup for this feature to figure out
> possible solutions for these uncler areas. Appreciate your suggestions on
> this.
>
> [1]
> https://docs.google.com/document/d/1syUw22Re9wLbomyYfQAP-EI-UWl9FnBrCGLHJ0L54Kg/edit?usp=sharing
> [1] https://tools.ietf.org/html/rfc5755
> [2]
> https://security.stackexchange.com/questions/101351/attribute-certificates-and-access-management
>
> Thanks.
>
> Regards,
> Megala
> --
> Megala Uthayakumar
>
> Senior Software Engineer
> Mobile : 0779967122
>


-- 
Rajith Roshan
Senior Software Engineer, WSO2 Inc.
Mobile: +94-7 <%2B94-71-554-8430>17-064-214
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [AM] Securing APIs using Mutal SSL

[Rajith Roshan]

On Wed, Sep 12, 2018 at 9:05 AM Megala Uthayakumar  wrote:

> Hi Rajith,
>
> Thanks for the response.
> On Tue, Sep 11, 2018 at 10:55 PM Rajith Roshan  wrote:
>
>> Hi Megala,
>> On Tue, Sep 11, 2018 at 9:16 PM Megala Uthayakumar 
>> wrote:
>>
>>> Hi All,
>>>
>>> I am currently working on $subject for APIM 2.x. Currently all the APIs
>>> are protected with oauth2 token, with this feature, the API
>>> creators/publishers will be given the flexibility to select different
>>> options to secure their APIs (i.e. Options can be oauth2, mutal ssl or
>>> both). Userstory for this feature can be found at [1]
>>>
>>> *Option 1  - oauth2*
>>> This will follow the same old flow when invoking the API.
>>>
>>> *Option 2 - Mutual SSL*
>>> If this option is selected, the authentication will be handled in the
>>> transport level and in the handler level, we do not need to do the
>>> authentication explicitily.
>>>
>>> *Option 3 - oauth2 and mutal SSL*
>>> The authentication will be handled in transport level as well as in
>>> handler level.
>>>
>>> In the above options, option 2 has some unclear areas that need to be
>>> sorted out.
>>>
>>> *How to handle the scope validation*
>>> Authentication will be handled with the client certificates, however for
>>> scope handling we need role/scope information(i.e. authorization
>>> information). As per specification[2], it seems attribute certificate is
>>> used for this purpose, which incudes the authorization information. However
>>> it seems it seems there seems to be no proper support for such certificate
>>> as of [3]. In that case, we may need to get the scope information from the
>>> public certificate, may be we could use certificate extension for that
>>> purpose, however seems we do not have a standard extension for the relevant
>>> purpose.
>>>
>> AFAIK there is no standard certificate extension to save scope values, If
>> we use wso2 proprietary certificate extension attribute , then users with
>> valid CA signed  x509 certificate won't be able to access the APIs. Or if
>> use proprietary attribute for scopes users will have to generate
>> certificates with those extension attributes.
>>
> Agree on those points. I was thinking of giving the flexibility to API
> creator to decide on what is the certificate extension attribute, we need
> to get the scope from, may be we can have a optional attibute in API level.
> If the API creator does not want the APIs to checked against scopes, they
> can simply leave the field empty. WDYT?
>

Seems fine. With this way api publishers can force the consumers to use
certificate with specific attribute to invoke the scope restricted apis.
Some what similar to psd2 APIs are protected using role check in EIDAS
certificate.

>
>
>>
>>> *How to support client certificates upload*
>>> When we support mutual SSL, we may need to provide the way to upload the
>>> client certificates. For this we can make use of the same way we have used
>>> for dynamic ssl certification handling for backend. Similar to sender,
>>> dynamic ssl certification is supported for listeners as well. Hence we
>>> could use the similar implementation to support this usecase.
>>>
>>> *Application subscription and related functionalities and a**nalytics
>>> related functionalities*
>>> We retrieve the subscription information from the authenticated token.
>>> Since we do not have any token's involved, subscription and related
>>> functionalities will not work.
>>> Analytics related functionalities need to be verified as well in the
>>> same flow.
>>>
>> In mutual ssl flow we will have  to skip the subscription validation,
>> since there is no valid subscription. Subscription related analytics and
>> throttling should also be skipped.
>>
>>>
>>> *Modification Store API Console*
>>> With this feature, we may need to consider the modifications that need
>>> to be done to swagger API console in store to support calling APIs with
>>> mutual SSL.
>>>
>>> Currently I am working on POC setup for this feature to figure out
>>> possible solutions for these uncler areas. Appreciate your suggestions on
>>> this.
>>>
>>> [1]
>>> https://docs.google.com/document/d/1syUw22Re9wLbomyYfQAP-EI-UWl9FnBrCGLHJ0L54Kg/edit?usp=sharing
>>> [1] https://tools.ietf.org/html/rfc5755
>>> [2]
>>> https://security.stackexchange.com/questions/101351/attribute-certificates-and-access-management
>>>
>>> Thanks.
>>>
>>> Regards,
>>> Megala
>>> --
>>> Megala Uthayakumar
>>>
>>> Senior Software Engineer
>>> Mobile : 0779967122
>>>
>>
>>
>> --
>> Rajith Roshan
>> Senior Software Engineer, WSO2 Inc.
>> Mobile: +94-7 <%2B94-71-554-8430>17-064-214
>>
>
>
> --
> Megala Uthayakumar
>
> Senior Software Engineer
> Mobile : 0779967122
>


-- 
Rajith Roshan
Senior Software Engineer, WSO2 Inc.
Mobile: +94-7 <%2B94-71-554-8430>17-064-214
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [Dev] Dev][VOTE] Release of WSO2 API Manager 2.6.0 RC3

[Rajith Roshan]

Tested following scenarios.

Basic API creation , publish and invoke flow
Creating api using swagger
Build a micro gw by using api created by swagger and invoke the resources
Customize the life cycle to add new state and check the lifecycle
transitions
Tested the basic scope validation
Tested the cross tenant subscription flow
Tested cross tenant subscriptions with scope validation

No blockers found.
[+] Stable - go ahead and release

Thanks!
Rajith

On Sat, Sep 15, 2018 at 4:27 PM Sanjeewa Malalgoda 
wrote:

> Tested microgateway flows,
>
> Microgateway docker/VM mode with APIM 2.5
> Microgateway  API pull using name and label to create gateway.
>
> Microgateway docker/VM mode with APIM 2.6
>
> +1.
>
> Thanks,
> sanjeewa.
>
>
> On Sat, Sep 15, 2018 at 3:34 PM Nuwan Dias  wrote:
>
>> Tested the following.
>>
>> Basic API creation by creator role
>> Publishing by publisher role
>> User sign up
>> Creation and invocation of SOAP APIs
>> Microgateway VM mode
>> Microgateway docker mode
>>
>> [+] Stable - go ahead and release
>>
>> Thanks,
>> NuwanD.
>>
>> On Sat, Sep 15, 2018 at 10:34 AM Chamila Adhikarinayake <
>> chami...@wso2.com> wrote:
>>
>>> Microgateway RC3 can be found in
>>> https://github.com/wso2/product-microgateway/releases/tag/v2.6.0-rc3
>>>
>>> Thanks
>>> Chamila
>>>
>>> On Sat, Sep 15, 2018 at 7:04 AM, Chamila Adhikarinayake <
>>> chami...@wso2.com> wrote:
>>>
>>>> Hi All,
>>>>
>>>> We are pleased to announce the third release candidate of WSO2 API
>>>> Manager 2.6.0.
>>>>
>>>> This release fixes the following issues.
>>>>
>>>> Fixes : carbon-apimgt
>>>> <https://github.com/wso2/carbon-apimgt/issues?utf8=%E2%9C%93&q=is%3Aclosed+closed%3A2018-07-16..2018-09-15+-label%3A%22APIM+3.0.0%22>
>>>> Fixes : product-apim
>>>> <https://github.com/wso2/product-apim/issues?utf8=%E2%9C%93&q=is%3Aclosed+closed%3A2018-07-16..2018-09-15+-label%3A%223.0.0%22>
>>>> Fixes : analytics-apim
>>>> <https://github.com/wso2/analytics-apim/issues?utf8=%E2%9C%93&q=is%3Aclosed+closed%3A2018-07-16..2018-09-15>
>>>> Fixes : product-microgateway
>>>> <https://github.com/wso2/product-microgateway/issues?utf8=%E2%9C%93&q=is%3Aclosed+closed%3A2018-07-16..2018-09-15>
>>>>
>>>> Source and Distribution,
>>>>- Runtime :
>>>> https://github.com/wso2/product-apim/releases/tag/v2.6.0-rc3
>>>>- Analytics :
>>>> https://github.com/wso2/analytics-apim/releases/tag/v2.6.0-rc3
>>>>- Tooling :
>>>> https://github.com/wso2/devstudio-tooling-apim/releases/tag/v2.6.0-rc1
>>>>- Microgateway :
>>>> https://github.com/wso2/product-microgateway/releases/tag/v2.6.0-rc2
>>>>
>>>> Please download, test the product and vote.
>>>>
>>>>   [+] Stable - go ahead and release
>>>>   [-] Broken - do not release (explain why)
>>>>
>>>> Thanks,
>>>> ~ WSO2 API Manager Team ~
>>>>
>>>>
>>>> --
>>>> Regards,
>>>> Chamila Adhikarinayake
>>>> Associate Technical Lead
>>>> WSO2, Inc.
>>>> Mobile - +94712346437
>>>> Email  - chami...@wso2.com
>>>> Blog  -  http://helpfromadhi.blogspot.com/
>>>>
>>>
>>>
>>>
>>> --
>>> Regards,
>>> Chamila Adhikarinayake
>>> Associate Technical Lead
>>> WSO2, Inc.
>>> Mobile - +94712346437
>>> Email  - chami...@wso2.com
>>> Blog  -  http://helpfromadhi.blogspot.com/
>>>
>>
>>
>> --
>> *Nuwan Dias* | Director | WSO2 Inc.
>> (m) +94 777 775 729 | (e) nuw...@wso2.com
>> [image: Signature.jpg]
>> ___
>> Dev mailing list
>> d...@wso2.org
>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>
>
>
> --
> *Sanjeewa Malalgoda*
> Software Architect | Associate Director, Engineering WSO2 Inc.
> (m) +94 712933253 | (e) sanje...@wso2.com
>
> GET INTEGRATION AGILE <https://wso2.com/signature>
> Integration Agility for Digitally Driven Business
> ___
> Dev mailing list
> d...@wso2.org
> http://wso2.org/cgi-bin/mailman/listinfo/dev
>


-- 
Rajith Roshan
Senior Software Engineer, WSO2 Inc.
Mobile: +94-7 <%2B94-71-554-8430>17-064-214
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Fwd: Certificate based Authentication for Micro-gateway

[Rajith Roshan]

s, ciphers)
> are not mandatory fields to enable mutual SSL. Because these are not
> specific to mutual SSL. They can be configured in 1 way SSL as well. So how
> about changing the name [mtslConfig] to [SslConfig]?
>
+1

>
>
>>
>> sslVerifyClient="optional"
>>
>
> What do you mean by setting sslVerifyClient="optional"? Does that mean
> that you first check if the mutual SSL has succeeded and if it has
> succeeded you skip OAuth or JWT tokens authentication and if mutual SSL
> fails, you continue with OAuth or JWT tokens authentication as well?
>
Yes, If we set it as optional , we would like to skip the oauth
authentication if mutual ssl has passed without any issue. But ATM we don't
have a way to identify whether the mutual ssl authentication has been done
successfully, when parameter is set as optional . is there a wat we can
achieve this?

>
>

>
>
>>
>> Thank You
>>
>> --
>> *Chamindu Udakara *
>> *Software engineering Intern*
>> WSO2  (University of Moratuwa)
>> *mobile *: *+94 755285531*  |   *email *:  cudak...@gmail.com
>>
>>
>> --
>> *Chamindu Udakara *
>> *Software engineering Intern*
>> WSO2  (University of Moratuwa)
>> *mobile *: *+94 755285531*  |   *email *:  cudak...@gmail.com
>> ___
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>
>
> --
> *Bhashinee Nirmali*
> *Software Engineer*
> *WSO2 Lanka (Private) Limited: **http://wso2.com
> <http://www.google.com/url?q=http%3A%2F%2Fwso2.com&sa=D&sntz=1&usg=AFQjCNEZvyc0uMD1HhBaEGCBxs6e9fBObg>*
> *lean.enterprise.middle-ware*
>
>
> *phone: (+94) 71 21 50003*
> <http://wso2.com/signature>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>


-- 
Rajith Roshan
Senior Software Engineer, WSO2 Inc.
Mobile: +94-7 <%2B94-71-554-8430>17-064-214
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Basic Authentication for Micro-gateway

[Rajith Roshan]

th.isRequired}}
>>>
>>> {{>basicAuthRequired}}
>>>
>>> {{else}}
>>>
>>> {{>oAuthRequired}}
>>>
>>> {{/if}}
>>>
>>> Then to validate and to set information which is needed for Analytics
>>> can be done in following way.
>>>
>>> Create a new filter called “BasicAuthenticationFilter.bal” and do the
>>> validation and value settings for analytics inside the filter. Include this
>>> filter by default to the filter chain and if “AUTH_HEADER” is “basic”
>>> then request will process through this “BasicAuthenticationFilter” and
>>> skip the “AuthnticationFilter” which requires OAuth2 tokens for
>>> authentication. By using this design, this feature can provide support for
>>> basic authentication and OAuth2 based authentication at the same time and
>>> to only support for basic authentication only.
>>>
>>> By using any of above designs validation and providing analytics
>>> data can be performed.  After enabling this user has to manually provide
>>> usernames and passwords which are authorized. Those usernames and passwords
>>> should be added into “micro-gw.conf” file which is using when
>>> micro-gateway is running in local machines or in docker after convert those
>>> sensitive values into hash values.
>>>
>>> To invoke the API user has to send the curl request with username
>>> and password as follows.
>>>
>>> curl -k -X GET "https://localhost:9095/test/v1.0/"; -H  "accept:
>>> application/json" -H "Authorization: Basic $(echo -n USERNAME:PASSWORD |
>>> base64)"
>>>
>>>
>>>
>>> --
>>> *Chamindu Udakara *
>>> *Software engineering Intern*
>>> WSO2  (University of Moratuwa)
>>> *mobile *: *+94 755285531*  |   *email *:  cudak...@gmail.com
>>> ___
>>> Architecture mailing list
>>> Architecture@wso2.org
>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>
>> ___
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>
>
> --
> *Chamindu Udakara *
> *Software engineering Intern*
> WSO2  (University of Moratuwa)
> *mobile *: *+94 755285531*  |   *email *:  cudak...@gmail.com
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>


-- 
Rajith Roshan
Senior Software Engineer, WSO2 Inc.
Mobile: +94-7 <%2B94-71-554-8430>17-064-214
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Cookie Based Authentication for Micro-gateway.

[Rajith Roshan]

*ProcessRequest*"
>>> which returns a string or an error. If any of the cookies included in
>>> request is not equal to given Id then the validation process will be
>>> failed. If it fails, then it throws an error and authnFilter will be
>>> failed. If any of session Id of a cookie matches with given one then that
>>> id will be returned to authnFilter for further execution at authnFilter.
>>>
>>> public function processRequest(http:Listener listener, http:Request
>>> request, http:FilterContext context)
>>>
>>>returns string|error {
>>>
>>>boolean isAuthorized;
>>>
>>>//get required cookie as config value
>>>
>>>string requiredCookie = config:getAsString(COOKIE_HEADER,
>>> default = "");
>>>
>>>//extraxt cookies from the incoming request
>>>
>>>string authHead = request.getHeader(COOKIE_HEADER);
>>>
>>>string[] cookies = authHead.trim().split(";");
>>>
>>>foreach cookie in cookies{
>>>
>>>io:println(cookie);
>>>
>>>string[] sessionIds = cookie.trim().split("=");
>>>
>>>string sessionId = sessionIds[1];
>>>
>>>if (sessionId == requiredCookie){
>>>
>>>return sessionId;
>>>
>>>}
>>>
>>>}
>>>
>>>error notFound = {message:"No matched cookie found"};
>>>
>>>return notFound;
>>>
>>> }
>>>
>>>
>>>
>>> *Chamindu Udakara *
>>> *Software engineering Intern*
>>> WSO2  (University of Moratuwa)
>>> *mobile *: *+94 755285531*  |   *email *:  cudak...@gmail.com
>>> ___
>>> Architecture mailing list
>>> Architecture@wso2.org
>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>
>> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>


-- 
*Rajith Roshan* | Senior Software Engineer | WSO2 Inc.
(m) +94-717-064-214 |  (e) raji...@wso2.com 

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

Re: [Architecture] API Manager integration with Istio

[Rajith Roshan]

On Thu, Jan 17, 2019 at 4:20 PM gayan gunawardana 
wrote:

> This is a great initiative.
> Small clarification, can there be overlapping features between Service
> Mesh and APIM such as rate limiting, end user authentication [1][2] ?
>
I think this is an key point. If Istio provides jwt based authentication,
how does our key manager can be placed here with oauth based
authentication.  Does it have any advantage over the provided jwt based
authentication.
If Istio provides rate limiting and enable to define custom policies, how
does out traffic manager can be placed in this architecture. AFAIU both do
the layer7 based rate limiting. So what is the advantage of using our TM

>
> [1] https://istio.io/docs/tasks/policy-enforcement/rate-limiting/
> [2] https://istio.io/help/ops/security/end-user-auth/
>
> Thanks,
> Gayan
>
> On Wed, Jan 16, 2019 at 11:16 PM Youcef HILEM 
> wrote:
>
>> Hi,
>> Good news.
>> Is there a link / dependency with the project
>> https://github.com/wso2/product-vick ?
>>
>> Thanks
>> Youcef HILEM
>>
>>
>>
>> --
>> Sent from:
>> http://wso2-oxygen-tank.10903.n7.nabble.com/WSO2-Architecture-f62919.html
>> ___
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>
>
> --
> Gayan
> _______
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>


-- 
*Rajith Roshan* | Senior Software Engineer | WSO2 Inc.
(m) +94-717-064-214 |  (e) raji...@wso2.com 

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

Re: [Architecture] Basic Authentication for APIM Gateway

[Rajith Roshan]

ssible caching mechanism for this.
>>>>>>>
>>>>>>> Since we do have mutual authentication as a security scheme, check
>>>>>>> the best way of providing the basic authentication
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Harsha
>>>>>>>
>>>>>>> On Fri, Feb 15, 2019 at 4:59 PM Chamod Samarajeewa 
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Adding architect...@wso2.com.
>>>>>>>>
>>>>>>>>
>>>>>>>> -- Forwarded message -
>>>>>>>> From: Nuwan Dias 
>>>>>>>> Date: Fri, Feb 15, 2019 at 3:01 PM
>>>>>>>> Subject: Re: Basic Authentication for APIM Gateway
>>>>>>>> To: Chamod Samarajeewa 
>>>>>>>> Cc: Architecture Team , APIM Team <
>>>>>>>> apim-gr...@wso2.com>
>>>>>>>>
>>>>>>>>
>>>>>>>> Chamod, this email should be sent to architecture@wso2.org.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> NuwanD.
>>>>>>>>
>>>>>>>> On Fri, Feb 15, 2019 at 2:37 PM Chamod Samarajeewa 
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> Hi All,
>>>>>>>>>
>>>>>>>>> I have included the information in the Github issue here as well.
>>>>>>>>>
>>>>>>>>> *Requirements*
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Provide authentication for APIM Gateway with basic authentication
>>>>>>>>> which uses usernames and passwords.
>>>>>>>>>
>>>>>>>>> *Introduction*
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Providing feature of enabling basic authentication security schema
>>>>>>>>> to product APIM Gateway along with OAuth2 token-based authentication. 
>>>>>>>>> The
>>>>>>>>> user will be benefited with using only OAuth2 token based 
>>>>>>>>> authentication
>>>>>>>>> alone, using basic authentication alone and using both schemas at the 
>>>>>>>>> same
>>>>>>>>> time.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> *Approach*
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> [image: Basic Auth - APIM-GW-2.jpg]
>>>>>>>>>
>>>>>>>>> curl -k -X GET "https://10.100.0.201:8243/pizzashack/1.0.0/menu";
>>>>>>>>> -H "accept: application/json" -H "Authorization: Basic $(echo -n
>>>>>>>>> username:password | base64)"
>>>>>>>>>
>>>>>>>>> The API Authentication Handler will forward the request to Basic
>>>>>>>>> Auth Authenticator or OAuth Authenticator based on the authorization 
>>>>>>>>> header
>>>>>>>>> of the request.
>>>>>>>>>
>>>>>>>>> Thank you. Regards.
>>>>>>>>>
>>>>>>>>> On Fri, Feb 15, 2019 at 2:20 PM Chamod Samarajeewa <
>>>>>>>>> cha...@wso2.com> wrote:
>>>>>>>>>
>>>>>>>>>> Hi All,
>>>>>>>>>>
>>>>>>>>>> I'm working on developing a new feature for APIM Gateway to
>>>>>>>>>> provide Basic Authentication support. You can find the details in the
>>>>>>>>>> following Github issue [1].
>>>>>>>>>>
>>>>>>>>>> I would really appreciate any feedback. Thank you.
>>>>>>>>>>
>>>>>>>>>> Best regards,
>>>>>>>>>> Chamod.
>>>>>>>>>>
>>>>>>>>>> [1] - https://github.com/wso2/carbon-apimgt/issues/5986
>>>>>>>>>> --
>>>>>>>>>> Chamod Samarajeewa | Software Engineer | WSO2 Inc.
>>>>>>>>>> (m) +94710397382 | Email: cha...@wso2.com 
>>>>>>>>>> GET INTEGRATION AGILE
>>>>>>>>>> Integration Agility for Digitally Driven Business
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Chamod Samarajeewa | Software Engineer | WSO2 Inc.
>>>>>>>>> (m) +94710397382 | Email: cha...@wso2.com 
>>>>>>>>> GET INTEGRATION AGILE
>>>>>>>>> Integration Agility for Digitally Driven Business
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> *Nuwan Dias* | Director | WSO2 Inc.
>>>>>>>> (m) +94 777 775 729 | (e) nuw...@wso2.com
>>>>>>>> [image: Signature.jpg]
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Chamod Samarajeewa | Software Engineer | WSO2 Inc.
>>>>>>>> (m) +94710397382 | Email: cha...@wso2.com 
>>>>>>>> GET INTEGRATION AGILE
>>>>>>>> Integration Agility for Digitally Driven Business
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>>
>>>>>>> *Harsha Kumara*
>>>>>>>
>>>>>>> Associate Technical Lead, WSO2 Inc.
>>>>>>> Mobile: +94775505618
>>>>>>> Email: hars...@wso2.coim
>>>>>>> Blog: harshcreationz.blogspot.com
>>>>>>>
>>>>>>> GET INTEGRATION AGILE
>>>>>>> Integration Agility for Digitally Driven Business
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Chamod Samarajeewa | Software Engineer | WSO2 Inc.
>>>>>> (m) +94710397382 | Email: cha...@wso2.com 
>>>>>> GET INTEGRATION AGILE
>>>>>> Integration Agility for Digitally Driven Business
>>>>>> ___
>>>>>> Architecture mailing list
>>>>>> Architecture@wso2.org
>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>>
>>>>> *Harsha Kumara*
>>>>>
>>>>> Associate Technical Lead, WSO2 Inc.
>>>>> Mobile: +94775505618
>>>>> Email: hars...@wso2.coim
>>>>> Blog: harshcreationz.blogspot.com
>>>>>
>>>>> GET INTEGRATION AGILE
>>>>> Integration Agility for Digitally Driven Business
>>>>> ___
>>>>> Architecture mailing list
>>>>> Architecture@wso2.org
>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>>>
>>>>
>>>>
>>>> --
>>>> Chamod Samarajeewa | Software Engineer | WSO2 Inc.
>>>> (m) +94710397382 | Email: cha...@wso2.com 
>>>> GET INTEGRATION AGILE
>>>> Integration Agility for Digitally Driven Business
>>>>
>>>
>>>
>>> --
>>> Chamod Samarajeewa | Software Engineer | WSO2 Inc.
>>> (m) +94710397382 | Email: cha...@wso2.com 
>>> GET INTEGRATION AGILE
>>> Integration Agility for Digitally Driven Business
>>>
>>
>>
>> --
>> *Nuwan Dias* | Director | WSO2 Inc.
>> (m) +94 777 775 729 | (e) nuw...@wso2.com
>> [image: Signature.jpg]
>> ___
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>


-- 
*Rajith Roshan* | Senior Software Engineer | WSO2 Inc.
(m) +94-717-064-214 |  (e) raji...@wso2.com 

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

Re: [Architecture] [APIM - Microgateway] Restructuring the Microgateway Project Folder Structure and Command Execution to Support Multiple APIs

[Rajith Roshan]

I think the commands
*micro-gw setup  , *
*and *
*micro-gw setup  -a  -oa  -e
*

 should be a single command when user already has a swagger. When we use
the second command it should create project structure as well as API
details as well. We don't need initial setup command to create project
structure. This will make automation processes difficult.

On Mon, Feb 25, 2019 at 5:03 PM Ishara Cooray  wrote:

> Hi,
>
> On Mon, Feb 25, 2019 at 3:41 PM Ishara Cooray  wrote:
>
>>
>> *Hi,*
>>
>> *micro-gw set-project *
>> I think setting the project name we can do within the *micro-gw setup*
>> command itself rather having another command.
>> *micro-gw setup  -a  -oa 
>> -e *
>>
>
> Yes, we can do that in this case. But if you want to switch between
> different projects, we can't use the setup command again and again. The
> setup command will work with the command -f. I don't think we can ask the
> user to use -f for switching between projects.
> Hence, we would need another command to set the project.
>
> Make sense..
> Having s separate command would be good in that case. However if *micro-gw
> setup command also able to do that, then set-project command will have to
> use only if needed.*
> *I think switching between projects may not be a frequent task.*
>
>
>> Can we have API_name different from the title in the swagger file?
>> I think if a different name is provided in the command, precedence will
>> be given to that API_name.
>>
>
> API Name or any other configs can be specified in the meta-data file. And
> that file get the precedence over the swagger.
>  Bit confused. Are there 3 different places that we can provide the
> API_name?
> If we give the option to provide API_name(or some parameter) regardless of
> it is optional or mandatory, we will have to clearly define which one is
> eventually be used in the underline logic.
> Could you please clarify?
>
>
>> Current Micro gateway is immutable so that if we want to update an api,
>> we will need to re-create the container/instance.
>> When we support multiple apis how are we going to handle this?
>> In that case i think we may need to have *micro-gw add-api *support for
>> bulk of apis.
>>
>
> In the microgateway approach there won't be many APIs and micro-gw add-api
> support should be able to handle.
>
> What is the expected max no of APIs per project?
> I think we can simply have a command that accepts APIs data as a file to
> cater this?
>
> Thanks & Regards,
> Ishara Cooray
> Associate Technical Lead
> Mobile : +9477 262 9512
> WSO2, Inc. | http://wso2.com/
> Lean . Enterprise . Middleware
>
>
> On Mon, Feb 25, 2019 at 4:03 PM Pubudu Gunatilaka 
> wrote:
>
>> Hi,
>>
>> On Mon, Feb 25, 2019 at 3:41 PM Ishara Cooray  wrote:
>>
>>>
>>> *Hi,*
>>>
>>> *micro-gw set-project *
>>> I think setting the project name we can do within the *micro-gw setup*
>>> command itself rather having another command.
>>> *micro-gw setup  -a  -oa 
>>> -e *
>>>
>>
>> Yes, we can do that in this case. But if you want to switch between
>> different projects, we can't use the setup command again and again. The
>> setup command will work with the command -f. I don't think we can ask the
>> user to use -f for switching between projects.
>>
>> Hence, we would need another command to set the project.
>>
>>>
>>> Can we have API_name different from the title in the swagger file?
>>> I think if a different name is provided in the command, precedence will
>>> be given to that API_name.
>>>
>>
>> API Name or any other configs can be specified in the meta-data file. And
>> that file get the precedence over the swagger.
>>
>>
>>>
>>> Current Micro gateway is immutable so that if we want to update an api,
>>> we will need to re-create the container/instance.
>>> When we support multiple apis how are we going to handle this?
>>> In that case i think we may need to have *micro-gw add-api *support for
>>> bulk of apis.
>>>
>>
>> In the microgateway approach there won't be many APIs and micro-gw
>> add-api support should be able to handle.
>>
>> Thank you!
>> --
>> *Pubudu Gunatilaka*
>> Committer and PMC Member - Apache Stratos
>> Associate Technical Lead
>> WSO2, Inc.: http://wso2.com
>> mobile : +94774078049 <%2B94772207163>
>>
>> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>


-- 
*Rajith Roshan* | Senior Software Engineer | WSO2 Inc.
(m) +94-717-064-214 |  (e) raji...@wso2.com 

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

Re: [Architecture] [APIM - Microgateway] Restructuring the Microgateway Project Folder Structure and Command Execution to Support Multiple APIs

[Rajith Roshan]

Hi all,
We need to figure out how to place global and per API mediation functions
also in the project structure.

On Tue, Feb 26, 2019 at 1:53 PM Viraj Gamage  wrote:

> Hi,
>
> I think the commands
> *micro-gw setup  , *
> *and *
> *micro-gw setup  -a  -oa  -e
> *
>
>  should be a single command when user already has a swagger. When we use
> the second command it should create project structure as well as API
> details as well. We don't need initial setup command to create project
> structure. This will make automation processes difficult.
>
> +1. If the user already has the swagger, he needs to execute only the
> second command. But the user can create project even without a swagger
> file, and add a swagger file later. That is the purpose of having two
> commands to setup the project.
>
> On Tue, Feb 26, 2019 at 12:31 PM Rajith Roshan  wrote:
>
>> I think the commands
>> *micro-gw setup  , *
>> *and *
>> *micro-gw setup  -a  -oa 
>> -e *
>>
>>  should be a single command when user already has a swagger. When we use
>> the second command it should create project structure as well as API
>> details as well. We don't need initial setup command to create project
>> structure. This will make automation processes difficult.
>>
>> On Mon, Feb 25, 2019 at 5:03 PM Ishara Cooray  wrote:
>>
>>> Hi,
>>>
>>> On Mon, Feb 25, 2019 at 3:41 PM Ishara Cooray  wrote:
>>>
>>>>
>>>> *Hi,*
>>>>
>>>> *micro-gw set-project *
>>>> I think setting the project name we can do within the *micro-gw setup*
>>>> command itself rather having another command.
>>>> *micro-gw setup  -a  -oa 
>>>> -e *
>>>>
>>>
>>> Yes, we can do that in this case. But if you want to switch between
>>> different projects, we can't use the setup command again and again. The
>>> setup command will work with the command -f. I don't think we can ask the
>>> user to use -f for switching between projects.
>>> Hence, we would need another command to set the project.
>>>
>>> Make sense..
>>> Having s separate command would be good in that case. However if *micro-gw
>>> setup command also able to do that, then set-project command will have to
>>> use only if needed.*
>>> *I think switching between projects may not be a frequent task.*
>>>
>>>
>>>> Can we have API_name different from the title in the swagger file?
>>>> I think if a different name is provided in the command, precedence will
>>>> be given to that API_name.
>>>>
>>>
>>> API Name or any other configs can be specified in the meta-data file.
>>> And that file get the precedence over the swagger.
>>>  Bit confused. Are there 3 different places that we can provide the
>>> API_name?
>>> If we give the option to provide API_name(or some parameter) regardless
>>> of it is optional or mandatory, we will have to clearly define which one is
>>> eventually be used in the underline logic.
>>> Could you please clarify?
>>>
>>>
>>>> Current Micro gateway is immutable so that if we want to update an api,
>>>> we will need to re-create the container/instance.
>>>> When we support multiple apis how are we going to handle this?
>>>> In that case i think we may need to have *micro-gw add-api *support
>>>> for bulk of apis.
>>>>
>>>
>>> In the microgateway approach there won't be many APIs and micro-gw
>>> add-api support should be able to handle.
>>>
>>> What is the expected max no of APIs per project?
>>> I think we can simply have a command that accepts APIs data as a file to
>>> cater this?
>>>
>>> Thanks & Regards,
>>> Ishara Cooray
>>> Associate Technical Lead
>>> Mobile : +9477 262 9512
>>> WSO2, Inc. | http://wso2.com/
>>> Lean . Enterprise . Middleware
>>>
>>>
>>> On Mon, Feb 25, 2019 at 4:03 PM Pubudu Gunatilaka 
>>> wrote:
>>>
>>>> Hi,
>>>>
>>>> On Mon, Feb 25, 2019 at 3:41 PM Ishara Cooray  wrote:
>>>>
>>>>>
>>>>> *Hi,*
>>>>>
>>>>> *micro-gw set-project *
>>>>> I think setting the project name we can do within the *micro-gw setup*
>>>>> command itself rather having another command.
>>>>> *micro-gw setup  -a  -oa
>>>>>  -e *
>>

Re: [Architecture] Decoupling API Manager and API Microgateway

[Rajith Roshan]

>
>>>>>>>
>>>>>>> which are bounded to API Manager 2.6.0
>>>>>>>
>>>>>>>
>>>>>>> *Solution*:
>>>>>>>
>>>>>>> Furthermore, there is a toolkit-config.toml file to setup
>>>>>>> configurations. We can avoid above constants by specifying these URLs as
>>>>>>> below in that file.
>>>>>>>
>>>>>>>
>>>>>>> publisherEndpoint = "https://localhost:9443/api/am/publisher/v0.13";
>>>>>>>
>>>>>>> adminEndpoint = "https://localhost:9443/api/am/admin/v0.13";
>>>>>>>
>>>>>>> registrationEndpoint = "
>>>>>>> https://localhost:9443/client-registration/v0.13/register";
>>>>>>>
>>>>>>> tokenEndpoint = "https://localhost:9443/oauth2/token";
>>>>>>>
>>>>>>>
>>>>>>> So a user can specify REST API version manually.
>>>>>>>
>>>>>>>
>>>>>>> *Suggested improvement:*
>>>>>>>
>>>>>>> Instead of specifying REST API version and these endpoints, allow
>>>>>>> the user to only add the API Manager version. The configuration file 
>>>>>>> will
>>>>>>> include fields similar to the following.
>>>>>>>
>>>>>>> apimVersion = “2.5.0”
>>>>>>>
>>>>>>> publisherEndpoint = "https://localhost:9443/api/am/publisher/";
>>>>>>>
>>>>>>> adminEndpoint = "https://localhost:9443/api/am/admin/";
>>>>>>>
>>>>>>> registrationEndpoint = "
>>>>>>> https://localhost:9443/client-registration/{version}/register";
>>>>>>>
>>>>>>> tokenEndpoint = "https://localhost:9443/oauth2/token";
>>>>>>>
>>>>>>>
>>>>>>> *Implementation:*
>>>>>>>
>>>>>>> In order to implement as above, we need to recognize the REST API
>>>>>>> version which corresponds to the API Manager version. Following 
>>>>>>> approaches
>>>>>>> are identified;
>>>>>>>
>>>>>>>
>>>>>>> 1. Get the version of the REST API of the specific API Manager
>>>>>>> version by using the API Manager’s swagger definition. However, an 
>>>>>>> endpoint
>>>>>>> to access swagger definition is not provided in API Manager 2.x
>>>>>>>
>>>>>>> 2. Profile REST API version for each API Manager version in
>>>>>>> Microgateway. (Drawback of this approach is that, Microgateway will only
>>>>>>> provide backward compatibility(compatible only to past API Manager
>>>>>>> versions) because new versions of API Manager which are released later 
>>>>>>> may
>>>>>>> not be included yet in version profiling.)
>>>>>>>
>>>>>>>
>>>>>>> Among them, the second option is selected. Version profiling in
>>>>>>> Microgateway is more suited considering time constraints and simplicity.
>>>>>>>
>>>>>>>
>>>>>>> I would really appreciate your feedback. Thank you.
>>>>>>>
>>>>>>>
>>>>>>> *Reference:*
>>>>>>>
>>>>>>> [1] https://github.com/wso2/product-microgateway/issues/301
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> *Amali Lakshika*
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> *Software EngineerWSO2 Inc.: https://wso2.com
>>>>>> <http://wso2.com/>lean.enterprise.middle-waremobile: **+94 71 932
>>>>>> 1861*
>>>>>>
>>>>>> *skype: amali.94d*
>>>>>>
>>>>>> <http://wso2.com/signature>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> *Amali Lakshika*
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> *Software EngineerWSO2 Inc.: https://wso2.com
>>>>> <http://wso2.com/>lean.enterprise.middle-waremobile: **+94 71 932
>>>>> 1861*
>>>>>
>>>>> *skype: amali.94d*
>>>>>
>>>>> <http://wso2.com/signature>
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> *Nuwan Dias* | Director | WSO2 Inc.
>>>> (m) +94 777 775 729 | (e) nuw...@wso2.com
>>>> [image: Signature.jpg]
>>>> ___
>>>> Architecture mailing list
>>>> Architecture@wso2.org
>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>>
>>>
>>>
>>> --
>>> *Naduni Pamudika*
>>> Senior Software Engineer | WSO2
>>>
>>> Mobile: +94 719 143658 <+94%2071%20914%203658>
>>> LinkedIn: https://lk.linkedin.com/in/naduni-pamudika
>>> Blog: https://medium.com/@naduni_pamudika
>>> [image: http://wso2.com/signature] <http://wso2.com/signature>
>>>
>>
>>
>> --
>> *Amali Lakshika*
>>
>>
>>
>>
>> *Software EngineerWSO2 Inc.: https://wso2.com
>> <http://wso2.com/>lean.enterprise.middle-waremobile: **+94 71 932 1861*
>>
>> *skype: amali.94d*
>>
>> <http://wso2.com/signature>
>>
>>
>
>
> --
> *Naduni Pamudika*
> Senior Software Engineer | WSO2
>
> Mobile: +94 719 143658 <+94%2071%20914%203658>
> LinkedIn: https://lk.linkedin.com/in/naduni-pamudika
> Blog: https://medium.com/@naduni_pamudika
> [image: http://wso2.com/signature] <http://wso2.com/signature>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>


-- 
*Rajith Roshan* | Senior Software Engineer | WSO2 Inc.
(m) +94-717-064-214 |  (e) raji...@wso2.com 

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

Re: [Architecture] [Microgateway] API Manager JWT Token Revocation Feature

[Rajith Roshan]

t;>>> only needs to store the unexpired revoked token information.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I also feel that we need to introduce a config to switch on
>>>>>>>>>>>>>> enabling/disabling this feature so that we can also use the 
>>>>>>>>>>>>>> microgateways
>>>>>>>>>>>>>> in the current mode.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Thu, Feb 7, 2019 at 3:58 PM Sanjeewa Malalgoda <
>>>>>>>>>>>>>> sanje...@wso2.com> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Hi All,
>>>>>>>>>>>>>>> I'm initiating this mail thread to discuss more about JWT
>>>>>>>>>>>>>>> token revocation feature we are planning to implement for API 
>>>>>>>>>>>>>>> Manager
>>>>>>>>>>>>>>> micro-gateway. In API Manager micro-gateway we do support both 
>>>>>>>>>>>>>>> oauth access
>>>>>>>>>>>>>>> tokens and JWT access tokens. When we use OAuth access tokens 
>>>>>>>>>>>>>>> we can revoke
>>>>>>>>>>>>>>> them and make it effect immediately. Since all OAuth tokens 
>>>>>>>>>>>>>>> geting
>>>>>>>>>>>>>>> validated with key manager revoked tokens will fail validation. 
>>>>>>>>>>>>>>> When we use
>>>>>>>>>>>>>>> JWT token we do token validation within gateway itself without 
>>>>>>>>>>>>>>> calling key
>>>>>>>>>>>>>>> manager or external party. Since JWT is self contained one we 
>>>>>>>>>>>>>>> are basically
>>>>>>>>>>>>>>> trust its content as long as token not expired and signature 
>>>>>>>>>>>>>>> valid. Then it
>>>>>>>>>>>>>>> will be a problem.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> So we will need to have some mechanism to propagate revoked
>>>>>>>>>>>>>>> token details to micro-gateways as well. Since self contained 
>>>>>>>>>>>>>>> token
>>>>>>>>>>>>>>> revocation is ineffective(there can be multiple token contents 
>>>>>>>>>>>>>>> for same
>>>>>>>>>>>>>>> valid JTI due to generated time and signature changes) most 
>>>>>>>>>>>>>>> suitable way of
>>>>>>>>>>>>>>> doing this is using JTI to identify revoked tokens. When JWT 
>>>>>>>>>>>>>>> revoked we
>>>>>>>>>>>>>>> need to revoke it using JTI. If we can send revoked JTI list to
>>>>>>>>>>>>>>> micro-gateway then we can check that as part of key validation 
>>>>>>>>>>>>>>> process.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> We need to find a way to send revoked JTI to microgateways,
>>>>>>>>>>>>>>> Pub/sub model - all gateways need to subscribe to topic and
>>>>>>>>>>>>>>> get updated about revoked tokens.
>>>>>>>>>>>>>>> Pull Model - micro-gateways will call key manager or
>>>>>>>>>>>>>>> management server and get update about revoked tokens
>>>>>>>>>>>>>>> Push Model - Management server or key manager plugin will
>>>>>>>>>>>>>>> call all deployed micro services and send revoked JWT list.
>>>>>>>>>>>>>>> Each of these methods will have their own advantages and
>>>>>>>>>>>>>>> disadvantages. Lets use this mail to discuss those in detail 
>>>>>>>>>>>>>>> and come to
>>>>>>>>>>>>>>> conclusion.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>> sanjeewa.
>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>> *Sanjeewa Malalgoda*
>>>>>>>>>>>>>>> Software Architect | Associate Director, Engineering - WSO2
>>>>>>>>>>>>>>> Inc.
>>>>>>>>>>>>>>> (m) +94 712933253 | (e) sanje...@wso2.com | (b) Blogger
>>>>>>>>>>>>>>> <http://sanjeewamalalgoda.blogspot.com>, Medium
>>>>>>>>>>>>>>> <https://medium.com/@sanjeewa190>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> GET INTEGRATION AGILE <https://wso2.com/signature>
>>>>>>>>>>>>>>> Integration Agility for Digitally Driven Business
>>>>>>>>>>>>>>> ___
>>>>>>>>>>>>>>> Architecture mailing list
>>>>>>>>>>>>>>> Architecture@wso2.org
>>>>>>>>>>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> --
>>>>>>>>>>>>>> Thanks & Regards,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> *Fazlan Nazeem*
>>>>>>>>>>>>>> Associate Technical Lead
>>>>>>>>>>>>>> WSO2 Inc
>>>>>>>>>>>>>> Mobile : +94772338839
>>>>>>>>>>>>>> fazl...@wso2.com
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> --
>>>>>>>>>>>>> *Nuwan Dias* | Director | WSO2 Inc.
>>>>>>>>>>>>> (m) +94 777 775 729 | (e) nuw...@wso2.com
>>>>>>>>>>>>> [image: Signature.jpg]
>>>>>>>>>>>>> ___
>>>>>>>>>>>>> Architecture mailing list
>>>>>>>>>>>>> Architecture@wso2.org
>>>>>>>>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>> *Sanjeewa Malalgoda*
>>>>>>>>>>>> Software Architect | Associate Director, Engineering - WSO2 Inc.
>>>>>>>>>>>> (m) +94 712933253 | (e) sanje...@wso2.com | (b) Blogger
>>>>>>>>>>>> <http://sanjeewamalalgoda.blogspot.com>, Medium
>>>>>>>>>>>> <https://medium.com/@sanjeewa190>
>>>>>>>>>>>>
>>>>>>>>>>>> GET INTEGRATION AGILE <https://wso2.com/signature>
>>>>>>>>>>>> Integration Agility for Digitally Driven Business
>>>>>>>>>>>> ___
>>>>>>>>>>>> Architecture mailing list
>>>>>>>>>>>> Architecture@wso2.org
>>>>>>>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> *Nuwan Dias* | Director | WSO2 Inc.
>>>>>>>>>>> (m) +94 777 775 729 | (e) nuw...@wso2.com
>>>>>>>>>>> [image: Signature.jpg]
>>>>>>>>>>> ___
>>>>>>>>>>> Architecture mailing list
>>>>>>>>>>> Architecture@wso2.org
>>>>>>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> *1G*
>>>>>>>>>> ___
>>>>>>>>>> Architecture mailing list
>>>>>>>>>> Architecture@wso2.org
>>>>>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> *Nuwan Dias* | Director | WSO2 Inc.
>>>>>>>>> (m) +94 777 775 729 | (e) nuw...@wso2.com
>>>>>>>>> [image: Signature.jpg]
>>>>>>>>> ___
>>>>>>>>> Architecture mailing list
>>>>>>>>> Architecture@wso2.org
>>>>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>>
>>>>>>>> *Sampath Rajapakse* | Software Engineer | WSO2 Inc.
>>>>>>>>
>>>>>>>> +94717313761 | samp...@wso2.com
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> *Sanjeewa Malalgoda*
>>>>>>> Software Architect | Associate Director, Engineering - WSO2 Inc.
>>>>>>> (m) +94 712933253 | (e) sanje...@wso2.com | (b) Blogger
>>>>>>> <http://sanjeewamalalgoda.blogspot.com>, Medium
>>>>>>> <https://medium.com/@sanjeewa190>
>>>>>>>
>>>>>>> GET INTEGRATION AGILE <https://wso2.com/signature>
>>>>>>> Integration Agility for Digitally Driven Business
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>>
>>>>>> *Sampath Rajapakse* | Software Engineer | WSO2 Inc.
>>>>>>
>>>>>> +94717313761 | samp...@wso2.com
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> --
>>>>>
>>>>> *Sampath Rajapakse* | Software Engineer | WSO2 Inc.
>>>>>
>>>>> +94717313761 | samp...@wso2.com
>>>>>
>>>>>
>>>>>
>>>>
>>>> --
>>>>
>>>> *Harsha Kumara*
>>>>
>>>> Associate Technical Lead, WSO2 Inc.
>>>> Mobile: +94775505618
>>>> Email: hars...@wso2.coim
>>>> Blog: harshcreationz.blogspot.com
>>>>
>>>> GET INTEGRATION AGILE
>>>> Integration Agility for Digitally Driven Business
>>>>
>>>
>>>
>>> --
>>> Hasintha Indrajee
>>> WSO2, Inc.
>>> Mobile:+94 771892453
>>>
>>> ___
>>> Architecture mailing list
>>> Architecture@wso2.org
>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>
>>
>>
>> --
>> Pushpalanka.
>> --
>> Pushpalanka Jayawardhana, B.Sc.Eng.(Hons).
>> Associate Tech Lead, 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
>>
>
>
> --
> *1G*
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>


-- 
*Rajith Roshan* | Associate Technical Lead | WSO2 Inc.
(m) +94-717-064-214 |  (e) raji...@wso2.com 

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

Re: [Architecture] [Dev] [DEV] [VOTE] Release WSO2 API Microgateway 3.0.0 RC1

[Rajith Roshan]

Hi all,
We will be closing this vote as we have found  issues related to analytics
publishing, import apis with labels. We will  call upon another vote once
these issues are fixed.

Thanks!
Rajith

On Fri, May 24, 2019 at 12:34 PM Praminda Jayawardana 
wrote:

> Tested followings, (not on docker, k8s)
>
>- Product quick start
>- Endpoint overriding (dev first)
>- API/Resource level request and response interceptors
>- Disabling security at resource level
>- Defining auth schemes + scopes
>- Basic auth
>- Basic auth secured backends
>
> [+] Stable - Go ahead and release.
>
> On Fri, May 24, 2019 at 11:12 AM Hasunie Adikari  wrote:
>
>>
>> Tested the following scenarios.
>>
>> - Follow the dev first approach and build the pet-store project.
>>
>>   - Override endpoint per resource.
>>
>>   - API / resource level request interceptors.
>>
>>   - Schema validation.
>>
>> - Import API from APIM manager and tested.
>>
>> [+] Stable - Go ahead and release.
>>
>>
>>
>> Regards,
>>
>> Hasunie
>>
>>
>>
>> On Tue, May 21, 2019 at 10:02 PM Praminda Jayawardana 
>> wrote:
>>
>>> Hi All,
>>>
>>> WSO2 Api Manager team is pleased to announce the first release candidate
>>> of WSO2 API Microgateway 3.0.0.
>>>
>>> The WSO2 API Microgateway is a lightweight, gateway distribution (WSO2
>>> API Microgateway) which can be used with single or multiple APIs.
>>>
>>> Please find the improvements and fixes related to this release in Fixed
>>> issues
>>> <https://github.com/wso2/product-microgateway/issues?utf8=%E2%9C%93&q=is%3Aissue+closed%3A2018-10-12..2019-05-21>
>>>
>>> Download the product from here
>>> <https://github.com/wso2/product-microgateway/releases/tag/v3.0.0-rc1>
>>>
>>> The Tag to be voted upon is
>>> https://github.com/wso2/product-microgateway/releases/tag/v3.0.0-rc1
>>>
>>> Please download, test the product and vote.
>>>
>>> *[+] Stable - Go ahead and release*
>>>
>>> *[-] Broken - Do not release *(explain why)
>>>
>>>
>>> Documentation: https://docs.wso2.com/display/MG300/
>>>
>>> Best Regards,
>>> WSO2 API Manager Team
>>>
>>
>>
>> --
>> *Hasunie Adikari*
>> Senior Software Engineer
>> WSO2 Inc.; http://wso2.com
>> lean.enterprise.middleware
>> blog http://hasuniea.blogspot.com | https://medium.com/@Hasunie/
>> Mobile:+94713095876
>>
>>
>
> --
>
> *Praminda Jayawardana* | Senior Software Engineer | WSO2 Inc.
> (m) +94 (0) 716 590918 | (e) prami...@wso2.com
> GET INTEGRATION AGILE
> Integration Agility for Digitally Driven Business
> ___
> Dev mailing list
> d...@wso2.org
> http://wso2.org/cgi-bin/mailman/listinfo/dev
>


-- 
*Rajith Roshan* | Associate Technical Lead | WSO2 Inc.
(m) +94-717-064-214 |  (e) raji...@wso2.com 

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

Re: [Architecture] [DEV] [VOTE] Release WSO2 API Microgateway 3.0.1 RC2

[Rajith Roshan]

Tested the following scenarios.


   - Basic throttling
   - Custom application throttling for open API based api and imported APIs
   - Custom subscription throttling for imported APIs
   - Global throttling
   - Basic flow in dev first approach

No blockers found.
*[+] Stable - Go ahead and release*

Thanks!
Rajith

On Fri, Jun 7, 2019 at 9:59 AM Praminda Jayawardana 
wrote:

> Hi All,
>
> WSO2 Api Manager team is pleased to announce the second release candidate
> of WSO2 API Microgateway 3.0.1.
>
> The WSO2 API Microgateway is a lightweight, gateway distribution which can
> be used with single or multiple APIs.
>
> Please find the improvements and fixes related to this release in Fixed
> issues
> <https://github.com/wso2/product-microgateway/issues?utf8=%E2%9C%93&q=is%3Aissue+closed%3A2018-10-12..2019-06-07>
>
> Download the product from here
> <https://github.com/wso2/product-microgateway/releases/tag/v3.0.1-rc2>
>
> The Tag to be voted upon is
> https://github.com/wso2/product-microgateway/releases/tag/v3.0.1-rc2
>
> Please download, test the product and vote.
>
> *[+] Stable - Go ahead and release*
>
> *[-] Broken - Do not release *(explain why)
>
>
> Documentation: https://docs.wso2.com/display/MG301/
>
> Best Regards,
> WSO2 API Manager Team
>


-- 
*Rajith Roshan* | Associate Technical Lead | WSO2 Inc.
(m) +94-717-064-214 |  (e) raji...@wso2.com 

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

Re: [Architecture] [DEV] [VOTE] Release WSO2 API Microgateway 3.0.1 RC3

[Rajith Roshan]

Tested the following scenarios.


   - Basic throttling
   - Custom application throttling for open API based api and imported APIs
   - Custom subscription throttling for imported APIs
   - Global throttling
   - Basic flow in dev first approach
   - Load balance and fail over endpoints

No blockers found.
*[+] Stable - Go ahead and release*

Thanks!
Rajith

On Sun, Jun 9, 2019 at 10:25 AM Praminda Jayawardana 
wrote:

> Hi All,
>
> WSO2 Api Manager team is pleased to announce the third release candidate
> of WSO2 API Microgateway 3.0.1.
>
> The WSO2 API Microgateway is a lightweight, gateway distribution which can
> be used with single or multiple APIs.
>
> Please find the improvements and fixes related to this release in Fixed
> issues
> <https://github.com/wso2/product-microgateway/issues?utf8=%E2%9C%93&q=is%3Aissue+closed%3A2018-10-12..2019-06-09>
>
> Download the product from here
> <https://github.com/wso2/product-microgateway/releases/tag/v3.0.1-rc3>
>
> The Tag to be voted upon is
> https://github.com/wso2/product-microgateway/releases/tag/v3.0.1-rc3
>
> Please download, test the product and vote.
>
> *[+] Stable - Go ahead and release*
>
> *[-] Broken - Do not release *(explain why)
>
>
> Documentation: https://docs.wso2.com/display/MG301/
>
> Best Regards,
> WSO2 API Manager Team
>


-- 
*Rajith Roshan* | Associate Technical Lead | WSO2 Inc.
(m) +94-717-064-214 |  (e) raji...@wso2.com 

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

Re: [Architecture] JWT Authentication for API Gateway

[Rajith Roshan]

t;>>>>> {
>>>>>>>>   "aud": "http://org.wso2.apimgt/gateway";,
>>>>>>>>   "sub": "admin@carbon.super",
>>>>>>>>   "application": {
>>>>>>>> "owner": "admin",
>>>>>>>> "tier": "Unlimited",
>>>>>>>> "name": "DefaultApplication",
>>>>>>>> "id": 1
>>>>>>>>   },
>>>>>>>>   "scope": "am_application_scope default",
>>>>>>>>   "iss": "https://localhost:9443/oauth2/token";,
>>>>>>>>   "keytype": "PRODUCTION",
>>>>>>>>   "subscribedAPIs": [
>>>>>>>> {
>>>>>>>>   "subscriberTenantDomain": "carbon.super",
>>>>>>>>   "name": "PizzaShackAPI",
>>>>>>>>   "context": "/pizzashack/1.0.0",
>>>>>>>>   "publisher": "admin",
>>>>>>>>   "version": "1.0.0",
>>>>>>>>   "subscriptionTier": "Gold"
>>>>>>>> }
>>>>>>>>   ],
>>>>>>>>   "consumerKey": "tRfDHrQNasyVaCVv1Ej4GnR2bD0a",
>>>>>>>>   "exp": 1561701126,
>>>>>>>>   "iat": 1561697526,
>>>>>>>>   "jti": "39d826ca-a56b-4637-b799-sa1ba4bbf24d"
>>>>>>>> }
>>>>>>>>
>>>>>>>> We are hoping to use the same caches used for OAuth tokens to store
>>>>>>>> the JWT tokens as well. In that scenario, the payload will be stored 
>>>>>>>> as a
>>>>>>>> JSONObject in the cache as the value and the key will be the "jti" 
>>>>>>>> value
>>>>>>>> (Unique identifier of the token) of the token.
>>>>>>>>
>>>>>>>> The swagger stored in the gateway as a local entry will be used to
>>>>>>>>  - retrieve the missing information in the payload of JWT token
>>>>>>>> such as "API tier"
>>>>>>>>  - retrieve scopes bound to the resource for scope validation
>>>>>>>>
>>>>>>>> The related Git issue can be found here [1]. I would really
>>>>>>>> appreciate any feedback. Thank you.
>>>>>>>>
>>>>>>>> Best regards,
>>>>>>>> Chamod.
>>>>>>>>
>>>>>>>> [1] - https://github.com/wso2/product-apim/issues/5115
>>>>>>>>
>>>>>>>> --
>>>>>>>> Chamod Samarajeewa | Software Engineer | WSO2 Inc.
>>>>>>>> (m) +94710397382 | Email: cha...@wso2.com 
>>>>>>>> GET INTEGRATION AGILE
>>>>>>>> Integration Agility for Digitally Driven Business
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>>
>>>>>>> *Harsha Kumara*
>>>>>>>
>>>>>>> Technical Lead, WSO2 Inc.
>>>>>>> Mobile: +94775505618
>>>>>>> Email: hars...@wso2.coim
>>>>>>> Blog: harshcreationz.blogspot.com
>>>>>>>
>>>>>>> GET INTEGRATION AGILE
>>>>>>> Integration Agility for Digitally Driven Business
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Chamod Samarajeewa | Software Engineer | WSO2 Inc.
>>>>>> (m) +94710397382 | Email: cha...@wso2.com 
>>>>>> GET INTEGRATION AGILE
>>>>>> Integration Agility for Digitally Driven Business
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Thanks & Regards,
>>>>>
>>>>> *Fazlan Nazeem | *Associate Technical Lead | WSO2 Inc
>>>>> Mobile : +94772338839 | fazl...@wso2.com
>>>>>
>>>>>
>>>>>
>>>>
>>>> --
>>>> Chamod Samarajeewa | Software Engineer | WSO2 Inc.
>>>> (m) +94710397382 | Email: cha...@wso2.com 
>>>> GET INTEGRATION AGILE
>>>> Integration Agility for Digitally Driven Business
>>>>
>>>
>>>
>>> --
>>> Rukshan C. Premathunga | Associate Technical Lead | WSO2 Inc.
>>> (m) +94711822074 | (w) +94112145345 | Email: ruks...@wso2.com
>>> GET INTEGRATION AGILE
>>> Integration Agility for Digitally Driven Business
>>>
>>
>>
>> --
>> Malintha Amarasinghe
>> *WSO2, Inc. - lean | enterprise | middleware*
>> http://wso2.com/
>>
>> Mobile : +94 712383306
>>
>
>
> --
>
> *Harsha Kumara*
>
> Technical Lead, WSO2 Inc.
> Mobile: +94775505618
> Email: hars...@wso2.coim
> Blog: harshcreationz.blogspot.com
>
> GET INTEGRATION AGILE
> Integration Agility for Digitally Driven Business
>


-- 
*Rajith Roshan* | Associate Technical Lead | WSO2 Inc.
(m) +94-717-064-214 |  (e) raji...@wso2.com 

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

Re: [Architecture] [Dev] OAS 3 as default API definition

[Rajith Roshan]

On Tue, Aug 13, 2019 at 2:48 PM Thilini Shanika  wrote:

> Even though OAS 2.0 support is deprecated, we should carefully handle the
> use cases of OAS 2.0 supported APIs which have been migrated from previous
> versions. In that case, still, we have to maintain the current
> implementation(Both in UI and backend) to handle functionalities of two
> versions.
>
> @Rajith Roshan  , @Praminda Jayawardana
> 
> How this would affect micro gateway?
>
Microgateway handles the swagger parsing based on the swagger version. When
APIs are imported from api manager it will , check the swagger version and
use the correct parser. So I don't think this would be an issue.

>
> On Tue, Aug 13, 2019 at 2:21 PM Dushan Silva  wrote:
>
>> Hi,
>> I also think since this is a major release it is a good time to move
>> 3.0.0 however if we think from users perspective we should consider the
>> however not supporting 2.0 would effect. If we are planning on supporting a
>> conversion between 2.0 to 3.0 then definitely +1 for this.
>>
>> Thanks
>>
>> On Mon, Aug 12, 2019 at 12:08 PM Malintha Amarasinghe 
>> wrote:
>>
>>>
>>>
>>> On Mon, Aug 12, 2019 at 11:21 AM Rukshan Premathunga 
>>> wrote:
>>>
>>>>
>>>>
>>>> On Mon, Aug 12, 2019 at 11:16 AM Thilini Shanika 
>>>> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Mon, Aug 12, 2019 at 10:53 AM Rukshan Premathunga 
>>>>> wrote:
>>>>>
>>>>>> Hi All,
>>>>>>
>>>>>> ATM generated API definition is in swagger 2. Can we make it OAS 3
>>>>>> for the new APIs?
>>>>>>
>>>>> Yes, we can change the default version of a newly created API to OAS
>>>>> 3.0.0. However, the API creator is allowed to pick the OAS version(OAS 2 
>>>>> or
>>>>> 3) of the API during API creation time. Are you suggesting to remove the
>>>>> default support for OAS 2.0(For newly designed APIs)?
>>>>>
>>>> Yes, my suggestion is, if a user doesn't have an OAS definition,
>>>> generate an OAS 3 definition for them. If they have an OAS definition,
>>>> allowing them to import OAS 2 or 3 definition. So we will maintain the same
>>>> OAS version afterward.
>>>>
>>>
>>> I also think this would be okay. If anyone wants to stick with OAS 2.0,
>>> they have an import OAS 2.0 option.
>>> Maintaining two different API designers at UI level would not be good in
>>> terms of maintenance. We would one day anyway have to move to the designer
>>> to 3.0.0 as we did for 1.2 -> 2.0 in the past. Since this is a major
>>> release, this is a good time to do it as Pubudu said. @Rukshan
>>> Premathunga ,  if we move to 3.0.0, can we completely
>>> remove the UI designer code used for 2.0 and keep only 3.0.0 related code?
>>>
>>> Thanks!
>>>
>>>>
>>>>
>>> When new API is created from an OAS 2 or 3, we can create from the same
>>>>>> imported version. Existing API also can be kept as an existing version.
>>>>>>
>>>>>> Thanks and Regards
>>>>>>
>>>>>> --
>>>>>> Rukshan C. Premathunga | Associate Technical Lead | WSO2 Inc.
>>>>>> (m) +94711822074 | (w) +94112145345 | Email: ruks...@wso2.com
>>>>>> GET INTEGRATION AGILE
>>>>>> Integration Agility for Digitally Driven Business
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Thilini Shanika
>>>>> Associate Technical Lead
>>>>> WSO2, Inc.; http://wso2.com
>>>>> 20, Palmgrove Avenue, Colombo 3
>>>>>
>>>>>
>>>>>
>>>>
>>>> --
>>>> Rukshan C. Premathunga | Associate Technical Lead | WSO2 Inc.
>>>> (m) +94711822074 | (w) +94112145345 | Email: ruks...@wso2.com
>>>> GET INTEGRATION AGILE
>>>> Integration Agility for Digitally Driven Business
>>>>
>>>
>>>
>>> --
>>> Malintha Amarasinghe
>>> *WSO2, Inc. - lean | enterprise | middleware*
>>> http://wso2.com/
>>>
>>> Mobile : +94 712383306
>>> ___
>>> Dev mailing list
>>> d...@wso2.org
>>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>>
>>
>>
>> --
>> Best Regards
>> Dushan Silva
>> Software Engineer
>>
>> *WSO2, Inc. *
>>
>> lean . enterprise . middleware
>> Mob: +94 774 979042
>> ___
>> Dev mailing list
>> d...@wso2.org
>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>
>
>
> --
> Thilini Shanika
> Associate Technical Lead
> WSO2, Inc.; http://wso2.com
> 20, Palmgrove Avenue, Colombo 3
>
>
>

-- 
*Rajith Roshan* | Associate Technical Lead | WSO2 Inc.
(m) +94-717-064-214 |  (e) raji...@wso2.com 

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

Re: [Architecture] [Dev] OAS 3 as default API definition

[Rajith Roshan]

On Tue, Aug 13, 2019 at 8:53 PM Rukshan Premathunga 
wrote:

>
>
> On Tue, Aug 13, 2019 at 7:39 PM Rajith Roshan  wrote:
>
>>
>>
>> On Tue, Aug 13, 2019 at 2:48 PM Thilini Shanika 
>> wrote:
>>
>>> Even though OAS 2.0 support is deprecated, we should carefully handle
>>> the use cases of OAS 2.0 supported APIs which have been migrated from
>>> previous versions. In that case, still, we have to maintain the current
>>> implementation(Both in UI and backend) to handle functionalities of two
>>> versions.
>>>
>>> @Rajith Roshan  , @Praminda Jayawardana
>>> 
>>> How this would affect micro gateway?
>>>
>> Microgateway handles the swagger parsing based on the swagger version.
>> When APIs are imported from api manager it will , check the swagger version
>> and use the correct parser. So I don't think this would be an issue.
>>
> had a discussion with Thilini and Praminda, and noticed MG use V3 parser.
> But it seems v3 parser doesn't validate the content but parse the
> definition with existing information. I think it is not enough for this use
> case. I think we need to use both v2 and v3 parser after identifying the
> OAS version. ATM we have parsed the definition with both v2 and v3 to
> identify the correct OAS version. @Rajith Roshan   what
> is the mechanism you have used to identify the version.
>
please find the logic used to identify the version in here[1]

[1] -
https://github.com/wso2/product-microgateway/blob/master/components/micro-gateway-cli/src/main/java/org/wso2/apimgt/gateway/cli/utils/OpenAPICodegenUtils.java#L113


> If there anything in the current approach, please suggest if there are any
> other alternatives.
>
>>
>>> On Tue, Aug 13, 2019 at 2:21 PM Dushan Silva  wrote:
>>>
>>>> Hi,
>>>> I also think since this is a major release it is a good time to move
>>>> 3.0.0 however if we think from users perspective we should consider the
>>>> however not supporting 2.0 would effect. If we are planning on supporting a
>>>> conversion between 2.0 to 3.0 then definitely +1 for this.
>>>>
>>>> Thanks
>>>>
>>>> On Mon, Aug 12, 2019 at 12:08 PM Malintha Amarasinghe <
>>>> malint...@wso2.com> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Mon, Aug 12, 2019 at 11:21 AM Rukshan Premathunga 
>>>>> wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> On Mon, Aug 12, 2019 at 11:16 AM Thilini Shanika 
>>>>>> wrote:
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Mon, Aug 12, 2019 at 10:53 AM Rukshan Premathunga <
>>>>>>> ruks...@wso2.com> wrote:
>>>>>>>
>>>>>>>> Hi All,
>>>>>>>>
>>>>>>>> ATM generated API definition is in swagger 2. Can we make it OAS 3
>>>>>>>> for the new APIs?
>>>>>>>>
>>>>>>> Yes, we can change the default version of a newly created API to OAS
>>>>>>> 3.0.0. However, the API creator is allowed to pick the OAS version(OAS 
>>>>>>> 2 or
>>>>>>> 3) of the API during API creation time. Are you suggesting to remove the
>>>>>>> default support for OAS 2.0(For newly designed APIs)?
>>>>>>>
>>>>>> Yes, my suggestion is, if a user doesn't have an OAS definition,
>>>>>> generate an OAS 3 definition for them. If they have an OAS definition,
>>>>>> allowing them to import OAS 2 or 3 definition. So we will maintain the 
>>>>>> same
>>>>>> OAS version afterward.
>>>>>>
>>>>>
>>>>> I also think this would be okay. If anyone wants to stick with OAS
>>>>> 2.0, they have an import OAS 2.0 option.
>>>>> Maintaining two different API designers at UI level would not be good
>>>>> in terms of maintenance. We would one day anyway have to move to the
>>>>> designer to 3.0.0 as we did for 1.2 -> 2.0 in the past. Since this is a
>>>>> major release, this is a good time to do it as Pubudu said. @Rukshan
>>>>> Premathunga ,  if we move to 3.0.0, can we
>>>>> completely remove the UI designer code used for 2.0 and keep only 3.0.0
>>>>> related code?
>>>>>
>>>> We need to keep both v2 a

Re: [Architecture] [Dev] [Intern Project] Integrating API gateway with AWS Lambda

[Rajith Roshan]

ith the suggested UI.
>>>>>>
>>>>>> As we discussed in the design review, following widget will be added
>>>>>> to ENDPOINTS section.
>>>>>>
>>>>>> [image: image.png]
>>>>>> But I have some UX issues adding this kind of widget to ENDPOINTS
>>>>>> page in APIM 3.0.
>>>>>>
>>>>>> 1. A typical user will confuse by seeing resources in ENDPOINTS
>>>>>> section.
>>>>>> 2. What will happen to RESOURCES section (whether it has to be
>>>>>> disabled after he selected the endpoint type as AWS Lambda)?
>>>>>> 3. What if the user adds resources first and then goes to ENDPOINTS
>>>>>> section to set AWS LAMBDA?
>>>>>>
>>>>>> To outcome these problems one can suggest to add AWS user role
>>>>>> details (access key & secret key) in ENDPOINTS section and map resources 
>>>>>> to
>>>>>> ARNs in RESOURCES section which raise following issues.
>>>>>>
>>>>>> 1. User has to first selects the endpoint type as AWS LAMBDA before
>>>>>> set the resources.
>>>>>> 2. Have to add optional interface for mapping ARNs in RESOURCES
>>>>>> section.
>>>>>>
>>>>>> I'm suggesting to add separate section for LAMBDA configuration which
>>>>>> will disable ENDPOINTS and RESOURCES sections when an user enables LAMBDA
>>>>>> functions.
>>>>>>
>>>>>> [image: image.png]
>>>>>> What will be the best way to add this feature in APIM-Publisher?
>>>>>>
>>>>>>
>>>>>> On Tue, Aug 6, 2019 at 5:52 PM Binod Karunanayake 
>>>>>> wrote:
>>>>>>
>>>>>>> Hi all,
>>>>>>>
>>>>>>> I'm doing the above project which is a new feature in WSO2 API-M to
>>>>>>> invoke AWS Lambda functions through WSO2 API gateway. You can find the
>>>>>>> detailed document attached below.
>>>>>>>
>>>>>>> There will be no backend endpoints for APIs. Instead, an API invokes
>>>>>>> Lambda functions as shown below.
>>>>>>> [image: 1*ucaFQnPaYgniRfOHbBpgwA.png]
>>>>>>> Calling Lambda is done by a class mediator. However, Lambda response
>>>>>>> is a *byteBuffer* which have to be set to the *messageContext*. I'm
>>>>>>> looking for a solution to set the Lambda response to messageContext 
>>>>>>> without
>>>>>>> converting it to *String*.
>>>>>>>
>>>>>>> Best Regards.
>>>>>>>
>>>>>>> --
>>>>>>> *Binod Karunanayake* | Software Engineering Intern | WSO2 Inc.
>>>>>>> (m) +94716611642 | (e) bi...@wso2.com
>>>>>>> [image: http://wso2.com/signature] <http://wso2.com/signature>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> *Binod Karunanayake* | Software Engineering Intern | WSO2 Inc.
>>>>>> (m) +94716611642 | (e) bi...@wso2.com
>>>>>> [image: http://wso2.com/signature] <http://wso2.com/signature>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> *Chanaka Jayasena* | Technical Lead | WSO2 Inc.
>>>>> (m) +94 77 44 64 00 6 | (w) 0112 145 345 | (e) chan...@wso2.com
>>>>> GET INTEGRATION AGILE
>>>>> Integration Agility for Digitally Driven Business
>>>>>
>>>>
>>>>
>>>> --
>>>> *Chanaka Jayasena* | Technical Lead | WSO2 Inc.
>>>> (m) +94 77 44 64 00 6 | (w) 0112 145 345 | (e) chan...@wso2.com
>>>> GET INTEGRATION AGILE
>>>> Integration Agility for Digitally Driven Business
>>>> ___
>>>> Architecture mailing list
>>>> Architecture@wso2.org
>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>>
>>>
>>>
>>> --
>>> Himasha Guruge
>>> Associate Lead Solutions Engineer
>>> WS*O2* *Inc.*
>>> Mobile: +94 777459299
>>> himas...@wso2.com
>>> <http://wso2.com/signature>
>>> ___
>>> Dev mailing list
>>> d...@wso2.org
>>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>>
>>
>>
>> --
>> Best Regards
>> Dushan Silva
>> Software Engineer
>>
>> *WSO2, Inc. *
>>
>> lean . enterprise . middleware
>> Mob: +94 774 979042
>>
>
>
> --
> *Binod Karunanayake* | Software Engineering Intern | WSO2 Inc.
> (m) +94716611642 | (e) bi...@wso2.com
> [image: http://wso2.com/signature] <http://wso2.com/signature>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>


-- 
*Rajith Roshan* | Associate Technical Lead | WSO2 Inc.
(m) +94-717-064-214 |  (e) raji...@wso2.com 

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

Re: [Architecture] Revamping validator filter in API Microgateway

[Rajith Roshan]

I think using a common library would make both synapse and micro gateways
behaves the same way when validating the schemas. Maintaining our own
library would become difficult as open API spec add more and more
validations(with newer versions) , we will have to keep track of it and
include those into the feature. Using a library(under continuous
development), would make this easier as we only have to update the library
version.

Thanks!
Rajith

On Thu, Oct 3, 2019 at 7:21 PM Hasunie Adikari  wrote:

> Hi All,
>
> I have been working on JBallerina upgrade for the schema validator filter
> which validates the request/response payloads against the schema in the
> swagger file. Significant changes have been introduced with the b7 release
> and thus we need to revamp the feature accordingly. This is an arduous task
> provided that the validation logic has been implemented by ourselves and
> not using a third-party library. The validation logic in a sense, it
> includes a blend of tasks as below.
>
> 1. Primitive type validation
>
> 2. Custom type validation
>
> 3. Minimum, Maximum length of the integer and query parameters
>
> 4. Required field validation
>
> 5. Consider (allOf, anyOf ,oneOf) and use with a discriminator
>
> Besides the above, the feature should be compatible with both swagger
> versions 2 and 3. There are some drawbacks with the current implementation
> such as,
>
>1.
>
>Complexity - We have to put unnecessary effort to do generic JSON
>schema validations on our side.
>2.
>
>Maintainability - We can get future improvements from the library
>instead of writing ourselves.
>
> Hence, I would like to propose to use the third party library everit [1]
> which is similar to the synapse gateway and It provides the same
> capabilities extensively. If we go ahead with this approach, we just need
> to provide the payload and relevant schema model to the validate function
> of the library. WDYT?
>
> [1] https://github.com/everit-org/json-schema
>
> Regards,
> Hasunie
>
>
>
> --
> *Hasunie Adikari*
> Associate Technical Lead
> WSO2 Inc.; http://wso2.com
> lean.enterprise.middleware
> blog http://hasuniea.blogspot.com | https://medium.com/@Hasunie/
> Mobile:+94713095876
>
>

-- 
*Rajith Roshan* | Associate Technical Lead | WSO2 Inc.
(m) +94-717-064-214 |  (e) raji...@wso2.com 

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

Re: [Architecture] [Intern Project] Management Dashboard for MIcrogateways

[Rajith Roshan]

ortal keeps the connection to the other endpoint (micro
>>>gateway) constantly active, so get the new information instantly.
>>>
>>>
>>> Cons :
>>>
>>>-
>>>
>>>Sometimes the data will arrive at an unwanted time when the admin
>>>portal is not ready for it. However this can be remedied by using a
>>>dependency constraint.
>>>
>>>
>>> Option 1:
>>> We can store the data that we receive from the mocrogateways in a
>>> database and then push those data to be displayed in the Management
>>> Dashboard.
>>>
>>> Option 2:
>>>
>>> Otherwise we can keep those data in memory and then push those to
>>> be displayed in the management dashboard.
>>>
>>>
>>> Solution
>>>
>>> We can implement a User Interface(dashboard) in the APIM Admin portal to
>>> monitor the micro gateways and push or pull (REST API) mechanism support of
>>> notifying in Micro gateway side. When considering the push and pull method,
>>> it will be efficient to use the Push method for this due to the above
>>> mentioned pros and cons. In the dashboard it will be useful to display some
>>> of the following features.
>>>
>>>
>>>-
>>>
>>>Currently up and running microservices
>>>
>>>
>>>
>>>-
>>>
>>>Status of the microservices (up or down)
>>>
>>>
>>>
>>>-
>>>
>>>The uptime of the exposed micro services
>>>
>>>
>>>
>>>-
>>>
>>> Request Counter (No.of requests served , No.of failed requests,
>>>No.of successful requests)
>>>
>>>
>>>
>>>-
>>>
>>>Request Failure rate
>>>
>>>
>>>
>>>-
>>>
>>>No.of requests per second(Throughput)
>>>
>>>
>>>
>>> Rough sketch of a dashboard
>>>
>>> [image: dasboard.png]
>>> I have created a  swagger specification for this. Please find it
>>> attached below. And highly appreciate your thoughts on this $subject.
>>>
>>> Thanks!
>>>
>>>
>>> --
>>> *Kavindi Gunasinghe* | Intern - Engineering | WSO2 Inc.
>>> <http://wso2.com/>
>>> (M)+94 773058210 | (E) kavi...@wso2.com 
>>> <https://wso2.com/signature>
>>>
>>>
>>>
>>>
>>
>> --
>> *Amila De Silva*
>> Software Architect | Associate Director, Engineering - WSO2 Inc.
>> (m) +94 775119302 | (e) ami...@wso2.com
>> <http://wso2.com/signature>
>> ___
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>
>
> --
> *Pubudu Gunatilaka* | Technical Lead | WSO2 Inc.
> (m) +94774078049 | (w) +94112145345 | (e) pubu...@wso2.com
> <http://wso2.com/signature>
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>


-- 
*Rajith Roshan* | Associate Technical Lead | WSO2 Inc.
(m) +94-717-064-214 |  (e) raji...@wso2.com 
blog: http://www.rajithr.com

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

Re: [Architecture] [DEV] [VOTE] Release WSO2 API Microgateway 3.1.0 RC1

[Rajith Roshan]

Hi all,
Tested the following scenarios.


   - Test open APi without wso2 specific extensions
   - Tested Oauth2 with APIM 3.1.0-RC3
   - Tested oauth2 scopes authentications
   - Tested Basic authentication + scopes
   - Tested the quick start guide on docker.


No issues found
*[+] Stable - Go ahead and release*

Thanks!
Rajith



On Sat, Mar 21, 2020 at 3:20 AM Praminda Jayawardana 
wrote:

> Hi All,
>
> WSO2 Api Manager team is pleased to announce the first release candidate
> of WSO2 API Microgateway 3.1.0.
>
> The WSO2 API Microgateway is a lightweight, gateway distribution which can
> be used to expose single or multiple APIs.
>
> Please find the improvements and fixes related to this release in Fixed
> issues
> <https://github.com/wso2/product-microgateway/issues?q=is%3Aissue+project%3Awso2%2Fproduct-microgateway%2F3+-label%3AType%2FDocs+-label%3AType%2FTask+-label%3AType%2FQuestion+-label%3AType%2FSpam>
>
> Download the product from here
> <https://github.com/wso2/product-microgateway/releases/tag/v3.1.0-rc1>
>
> The Tag to be voted upon is
> https://github.com/wso2/product-microgateway/tree/v3.1.0-rc1
>
>
> Documentation: https://docs.wso2.com/display/MG310/
>
> Please download, test the product and vote.
>
>
> *[+] Stable - Go ahead and release*
>
> *[-] Broken - Do not release *(explain why)
>
> Best Regards,
> WSO2 API Manager Team
>


-- 
*Rajith Roshan* | Associate Technical Lead | WSO2 Inc.
(m) +94-717-064-214 |  (e) raji...@wso2.com 
blog: http://www.rajithr.com

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

Re: [Architecture] [Dev] [Vote] Release of WSO2 API Microgateway 3.1.0 RC2

[Rajith Roshan]

Hi all,
Tested the following scenarios.

   - Tested Oauth2 with APIM 3.1.0-RC3
   - Tested oauth2 scopes authentications
   - Tested templating the basePath with Oauth2
   - Tested following scenarios in k8s

   - Jwt authentication
   - Multiple JWT issuers with auth0
   - Analytics file rotation task

No issues found.
*[+] Stable - Go ahead and release*

On Tue, Mar 24, 2020 at 11:43 PM Praminda Jayawardana 
wrote:

> Hi All,
>
> WSO2 Api Manager team is pleased to announce the second release candidate
> of WSO2 API Microgateway 3.1.0.
>
> The WSO2 API Microgateway is a lightweight, gateway distribution which can
> be used to expose single or multiple APIs.
>
> Please find the improvements and fixes related to this release in Fixed
> issues
> <https://github.com/wso2/product-microgateway/issues?q=is%3Aissue+project%3Awso2%2Fproduct-microgateway%2F3+-label%3AType%2FDocs+-label%3AType%2FTask+-label%3AType%2FQuestion+-label%3AType%2FSpam>
>
> Download the product from here
> <https://github.com/wso2/product-microgateway/releases/tag/v3.1.0-rc2>
>
> The Tag to be voted upon is
> https://github.com/wso2/product-microgateway/tree/v3.1.0-rc2
>
>
> Documentation: https://docs.wso2.com/display/MG310/
>
> Please download, test the product and vote.
>
>
> *[+] Stable - Go ahead and release*
>
> *[-] Broken - Do not release *(explain why)
>
> Best Regards,
> WSO2 API Manager Team
>


-- 
*Rajith Roshan* | Associate Technical Lead | WSO2 Inc.
(m) +94-717-064-214 |  (e) raji...@wso2.com 
blog: http://www.rajithr.com

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

Re: [Architecture] [DEV] [VOTE] Release WSO2 API Manager Tooling v3.1.0 RC3

[Rajith Roshan]

Hi all,
Tested apictl for the integration of microgateway and APIM. Tested
following scenario
1. Create microgateway swagger and import to APIM using apictl and invoke
using oauth2 tokens
2. Added scopes and scope bindings and check for scope validation with MGW
and gateway by importing MGW swagger to APIM

No blockers found

*[+] Stable - Go ahead and release*

On Thu, Apr 2, 2020 at 7:30 PM Naduni Pamudika  wrote:

> Hi All,
>
> WSO2 Api Manager team is pleased to announce the third release candidate
> of WSO2 API Manager Tooling 3.1.0 version.
>
> The WSO2 API Manager tooling provides the capability to import and export
> APIs and Applications across multiple environments seamlessly. Hence it
> provides greater flexibility to create CI/CD pipelines for APIs and
> applications.
>
> Apart from migrating APIs and applications, it supports Kubernetes API
> operator to deploy and manage APIs in the Kubernetes cluster by reducing
> additional overheads for the DevOps.
>
> Please find the improvements and fixes related to this release in Fixed
> Issues
> <https://github.com/wso2/product-apim-tooling/issues?q=is%3Aissue+is%3Aclosed+label%3A3.1.0>
> .
>
> Download the API Manager Tooling Distribution from here
> <https://github.com/wso2/product-apim-tooling/releases/tag/v3.1.0-rc3>.
>
> The tag to be voted upon is
> https://github.com/wso2/product-apim-tooling/releases/tag/v3.1.0-rc3
>
> Documentation:
> https://apim.docs.wso2.com/en/next/learn/api-controller/getting-started-with-wso2-api-controller/
>
> Please download, test the tool and vote.
>
>
> *[+] Stable - Go ahead and release*
>
> *[-] Broken - Do not release *(explain why)
>
>
>
> Best Regards,
> WSO2 API Manager Team
>
> --
> *Naduni Pamudika* | Senior Software Engineer | WSO2 Inc.
> (m) +94 (71) 9143658 | (w) +94 (11) 2145345 | (e) nad...@wso2.com
> [image: http://wso2.com/signature] <http://wso2.com/signature>
>
>

-- 
*Rajith Roshan* | Associate Technical Lead | WSO2 Inc.
(m) +94-717-064-214 |  (e) raji...@wso2.com 
blog: http://www.rajithr.com

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

Re: [Architecture] [Dev] [DEV] [VOTE] Release WSO2 API Manager Tooling v3.1.0 RC4

[Rajith Roshan]

Hi all,
Tested the basic scenarios with microgateway.

No blockers found

*[+] Stable - Go ahead and release*

On Sun, Apr 5, 2020 at 5:02 PM Chashika Weerathunga 
wrote:

> Hi all,
>
> Tested the following scenarios.
>
>- Followed the getting started guide.
>- Tested apictl for the integration of Microgateway and APIM
>   - Create Microgateway swaggers(with different versions) and
>   import it to APIM using apictl and invoke it using JWT and Opaque 
> tokens.
>
> No blockers found
>
> *[+] Stable - Go ahead and release*
>
> On Fri, Apr 3, 2020 at 2:16 PM Naduni Pamudika  wrote:
>
>> Hi All,
>>
>> WSO2 Api Manager team is pleased to announce the fourth release candidate
>> of WSO2 API Manager Tooling 3.1.0 version.
>>
>> The WSO2 API Manager tooling provides the capability to import and export
>> APIs and Applications across multiple environments seamlessly. Hence it
>> provides greater flexibility to create CI/CD pipelines for APIs and
>> applications.
>>
>> Apart from migrating APIs and applications, it supports Kubernetes API
>> operator to deploy and manage APIs in the Kubernetes cluster by reducing
>> additional overheads for the DevOps.
>>
>> Please find the improvements and fixes related to this release in Fixed
>> Issues
>> <https://github.com/wso2/product-apim-tooling/issues?q=is%3Aissue+is%3Aclosed+label%3A3.1.0>
>> .
>>
>> Download the API Manager Tooling Distribution from here
>> <https://github.com/wso2/product-apim-tooling/releases/tag/v3.1.0-rc4>.
>>
>> The tag to be voted upon is
>> https://github.com/wso2/product-apim-tooling/releases/tag/v3.1.0-rc4
>>
>> Documentation:
>> https://apim.docs.wso2.com/en/next/learn/api-controller/getting-started-with-wso2-api-controller/
>>
>> Please download, test the tool and vote.
>>
>>
>> *[+] Stable - Go ahead and release*
>>
>> *[-] Broken - Do not release *(explain why)
>>
>>
>>
>> Best Regards,
>> WSO2 API Manager Team
>>
>> --
>> *Naduni Pamudika* | Senior Software Engineer | WSO2 Inc.
>> (m) +94 (71) 9143658 | (w) +94 (11) 2145345 | (e) nad...@wso2.com
>> [image: http://wso2.com/signature] <http://wso2.com/signature>
>>
>>
>
> --
> *Chashika Weerathunga* | Software Engineer | WSO2 Inc.
> (m) +94713731206 | Email: chash...@wso2.com
> [image: http://wso2.com]
> <http://wso2.com>
> ___
> Dev mailing list
> d...@wso2.org
> http://wso2.org/cgi-bin/mailman/listinfo/dev
>


-- 
*Rajith Roshan* | Associate Technical Lead | WSO2 Inc.
(m) +94-717-064-214 |  (e) raji...@wso2.com 
blog: http://www.rajithr.com

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

[Architecture] WSO2 API Microgateway 3.2.0-Alpha Released!

[Rajith Roshan]

The WSO2 API Manager team is pleased to announce the release of API
Microgateway version 3.2.0-Alpha.
It's now available to download.Download
wso2am-micro-gw-3.2.0-alpha
<https://github.com/wso2/product-microgateway/releases/tag/v3.2.0-alpha>

Bug Fixes and Improvements in 3.2.0-Alpha

Fixed Issues
<https://github.com/wso2/product-microgateway/issues?q=is%3Aissue+is%3Aclosed+milestone%3A3.2.0-alpha>
Known Issues

Open Issues
<https://github.com/wso2/product-microgateway/issues?q=is%3Aopen+is%3Aissue>
Try it

https://mg.docs.wso2.com/en/latest/getting-started/quick-start-guide/quick-start-guide-overview/
Documentation

https://mg.docs.wso2.com/
How You Can Contribute

   -

   *Reporting Issues*
   We encourage you to report issues, documentation faults, and feature
   requests regarding WSO2 API Microgateway through the Github Issues
   <https://github.com/wso2/product-microgateway/issues>.
   -

   *Contributing Code*
   Read through project Contribution Guidelines
   <https://github.com/wso2/product-microgateway/blob/master/CONTRIBUTING.md>
to
   learn how to contribute with code.
   -

   *Mailing Lists*
   Join our mailing list and receive updates on product development.
   Developer List: d...@wso2.org
   -

   *User Forum*
   Go through the StackOverflow
   <https://stackoverflow.com/questions/tagged/wso2-mgw>
   -

   *Slack channels*
   Join us via our wso2-apim.slack.com for even better communication. You
   can talk to our developers directly regarding any issues, concerns about
   the product. We encourage you to start discussions or join any ongoing
   discussions with the team, via our slack channels.
 - Discussions about developments: Dev Channel
   <https://wso2-apim.slack.com/messages/microgateway>
 - New releases: Release Announcement Channel
   <https://wso2-apim.slack.com/messages/announcements>

*--WSO2 API Manager Team--*

-- 
*Rajith Roshan* | Associate Technical Lead | WSO2 Inc.
(m) +94-717-064-214 |  (e) raji...@wso2.com 
blog: http://www.rajithr.com

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

Re: [Architecture] [Dev][Vote] Release of WSO2 API Microgateway 3.2.0 RC2

[Rajith Roshan]

Hi all ,
Tested following scenarios:

   - Test jwt flow without subscription validation
   - Test subscription validation with pilot configurations to connect with
   APIM
   - Use apictl to import the API to API Manager and invoke using both
   microgateway and synapse gateway
   - Test api with multiple scopes.
   - Test apictl default version is enabled when x-wso2-basePath only
   presents in the open API.

No blockers found.

*[+] Stable* - Go ahead and release



On Sat, Aug 22, 2020 at 4:10 PM Menaka Jayawardena  wrote:

> Hi All,
>
> WSO2 Api Manager team is pleased to announce the second release candidate
> of WSO2 API Microgateway 3.2.0.
>
> The WSO2 API Microgateway is a lightweight, gateway distribution which can
> be used to expose single or multiple APIs.
>
> Please find the improvements and fixes related to this release in Fixed
> issues
> <https://github.com/wso2/product-microgateway/issues?q=is%3Aissue+project%3Awso2%2Fproduct-microgateway%2F9+is%3Aclosed+label%3AType%2FBug+>
>
> Download the product from here
> <https://github.com/wso2/product-microgateway/releases/tag/v3.2.0-rc2>
>
> The Tag to be voted upon is
> https://github.com/wso2/product-microgateway/tree/v3.2.0-rc2
>
> *Documentation*: https://mg.docs.wso2.com/en/latest/
>
> Please download, test the product and vote.
>
> *[+] Stable* - Go ahead and release
>
> *[-] Broken* - Do not release (explain why)
>
>
> Best Regards,
> WSO2 API Manager Team
>
>
> --
> *Menaka Jayawardena*
> Senior Software Engineer *|* *WSO2* *Inc*.
> +94 71 350 5470 | men...@wso2.com
>
> <https://wso2.com/signature>
>
>

-- 
*Rajith Roshan* | Associate Technical Lead | WSO2 Inc.
(m) +94-717-064-214 |  (e) raji...@wso2.com 
blog: http://www.rajithr.com

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

Re: [Architecture] [APIM] - Event Based API Deployment architecture.

[Rajith Roshan]

ht into
>>>> onprem. So those who use all in one pack or having simple deployments won't
>>>> notice any complexity. Thoughts?
>>>>
>>>> Thanks,
>>>> sanjeewa.
>>>>
>>>>
>>>>
>>>>
>>>> On Thu, Nov 19, 2020 at 3:25 PM Tharindu Dharmarathna <
>>>> tharin...@wso2.com> wrote:
>>>>
>>>>> Hi All,
>>>>>
>>>>> Currently, WSO2 API Manager has the following two methods of deploying
>>>>> artifacts into the Gateway deployments.
>>>>>
>>>>>1. Push API artifacts into Gateway nodes.
>>>>>2. Pull Gateway Artifacts from Traffic Manager nodes based on the
>>>>>event.
>>>>>
>>>>> from the next APIM release, we will be going to remove the [1] option
>>>>> and we going to make [2] the way of deploying APIS.
>>>>>
>>>>> *Problems come in [2] architecture implemented.*
>>>>> 1. Introducing a new Gateway Type (Envoy Micro Gateway, etc) couldn't
>>>>> use existing event-based architecture since it handles only the synapse
>>>>> artifacts at the publisher end.
>>>>>
>>>>> *Solution*
>>>>> The following model going to be implemented based on the above points
>>>>> as discussed.
>>>>>
>>>>> [image: deployment.png]
>>>>> Your feedback on the above implementation is highly appreciated.
>>>>>
>>>>> Thanks
>>>>>
>>>>> *Tharindu Dharmarathna*Technical Lead
>>>>> WSO2 Inc.; http://wso2.com
>>>>> lean.enterprise.middleware
>>>>>
>>>>> mobile: *+94779109091*
>>>>>
>>>>
>>>>
>>>> --
>>>> *Sanjeewa Malalgoda*
>>>> Software Architect | Associate Director, Engineering - WSO2 Inc.
>>>> (m) +94 712933253 | (e) sanje...@wso2.com | (b) Blogger
>>>> <http://sanjeewamalalgoda.blogspot.com>, Medium
>>>> <https://medium.com/@sanjeewa190>
>>>>
>>>> GET INTEGRATION AGILE <https://wso2.com/signature>
>>>> Integration Agility for Digitally Driven Business
>>>> ___
>>>> Architecture mailing list
>>>> Architecture@wso2.org
>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>>
>>>
>>
>> Thanks
>>
>> *Tharindu Dharmarathna*Technical Lead
>> WSO2 Inc.; http://wso2.com
>> lean.enterprise.middleware
>>
>> mobile: *+94779109091*
>>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>


-- 
*Rajith Roshan* | Technical Lead | WSO2 Inc.
(m) +94-717-064-214 |  (e) raji...@wso2.com 
blog: http://www.rajithr.com

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