[Architechture] [APIM] Label based Store nodes for API Manager

classic Classic list List threaded Threaded
20 messages Options
Reply | Threaded
Open this post in threaded view
|

[Architechture] [APIM] Label based Store nodes for API Manager

Praminda Jayawardana
Hi All,

We've planned to introduce store labeling feature for API Manager 3.0.0. With this feature different business units inside an organizations will be able to publish their APIs in separate API Stores.

Ex:
Separate API Stores for Infra and Sales APIs.

Current plan is to utilize the same design as gateway label implementation with small set of changes. Therefore a Publisher of an API can select the Store label(s) he/she needs to publish the API and a Store node should be started with this specific label.
We are hoping to add following changes to current label implementation.

1. Add new column for label type: AM_LABELS
We can utilize the same label table used for storing gateway labels by introducing a new TYPE column to existing AM_LABELS table

==========================
LABEL_ID |  NAME   |  TYPE_ID
==========================
                 |               |

2. Add Label type table: AM_LABEL_TYPE
Table used to store label types. Currently only gateway and store labels

=====================
TYPE_ID |  TYPE_NAME
=====================
1              |  GATEWAY
2              |  STORE

3. Add API-Label mapping table: AM_API_STORE_LABEL_MAPPING
New table is introduced to keep the mapping between an API and Labels

================
API_ID |  LABEL_ID
================
            |

Please let us know what do you think of the approach we have suggested.

Thanks,
Praminda

--

Praminda Jayawardana

Software Engineer
WSO2 Inc.; http://wso2.com
Mobile : <a href="tel:+94%2071%20659%200918" value="+94716590918" target="_blank">+94 (0) 716 590918

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Reply | Threaded
Open this post in threaded view
|

Re: [Architechture] [APIM] Label based Store nodes for API Manager

Bhathiya Jayasekara
Hi Praminda,

When we say a "store node", does that mean an APIM Core node, or a node with some kind of a profile with only store services?  

Thanks,
Bhathiya

On Mon, Jun 19, 2017 at 10:08 PM, Praminda Jayawardana <[hidden email]> wrote:
Hi All,

We've planned to introduce store labeling feature for API Manager 3.0.0. With this feature different business units inside an organizations will be able to publish their APIs in separate API Stores.

Ex:
Separate API Stores for Infra and Sales APIs.

Current plan is to utilize the same design as gateway label implementation with small set of changes. Therefore a Publisher of an API can select the Store label(s) he/she needs to publish the API and a Store node should be started with this specific label.
We are hoping to add following changes to current label implementation.

1. Add new column for label type: AM_LABELS
We can utilize the same label table used for storing gateway labels by introducing a new TYPE column to existing AM_LABELS table

==========================
LABEL_ID |  NAME   |  TYPE_ID
==========================
                 |               |

2. Add Label type table: AM_LABEL_TYPE
Table used to store label types. Currently only gateway and store labels

=====================
TYPE_ID |  TYPE_NAME
=====================
1              |  GATEWAY
2              |  STORE

3. Add API-Label mapping table: AM_API_STORE_LABEL_MAPPING
New table is introduced to keep the mapping between an API and Labels

================
API_ID |  LABEL_ID
================
            |

Please let us know what do you think of the approach we have suggested.

Thanks,
Praminda

--

Praminda Jayawardana

Software Engineer
WSO2 Inc.; http://wso2.com
Mobile : <a href="tel:+94%2071%20659%200918" value="+94716590918" target="_blank">+94 (0) 716 590918



--
Bhathiya Jayasekara
Associate Technical Lead,
WSO2 inc., http://wso2.com

Phone: +94715478185

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Reply | Threaded
Open this post in threaded view
|

Re: [Architechture] [APIM] Label based Store nodes for API Manager

lakmal Warusawithana
There are some use-cases for have multiple stores. yes it is store profile  (store REST API+ Store SPA + and Impel)

On Mon, Jun 19, 2017 at 10:25 PM, Bhathiya Jayasekara <[hidden email]> wrote:
Hi Praminda,

When we say a "store node", does that mean an APIM Core node, or a node with some kind of a profile with only store services?  

Thanks,
Bhathiya

On Mon, Jun 19, 2017 at 10:08 PM, Praminda Jayawardana <[hidden email]> wrote:
Hi All,

We've planned to introduce store labeling feature for API Manager 3.0.0. With this feature different business units inside an organizations will be able to publish their APIs in separate API Stores.

Ex:
Separate API Stores for Infra and Sales APIs.

Current plan is to utilize the same design as gateway label implementation with small set of changes. Therefore a Publisher of an API can select the Store label(s) he/she needs to publish the API and a Store node should be started with this specific label.
We are hoping to add following changes to current label implementation.

1. Add new column for label type: AM_LABELS
We can utilize the same label table used for storing gateway labels by introducing a new TYPE column to existing AM_LABELS table

==========================
LABEL_ID |  NAME   |  TYPE_ID
==========================
                 |               |

2. Add Label type table: AM_LABEL_TYPE
Table used to store label types. Currently only gateway and store labels

=====================
TYPE_ID |  TYPE_NAME
=====================
1              |  GATEWAY
2              |  STORE

3. Add API-Label mapping table: AM_API_STORE_LABEL_MAPPING
New table is introduced to keep the mapping between an API and Labels

================
API_ID |  LABEL_ID
================
            |

Please let us know what do you think of the approach we have suggested.

Thanks,
Praminda

--

Praminda Jayawardana

Software Engineer
WSO2 Inc.; http://wso2.com
Mobile : <a href="tel:+94%2071%20659%200918" value="+94716590918" target="_blank">+94 (0) 716 590918



--
Bhathiya Jayasekara
Associate Technical Lead,
WSO2 inc., http://wso2.com

Phone: <a href="tel:+94%2071%20547%208185" value="+94715478185" target="_blank">+94715478185

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Lakmal Warusawithana
Director - Cloud Architecture; WSO2 Inc.
Mobile : +94714289692


_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Reply | Threaded
Open this post in threaded view
|

Re: [Architechture] [APIM] Label based Store nodes for API Manager

Sajith Kariyawasam
Hi Praminda, 

On Mon, Jun 19, 2017 at 11:05 PM, Lakmal Warusawithana <[hidden email]> wrote:
There are some use-cases for have multiple stores. yes it is store profile  (store REST API+ Store SPA + and Impel)

On Mon, Jun 19, 2017 at 10:25 PM, Bhathiya Jayasekara <[hidden email]> wrote:
Hi Praminda,

When we say a "store node", does that mean an APIM Core node, or a node with some kind of a profile with only store services?  

Thanks,
Bhathiya

On Mon, Jun 19, 2017 at 10:08 PM, Praminda Jayawardana <[hidden email]> wrote:
Hi All,

We've planned to introduce store labeling feature for API Manager 3.0.0. With this feature different business units inside an organizations will be able to publish their APIs in separate API Stores.

Ex:
Separate API Stores for Infra and Sales APIs.

Current plan is to utilize the same design as gateway label implementation with small set of changes. Therefore a Publisher of an API can select the Store label(s) he/she needs to publish the API and a Store node should be started with this specific label.
We are hoping to add following changes to current label implementation.

1. Add new column for label type: AM_LABELS
We can utilize the same label table used for storing gateway labels by introducing a new TYPE column to existing AM_LABELS table

==========================
LABEL_ID |  NAME   |  TYPE_ID
==========================
                 |               |

2. Add Label type table: AM_LABEL_TYPE
Table used to store label types. Currently only gateway and store labels

=====================
TYPE_ID |  TYPE_NAME
=====================
1              |  GATEWAY
2              |  STORE


What is the benefit of this AM_LABEL_TYPE table? Can't we just store the Type Name values (GATEWAY, STORE. etc.. ) in the Type column of AM_LABELS?
 
3. Add API-Label mapping table: AM_API_STORE_LABEL_MAPPING
New table is introduced to keep the mapping between an API and Labels

================
API_ID |  LABEL_ID
================
            |

Please let us know what do you think of the approach we have suggested.

Thanks,
Praminda

--

Praminda Jayawardana

Software Engineer
WSO2 Inc.; http://wso2.com
Mobile : <a href="tel:+94%2071%20659%200918" value="+94716590918" target="_blank">+94 (0) 716 590918



--
Bhathiya Jayasekara
Associate Technical Lead,
WSO2 inc., http://wso2.com

Phone: <a href="tel:+94%2071%20547%208185" value="+94715478185" target="_blank">+94715478185

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Lakmal Warusawithana
Director - Cloud Architecture; WSO2 Inc.
Mobile : <a href="tel:+94%2071%20428%209692" value="+94714289692" target="_blank">+94714289692


_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Sajith Kariyawasam
Associate Tech Lead
WSO2 Inc.; http://wso2.com
Committer and PMC member, Apache Stratos 
AMIE (SL)
Mobile: 0772269575

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Reply | Threaded
Open this post in threaded view
|

Re: [Architechture] [APIM] Label based Store nodes for API Manager

Jochen Traunecker
Hi,

what about changing the meta-model a little bit and introduce another indirection : LABELSCOPE.  LABELS can be assigned to 1...n LABELSCOPES.

With this model, these use cases could get realised without confusing Publishers and avoiding redundancy in LABEL-Names (which should get avoided):

Use case : A Store and dedicated Gateway(s) for "Public APIs" - so everyone is free to sign up and subscribe
Use case: A B2B-Store with dedicated B2B-Gateways for "Business Customers" with invitation only
Use case: Internal API-Store and deployment to SECURE_ZONE_1 
Use case: internal API-Store and deployment to SECURE_ZONE_2

Publisher UI could filter labels based on LABELSCOPE and just render the ones needed for "Deployment to Gateway" selection UI element and "Visible in Store" selection UI component. Still the Label e.g. "PUBLIC" could be visible / assignable in both UI elements. 

With the options to define labels for Stores and Gateways there will be demand to govern and protect users from configuration mistakes. By that it would be just consequent to be able to specify, which label combinations are valid :-) I did not model this requirement. 

Furthermore there will be demand to define, which user/role is allowed, to assign specific labels. Only "public_publishers" are allowed to assign "public" label to APIs ...  

Ultimately, Labels could get used for "Publisher UIs". There are use cases, to expose a dedicated "Publisher UI" for internal APIs only, or a "Publisher UI" for some specific Business Unit X and so on. Such dedicated Publishers could limit / restrict the set of Labels assignable to APIs. 


LABEL
==============
LABEL_ID | NAME 
==============
1                | B2B
2                | PUBLIC
3                | INTERNAL
4                | SECURE_ZONE_1
5                | SECURE_ZONE_2

LABEL_API
===============
API_ID | LABEL_ID
===============

LABELSCOPE
================
LSCOPE_ID | NAME
================
1                   | GATEWAY
2                   | STORE


LABELSCOPE_LABEL
====================
LABEL_ID | LSCOPE_ID
====================
1               | 1
1               | 2
2               | 1
2               | 2   
3               | 2
4               | 1
5               | 1


Thanks,
Jochen

2017-06-19 21:43 GMT+02:00 Sajith Kariyawasam <[hidden email]>:
Hi Praminda, 

On Mon, Jun 19, 2017 at 11:05 PM, Lakmal Warusawithana <[hidden email]> wrote:
There are some use-cases for have multiple stores. yes it is store profile  (store REST API+ Store SPA + and Impel)

On Mon, Jun 19, 2017 at 10:25 PM, Bhathiya Jayasekara <[hidden email]> wrote:
Hi Praminda,

When we say a "store node", does that mean an APIM Core node, or a node with some kind of a profile with only store services?  

Thanks,
Bhathiya

On Mon, Jun 19, 2017 at 10:08 PM, Praminda Jayawardana <[hidden email]> wrote:
Hi All,

We've planned to introduce store labeling feature for API Manager 3.0.0. With this feature different business units inside an organizations will be able to publish their APIs in separate API Stores.

Ex:
Separate API Stores for Infra and Sales APIs.

Current plan is to utilize the same design as gateway label implementation with small set of changes. Therefore a Publisher of an API can select the Store label(s) he/she needs to publish the API and a Store node should be started with this specific label.
We are hoping to add following changes to current label implementation.

1. Add new column for label type: AM_LABELS
We can utilize the same label table used for storing gateway labels by introducing a new TYPE column to existing AM_LABELS table

==========================
LABEL_ID |  NAME   |  TYPE_ID
==========================
                 |               |

2. Add Label type table: AM_LABEL_TYPE
Table used to store label types. Currently only gateway and store labels

=====================
TYPE_ID |  TYPE_NAME
=====================
1              |  GATEWAY
2              |  STORE


What is the benefit of this AM_LABEL_TYPE table? Can't we just store the Type Name values (GATEWAY, STORE. etc.. ) in the Type column of AM_LABELS?
 
3. Add API-Label mapping table: AM_API_STORE_LABEL_MAPPING
New table is introduced to keep the mapping between an API and Labels

================
API_ID |  LABEL_ID
================
            |

Please let us know what do you think of the approach we have suggested.

Thanks,
Praminda

--

Praminda Jayawardana

Software Engineer
WSO2 Inc.; http://wso2.com
Mobile : <a href="tel:+94%2071%20659%200918" value="+94716590918" target="_blank">+94 (0) 716 590918



--
Bhathiya Jayasekara
Associate Technical Lead,
WSO2 inc., http://wso2.com

Phone: <a href="tel:+94%2071%20547%208185" value="+94715478185" target="_blank">+94715478185

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Lakmal Warusawithana
Director - Cloud Architecture; WSO2 Inc.
Mobile : <a href="tel:+94%2071%20428%209692" value="+94714289692" target="_blank">+94714289692


_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Sajith Kariyawasam
Associate Tech Lead
WSO2 Inc.; http://wso2.com
Committer and PMC member, Apache Stratos 
AMIE (SL)
Mobile: <a href="tel:07722%2069575" value="+49772269575" target="_blank">0772269575

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Gruss / regards

Jochen Traunecker
mailto: [hidden email]

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Reply | Threaded
Open this post in threaded view
|

Re: [Architechture] [APIM] Label based Store nodes for API Manager

lakmal Warusawithana
+1 Jochen, this is more cleaner and it is addressing governance aspect of the labels. 

On Tue, Jun 20, 2017 at 1:22 AM, Jochen Traunecker <[hidden email]> wrote:
Hi,

what about changing the meta-model a little bit and introduce another indirection : LABELSCOPE.  LABELS can be assigned to 1...n LABELSCOPES.

With this model, these use cases could get realised without confusing Publishers and avoiding redundancy in LABEL-Names (which should get avoided):

Use case : A Store and dedicated Gateway(s) for "Public APIs" - so everyone is free to sign up and subscribe
Use case: A B2B-Store with dedicated B2B-Gateways for "Business Customers" with invitation only
Use case: Internal API-Store and deployment to SECURE_ZONE_1 
Use case: internal API-Store and deployment to SECURE_ZONE_2

Publisher UI could filter labels based on LABELSCOPE and just render the ones needed for "Deployment to Gateway" selection UI element and "Visible in Store" selection UI component. Still the Label e.g. "PUBLIC" could be visible / assignable in both UI elements. 

With the options to define labels for Stores and Gateways there will be demand to govern and protect users from configuration mistakes. By that it would be just consequent to be able to specify, which label combinations are valid :-) I did not model this requirement. 

Furthermore there will be demand to define, which user/role is allowed, to assign specific labels. Only "public_publishers" are allowed to assign "public" label to APIs ...  

Ultimately, Labels could get used for "Publisher UIs". There are use cases, to expose a dedicated "Publisher UI" for internal APIs only, or a "Publisher UI" for some specific Business Unit X and so on. Such dedicated Publishers could limit / restrict the set of Labels assignable to APIs. 


LABEL
==============
LABEL_ID | NAME 
==============
1                | B2B
2                | PUBLIC
3                | INTERNAL
4                | SECURE_ZONE_1
5                | SECURE_ZONE_2

LABEL_API
===============
API_ID | LABEL_ID
===============

LABELSCOPE
================
LSCOPE_ID | NAME
================
1                   | GATEWAY
2                   | STORE


LABELSCOPE_LABEL
====================
LABEL_ID | LSCOPE_ID
====================
1               | 1
1               | 2
2               | 1
2               | 2   
3               | 2
4               | 1
5               | 1


Thanks,
Jochen

2017-06-19 21:43 GMT+02:00 Sajith Kariyawasam <[hidden email]>:
Hi Praminda, 

On Mon, Jun 19, 2017 at 11:05 PM, Lakmal Warusawithana <[hidden email]> wrote:
There are some use-cases for have multiple stores. yes it is store profile  (store REST API+ Store SPA + and Impel)

On Mon, Jun 19, 2017 at 10:25 PM, Bhathiya Jayasekara <[hidden email]> wrote:
Hi Praminda,

When we say a "store node", does that mean an APIM Core node, or a node with some kind of a profile with only store services?  

Thanks,
Bhathiya

On Mon, Jun 19, 2017 at 10:08 PM, Praminda Jayawardana <[hidden email]> wrote:
Hi All,

We've planned to introduce store labeling feature for API Manager 3.0.0. With this feature different business units inside an organizations will be able to publish their APIs in separate API Stores.

Ex:
Separate API Stores for Infra and Sales APIs.

Current plan is to utilize the same design as gateway label implementation with small set of changes. Therefore a Publisher of an API can select the Store label(s) he/she needs to publish the API and a Store node should be started with this specific label.
We are hoping to add following changes to current label implementation.

1. Add new column for label type: AM_LABELS
We can utilize the same label table used for storing gateway labels by introducing a new TYPE column to existing AM_LABELS table

==========================
LABEL_ID |  NAME   |  TYPE_ID
==========================
                 |               |

2. Add Label type table: AM_LABEL_TYPE
Table used to store label types. Currently only gateway and store labels

=====================
TYPE_ID |  TYPE_NAME
=====================
1              |  GATEWAY
2              |  STORE


What is the benefit of this AM_LABEL_TYPE table? Can't we just store the Type Name values (GATEWAY, STORE. etc.. ) in the Type column of AM_LABELS?
 
3. Add API-Label mapping table: AM_API_STORE_LABEL_MAPPING
New table is introduced to keep the mapping between an API and Labels

================
API_ID |  LABEL_ID
================
            |

Please let us know what do you think of the approach we have suggested.

Thanks,
Praminda

--

Praminda Jayawardana

Software Engineer
WSO2 Inc.; http://wso2.com
Mobile : <a href="tel:+94%2071%20659%200918" value="+94716590918" target="_blank">+94 (0) 716 590918



--
Bhathiya Jayasekara
Associate Technical Lead,
WSO2 inc., http://wso2.com

Phone: <a href="tel:+94%2071%20547%208185" value="+94715478185" target="_blank">+94715478185

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Lakmal Warusawithana
Director - Cloud Architecture; WSO2 Inc.
Mobile : <a href="tel:+94%2071%20428%209692" value="+94714289692" target="_blank">+94714289692


_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Sajith Kariyawasam
Associate Tech Lead
WSO2 Inc.; http://wso2.com
Committer and PMC member, Apache Stratos 
AMIE (SL)
Mobile: <a href="tel:07722%2069575" value="+49772269575" target="_blank">0772269575

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Gruss / regards

Jochen Traunecker
mailto: [hidden email]

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Lakmal Warusawithana
Director - Cloud Architecture; WSO2 Inc.
Mobile : +94714289692


_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Reply | Threaded
Open this post in threaded view
|

Re: [Architechture] [APIM] Label based Store nodes for API Manager

Harsha Kumara-2
Hi All,

Currently, we are adding labels through core API when gateway gets registered with the core. Since we don't have permissions for the gateway labels it allows publishers to select whatever gateway that they want to publish. Are we going to incorporate it with our permission model? This will also apply for the store labels as well. 

@praminda how are we plan to add labels before we going to attach them to the APIs?

Thanks,
Harsha

On Tue, Jun 20, 2017 at 1:47 PM, Lakmal Warusawithana <[hidden email]> wrote:
+1 Jochen, this is more cleaner and it is addressing governance aspect of the labels. 


On Tue, Jun 20, 2017 at 1:22 AM, Jochen Traunecker <[hidden email]> wrote:
Hi,

what about changing the meta-model a little bit and introduce another indirection : LABELSCOPE.  LABELS can be assigned to 1...n LABELSCOPES.

With this model, these use cases could get realised without confusing Publishers and avoiding redundancy in LABEL-Names (which should get avoided):

Use case : A Store and dedicated Gateway(s) for "Public APIs" - so everyone is free to sign up and subscribe
Use case: A B2B-Store with dedicated B2B-Gateways for "Business Customers" with invitation only
Use case: Internal API-Store and deployment to SECURE_ZONE_1 
Use case: internal API-Store and deployment to SECURE_ZONE_2

Publisher UI could filter labels based on LABELSCOPE and just render the ones needed for "Deployment to Gateway" selection UI element and "Visible in Store" selection UI component. Still the Label e.g. "PUBLIC" could be visible / assignable in both UI elements. 

With the options to define labels for Stores and Gateways there will be demand to govern and protect users from configuration mistakes. By that it would be just consequent to be able to specify, which label combinations are valid :-) I did not model this requirement. 

Furthermore there will be demand to define, which user/role is allowed, to assign specific labels. Only "public_publishers" are allowed to assign "public" label to APIs ...  

Ultimately, Labels could get used for "Publisher UIs". There are use cases, to expose a dedicated "Publisher UI" for internal APIs only, or a "Publisher UI" for some specific Business Unit X and so on. Such dedicated Publishers could limit / restrict the set of Labels assignable to APIs. 


LABEL
==============
LABEL_ID | NAME 
==============
1                | B2B
2                | PUBLIC
3                | INTERNAL
4                | SECURE_ZONE_1
5                | SECURE_ZONE_2

LABEL_API
===============
API_ID | LABEL_ID
===============

LABELSCOPE
================
LSCOPE_ID | NAME
================
1                   | GATEWAY
2                   | STORE


LABELSCOPE_LABEL
====================
LABEL_ID | LSCOPE_ID
====================
1               | 1
1               | 2
2               | 1
2               | 2   
3               | 2
4               | 1
5               | 1


Thanks,
Jochen

2017-06-19 21:43 GMT+02:00 Sajith Kariyawasam <[hidden email]>:
Hi Praminda, 

On Mon, Jun 19, 2017 at 11:05 PM, Lakmal Warusawithana <[hidden email]> wrote:
There are some use-cases for have multiple stores. yes it is store profile  (store REST API+ Store SPA + and Impel)

On Mon, Jun 19, 2017 at 10:25 PM, Bhathiya Jayasekara <[hidden email]> wrote:
Hi Praminda,

When we say a "store node", does that mean an APIM Core node, or a node with some kind of a profile with only store services?  

Thanks,
Bhathiya

On Mon, Jun 19, 2017 at 10:08 PM, Praminda Jayawardana <[hidden email]> wrote:
Hi All,

We've planned to introduce store labeling feature for API Manager 3.0.0. With this feature different business units inside an organizations will be able to publish their APIs in separate API Stores.

Ex:
Separate API Stores for Infra and Sales APIs.

Current plan is to utilize the same design as gateway label implementation with small set of changes. Therefore a Publisher of an API can select the Store label(s) he/she needs to publish the API and a Store node should be started with this specific label.
We are hoping to add following changes to current label implementation.

1. Add new column for label type: AM_LABELS
We can utilize the same label table used for storing gateway labels by introducing a new TYPE column to existing AM_LABELS table

==========================
LABEL_ID |  NAME   |  TYPE_ID
==========================
                 |               |

2. Add Label type table: AM_LABEL_TYPE
Table used to store label types. Currently only gateway and store labels

=====================
TYPE_ID |  TYPE_NAME
=====================
1              |  GATEWAY
2              |  STORE


What is the benefit of this AM_LABEL_TYPE table? Can't we just store the Type Name values (GATEWAY, STORE. etc.. ) in the Type column of AM_LABELS?
 
3. Add API-Label mapping table: AM_API_STORE_LABEL_MAPPING
New table is introduced to keep the mapping between an API and Labels

================
API_ID |  LABEL_ID
================
            |

Please let us know what do you think of the approach we have suggested.

Thanks,
Praminda

--

Praminda Jayawardana

Software Engineer
WSO2 Inc.; http://wso2.com
Mobile : <a href="tel:+94%2071%20659%200918" value="+94716590918" target="_blank">+94 (0) 716 590918



--
Bhathiya Jayasekara
Associate Technical Lead,
WSO2 inc., http://wso2.com

Phone: <a href="tel:+94%2071%20547%208185" value="+94715478185" target="_blank">+94715478185

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Lakmal Warusawithana
Director - Cloud Architecture; WSO2 Inc.
Mobile : <a href="tel:+94%2071%20428%209692" value="+94714289692" target="_blank">+94714289692


_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Sajith Kariyawasam
Associate Tech Lead
WSO2 Inc.; http://wso2.com
Committer and PMC member, Apache Stratos 
AMIE (SL)
Mobile: <a href="tel:07722%2069575" value="+49772269575" target="_blank">0772269575

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Gruss / regards

Jochen Traunecker
mailto: [hidden email]

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Lakmal Warusawithana
Director - Cloud Architecture; WSO2 Inc.
Mobile : <a href="tel:+94%2071%20428%209692" value="+94714289692" target="_blank">+94714289692


_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Harsha Kumara
Software Engineer, WSO2 Inc.
Mobile: +94775505618
Blog:harshcreationz.blogspot.com

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Reply | Threaded
Open this post in threaded view
|

Re: [Architechture] [APIM] Label based Store nodes for API Manager

lakmal Warusawithana
Since they are dynamic registrations, I don't think we have thought the permission model.

I am seen few complexity of allowing dynamic label registrations.  I have few questions.
  1. What are the benefits we are getting through the dynamic label registration?  
  2. Can we use admin API's to register labels?  without dynamic registration
    1. Its allow shipping few labels by default
    2. Easy to apply permissions

Shall we list out few points?

thanks


On Tue, Jun 20, 2017 at 7:43 PM, Harsha Kumara <[hidden email]> wrote:
Hi All,

Currently, we are adding labels through core API when gateway gets registered with the core. Since we don't have permissions for the gateway labels it allows publishers to select whatever gateway that they want to publish. Are we going to incorporate it with our permission model? This will also apply for the store labels as well. 

@praminda how are we plan to add labels before we going to attach them to the APIs?

Thanks,
Harsha

On Tue, Jun 20, 2017 at 1:47 PM, Lakmal Warusawithana <[hidden email]> wrote:
+1 Jochen, this is more cleaner and it is addressing governance aspect of the labels. 


On Tue, Jun 20, 2017 at 1:22 AM, Jochen Traunecker <[hidden email]> wrote:
Hi,

what about changing the meta-model a little bit and introduce another indirection : LABELSCOPE.  LABELS can be assigned to 1...n LABELSCOPES.

With this model, these use cases could get realised without confusing Publishers and avoiding redundancy in LABEL-Names (which should get avoided):

Use case : A Store and dedicated Gateway(s) for "Public APIs" - so everyone is free to sign up and subscribe
Use case: A B2B-Store with dedicated B2B-Gateways for "Business Customers" with invitation only
Use case: Internal API-Store and deployment to SECURE_ZONE_1 
Use case: internal API-Store and deployment to SECURE_ZONE_2

Publisher UI could filter labels based on LABELSCOPE and just render the ones needed for "Deployment to Gateway" selection UI element and "Visible in Store" selection UI component. Still the Label e.g. "PUBLIC" could be visible / assignable in both UI elements. 

With the options to define labels for Stores and Gateways there will be demand to govern and protect users from configuration mistakes. By that it would be just consequent to be able to specify, which label combinations are valid :-) I did not model this requirement. 

Furthermore there will be demand to define, which user/role is allowed, to assign specific labels. Only "public_publishers" are allowed to assign "public" label to APIs ...  

Ultimately, Labels could get used for "Publisher UIs". There are use cases, to expose a dedicated "Publisher UI" for internal APIs only, or a "Publisher UI" for some specific Business Unit X and so on. Such dedicated Publishers could limit / restrict the set of Labels assignable to APIs. 


LABEL
==============
LABEL_ID | NAME 
==============
1                | B2B
2                | PUBLIC
3                | INTERNAL
4                | SECURE_ZONE_1
5                | SECURE_ZONE_2

LABEL_API
===============
API_ID | LABEL_ID
===============

LABELSCOPE
================
LSCOPE_ID | NAME
================
1                   | GATEWAY
2                   | STORE


LABELSCOPE_LABEL
====================
LABEL_ID | LSCOPE_ID
====================
1               | 1
1               | 2
2               | 1
2               | 2   
3               | 2
4               | 1
5               | 1


Thanks,
Jochen

2017-06-19 21:43 GMT+02:00 Sajith Kariyawasam <[hidden email]>:
Hi Praminda, 

On Mon, Jun 19, 2017 at 11:05 PM, Lakmal Warusawithana <[hidden email]> wrote:
There are some use-cases for have multiple stores. yes it is store profile  (store REST API+ Store SPA + and Impel)

On Mon, Jun 19, 2017 at 10:25 PM, Bhathiya Jayasekara <[hidden email]> wrote:
Hi Praminda,

When we say a "store node", does that mean an APIM Core node, or a node with some kind of a profile with only store services?  

Thanks,
Bhathiya

On Mon, Jun 19, 2017 at 10:08 PM, Praminda Jayawardana <[hidden email]> wrote:
Hi All,

We've planned to introduce store labeling feature for API Manager 3.0.0. With this feature different business units inside an organizations will be able to publish their APIs in separate API Stores.

Ex:
Separate API Stores for Infra and Sales APIs.

Current plan is to utilize the same design as gateway label implementation with small set of changes. Therefore a Publisher of an API can select the Store label(s) he/she needs to publish the API and a Store node should be started with this specific label.
We are hoping to add following changes to current label implementation.

1. Add new column for label type: AM_LABELS
We can utilize the same label table used for storing gateway labels by introducing a new TYPE column to existing AM_LABELS table

==========================
LABEL_ID |  NAME   |  TYPE_ID
==========================
                 |               |

2. Add Label type table: AM_LABEL_TYPE
Table used to store label types. Currently only gateway and store labels

=====================
TYPE_ID |  TYPE_NAME
=====================
1              |  GATEWAY
2              |  STORE


What is the benefit of this AM_LABEL_TYPE table? Can't we just store the Type Name values (GATEWAY, STORE. etc.. ) in the Type column of AM_LABELS?
 
3. Add API-Label mapping table: AM_API_STORE_LABEL_MAPPING
New table is introduced to keep the mapping between an API and Labels

================
API_ID |  LABEL_ID
================
            |

Please let us know what do you think of the approach we have suggested.

Thanks,
Praminda

--

Praminda Jayawardana

Software Engineer
WSO2 Inc.; http://wso2.com
Mobile : <a href="tel:+94%2071%20659%200918" value="+94716590918" target="_blank">+94 (0) 716 590918



--
Bhathiya Jayasekara
Associate Technical Lead,
WSO2 inc., http://wso2.com

Phone: <a href="tel:+94%2071%20547%208185" value="+94715478185" target="_blank">+94715478185

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Lakmal Warusawithana
Director - Cloud Architecture; WSO2 Inc.
Mobile : <a href="tel:+94%2071%20428%209692" value="+94714289692" target="_blank">+94714289692


_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Sajith Kariyawasam
Associate Tech Lead
WSO2 Inc.; http://wso2.com
Committer and PMC member, Apache Stratos 
AMIE (SL)
Mobile: <a href="tel:07722%2069575" value="+49772269575" target="_blank">0772269575

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Gruss / regards

Jochen Traunecker
mailto: [hidden email]

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Lakmal Warusawithana
Director - Cloud Architecture; WSO2 Inc.
Mobile : <a href="tel:+94%2071%20428%209692" value="+94714289692" target="_blank">+94714289692


_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Harsha Kumara
Software Engineer, WSO2 Inc.
Mobile: <a href="tel:+94%2077%20550%205618" value="+94775505618" target="_blank">+94775505618
Blog:harshcreationz.blogspot.com

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Lakmal Warusawithana
Director - Cloud Architecture; WSO2 Inc.
Mobile : +94714289692


_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Reply | Threaded
Open this post in threaded view
|

Re: [Architechture] [APIM] Label based Store nodes for API Manager

Bhathiya Jayasekara
In reply to this post by Harsha Kumara-2
Hi all,

On Tue, Jun 20, 2017 at 7:43 PM, Harsha Kumara <[hidden email]> wrote:
Hi All,

Currently, we are adding labels through core API when gateway gets registered with the core. Since we don't have permissions for the gateway labels it allows publishers to select whatever gateway that they want to publish. Are we going to incorporate it with our permission model? This will also apply for the store labels as well. 

@praminda how are we plan to add labels before we going to attach them to the APIs?

Don't we need some place to manage these labels? If we forget about engaging the permission model for a moment, we may add labels when a store/gateway is started with a new label. But to remove such added labels, we may need some place to list them down. 

WDYT?

Thanks,
Bhathiya
 

Thanks,
Harsha

On Tue, Jun 20, 2017 at 1:47 PM, Lakmal Warusawithana <[hidden email]> wrote:
+1 Jochen, this is more cleaner and it is addressing governance aspect of the labels. 


On Tue, Jun 20, 2017 at 1:22 AM, Jochen Traunecker <[hidden email]> wrote:
Hi,

what about changing the meta-model a little bit and introduce another indirection : LABELSCOPE.  LABELS can be assigned to 1...n LABELSCOPES.

With this model, these use cases could get realised without confusing Publishers and avoiding redundancy in LABEL-Names (which should get avoided):

Use case : A Store and dedicated Gateway(s) for "Public APIs" - so everyone is free to sign up and subscribe
Use case: A B2B-Store with dedicated B2B-Gateways for "Business Customers" with invitation only
Use case: Internal API-Store and deployment to SECURE_ZONE_1 
Use case: internal API-Store and deployment to SECURE_ZONE_2

Publisher UI could filter labels based on LABELSCOPE and just render the ones needed for "Deployment to Gateway" selection UI element and "Visible in Store" selection UI component. Still the Label e.g. "PUBLIC" could be visible / assignable in both UI elements. 

With the options to define labels for Stores and Gateways there will be demand to govern and protect users from configuration mistakes. By that it would be just consequent to be able to specify, which label combinations are valid :-) I did not model this requirement. 

Furthermore there will be demand to define, which user/role is allowed, to assign specific labels. Only "public_publishers" are allowed to assign "public" label to APIs ...  

Ultimately, Labels could get used for "Publisher UIs". There are use cases, to expose a dedicated "Publisher UI" for internal APIs only, or a "Publisher UI" for some specific Business Unit X and so on. Such dedicated Publishers could limit / restrict the set of Labels assignable to APIs. 


LABEL
==============
LABEL_ID | NAME 
==============
1                | B2B
2                | PUBLIC
3                | INTERNAL
4                | SECURE_ZONE_1
5                | SECURE_ZONE_2

LABEL_API
===============
API_ID | LABEL_ID
===============

LABELSCOPE
================
LSCOPE_ID | NAME
================
1                   | GATEWAY
2                   | STORE


LABELSCOPE_LABEL
====================
LABEL_ID | LSCOPE_ID
====================
1               | 1
1               | 2
2               | 1
2               | 2   
3               | 2
4               | 1
5               | 1


Thanks,
Jochen

2017-06-19 21:43 GMT+02:00 Sajith Kariyawasam <[hidden email]>:
Hi Praminda, 

On Mon, Jun 19, 2017 at 11:05 PM, Lakmal Warusawithana <[hidden email]> wrote:
There are some use-cases for have multiple stores. yes it is store profile  (store REST API+ Store SPA + and Impel)

On Mon, Jun 19, 2017 at 10:25 PM, Bhathiya Jayasekara <[hidden email]> wrote:
Hi Praminda,

When we say a "store node", does that mean an APIM Core node, or a node with some kind of a profile with only store services?  

Thanks,
Bhathiya

On Mon, Jun 19, 2017 at 10:08 PM, Praminda Jayawardana <[hidden email]> wrote:
Hi All,

We've planned to introduce store labeling feature for API Manager 3.0.0. With this feature different business units inside an organizations will be able to publish their APIs in separate API Stores.

Ex:
Separate API Stores for Infra and Sales APIs.

Current plan is to utilize the same design as gateway label implementation with small set of changes. Therefore a Publisher of an API can select the Store label(s) he/she needs to publish the API and a Store node should be started with this specific label.
We are hoping to add following changes to current label implementation.

1. Add new column for label type: AM_LABELS
We can utilize the same label table used for storing gateway labels by introducing a new TYPE column to existing AM_LABELS table

==========================
LABEL_ID |  NAME   |  TYPE_ID
==========================
                 |               |

2. Add Label type table: AM_LABEL_TYPE
Table used to store label types. Currently only gateway and store labels

=====================
TYPE_ID |  TYPE_NAME
=====================
1              |  GATEWAY
2              |  STORE


What is the benefit of this AM_LABEL_TYPE table? Can't we just store the Type Name values (GATEWAY, STORE. etc.. ) in the Type column of AM_LABELS?
 
3. Add API-Label mapping table: AM_API_STORE_LABEL_MAPPING
New table is introduced to keep the mapping between an API and Labels

================
API_ID |  LABEL_ID
================
            |

Please let us know what do you think of the approach we have suggested.

Thanks,
Praminda

--

Praminda Jayawardana

Software Engineer
WSO2 Inc.; http://wso2.com
Mobile : <a href="tel:+94%2071%20659%200918" value="+94716590918" target="_blank">+94 (0) 716 590918



--
Bhathiya Jayasekara
Associate Technical Lead,
WSO2 inc., http://wso2.com

Phone: <a href="tel:+94%2071%20547%208185" value="+94715478185" target="_blank">+94715478185

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Lakmal Warusawithana
Director - Cloud Architecture; WSO2 Inc.
Mobile : <a href="tel:+94%2071%20428%209692" value="+94714289692" target="_blank">+94714289692


_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Sajith Kariyawasam
Associate Tech Lead
WSO2 Inc.; http://wso2.com
Committer and PMC member, Apache Stratos 
AMIE (SL)
Mobile: <a href="tel:07722%2069575" value="+49772269575" target="_blank">0772269575

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Gruss / regards

Jochen Traunecker
mailto: [hidden email]

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Lakmal Warusawithana
Director - Cloud Architecture; WSO2 Inc.
Mobile : <a href="tel:+94%2071%20428%209692" value="+94714289692" target="_blank">+94714289692


_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Harsha Kumara
Software Engineer, WSO2 Inc.
Mobile: <a href="tel:077%20550%205618" value="+94775505618" target="_blank">+94775505618
Blog:harshcreationz.blogspot.com

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Bhathiya Jayasekara
Associate Technical Lead,
WSO2 inc., http://wso2.com

Phone: +94715478185

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Reply | Threaded
Open this post in threaded view
|

Re: [Architechture] [APIM] Label based Store nodes for API Manager

Harsha Kumara-2


On Tue, Jun 20, 2017 at 10:00 PM, Bhathiya Jayasekara <[hidden email]> wrote:
Hi all,

On Tue, Jun 20, 2017 at 7:43 PM, Harsha Kumara <[hidden email]> wrote:
Hi All,

Currently, we are adding labels through core API when gateway gets registered with the core. Since we don't have permissions for the gateway labels it allows publishers to select whatever gateway that they want to publish. Are we going to incorporate it with our permission model? This will also apply for the store labels as well. 

@praminda how are we plan to add labels before we going to attach them to the APIs?

Don't we need some place to manage these labels? If we forget about engaging the permission model for a moment, we may add labels when a store/gateway is started with a new label. But to remove such added labels, we may need some place to list them down. 
We discussed about this sometime back to provide a interface to manage the labels. Pubudu should have more insight on this.

WDYT?

Thanks,
Bhathiya
 

Thanks,
Harsha

On Tue, Jun 20, 2017 at 1:47 PM, Lakmal Warusawithana <[hidden email]> wrote:
+1 Jochen, this is more cleaner and it is addressing governance aspect of the labels. 


On Tue, Jun 20, 2017 at 1:22 AM, Jochen Traunecker <[hidden email]> wrote:
Hi,

what about changing the meta-model a little bit and introduce another indirection : LABELSCOPE.  LABELS can be assigned to 1...n LABELSCOPES.

With this model, these use cases could get realised without confusing Publishers and avoiding redundancy in LABEL-Names (which should get avoided):

Use case : A Store and dedicated Gateway(s) for "Public APIs" - so everyone is free to sign up and subscribe
Use case: A B2B-Store with dedicated B2B-Gateways for "Business Customers" with invitation only
Use case: Internal API-Store and deployment to SECURE_ZONE_1 
Use case: internal API-Store and deployment to SECURE_ZONE_2

Publisher UI could filter labels based on LABELSCOPE and just render the ones needed for "Deployment to Gateway" selection UI element and "Visible in Store" selection UI component. Still the Label e.g. "PUBLIC" could be visible / assignable in both UI elements. 

With the options to define labels for Stores and Gateways there will be demand to govern and protect users from configuration mistakes. By that it would be just consequent to be able to specify, which label combinations are valid :-) I did not model this requirement. 

Furthermore there will be demand to define, which user/role is allowed, to assign specific labels. Only "public_publishers" are allowed to assign "public" label to APIs ...  

Ultimately, Labels could get used for "Publisher UIs". There are use cases, to expose a dedicated "Publisher UI" for internal APIs only, or a "Publisher UI" for some specific Business Unit X and so on. Such dedicated Publishers could limit / restrict the set of Labels assignable to APIs. 


LABEL
==============
LABEL_ID | NAME 
==============
1                | B2B
2                | PUBLIC
3                | INTERNAL
4                | SECURE_ZONE_1
5                | SECURE_ZONE_2

LABEL_API
===============
API_ID | LABEL_ID
===============

LABELSCOPE
================
LSCOPE_ID | NAME
================
1                   | GATEWAY
2                   | STORE


LABELSCOPE_LABEL
====================
LABEL_ID | LSCOPE_ID
====================
1               | 1
1               | 2
2               | 1
2               | 2   
3               | 2
4               | 1
5               | 1


Thanks,
Jochen

2017-06-19 21:43 GMT+02:00 Sajith Kariyawasam <[hidden email]>:
Hi Praminda, 

On Mon, Jun 19, 2017 at 11:05 PM, Lakmal Warusawithana <[hidden email]> wrote:
There are some use-cases for have multiple stores. yes it is store profile  (store REST API+ Store SPA + and Impel)

On Mon, Jun 19, 2017 at 10:25 PM, Bhathiya Jayasekara <[hidden email]> wrote:
Hi Praminda,

When we say a "store node", does that mean an APIM Core node, or a node with some kind of a profile with only store services?  

Thanks,
Bhathiya

On Mon, Jun 19, 2017 at 10:08 PM, Praminda Jayawardana <[hidden email]> wrote:
Hi All,

We've planned to introduce store labeling feature for API Manager 3.0.0. With this feature different business units inside an organizations will be able to publish their APIs in separate API Stores.

Ex:
Separate API Stores for Infra and Sales APIs.

Current plan is to utilize the same design as gateway label implementation with small set of changes. Therefore a Publisher of an API can select the Store label(s) he/she needs to publish the API and a Store node should be started with this specific label.
We are hoping to add following changes to current label implementation.

1. Add new column for label type: AM_LABELS
We can utilize the same label table used for storing gateway labels by introducing a new TYPE column to existing AM_LABELS table

==========================
LABEL_ID |  NAME   |  TYPE_ID
==========================
                 |               |

2. Add Label type table: AM_LABEL_TYPE
Table used to store label types. Currently only gateway and store labels

=====================
TYPE_ID |  TYPE_NAME
=====================
1              |  GATEWAY
2              |  STORE


What is the benefit of this AM_LABEL_TYPE table? Can't we just store the Type Name values (GATEWAY, STORE. etc.. ) in the Type column of AM_LABELS?
 
3. Add API-Label mapping table: AM_API_STORE_LABEL_MAPPING
New table is introduced to keep the mapping between an API and Labels

================
API_ID |  LABEL_ID
================
            |

Please let us know what do you think of the approach we have suggested.

Thanks,
Praminda

--

Praminda Jayawardana

Software Engineer
WSO2 Inc.; http://wso2.com
Mobile : <a href="tel:+94%2071%20659%200918" value="+94716590918" target="_blank">+94 (0) 716 590918



--
Bhathiya Jayasekara
Associate Technical Lead,
WSO2 inc., http://wso2.com

Phone: <a href="tel:+94%2071%20547%208185" value="+94715478185" target="_blank">+94715478185

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Lakmal Warusawithana
Director - Cloud Architecture; WSO2 Inc.
Mobile : <a href="tel:+94%2071%20428%209692" value="+94714289692" target="_blank">+94714289692


_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Sajith Kariyawasam
Associate Tech Lead
WSO2 Inc.; http://wso2.com
Committer and PMC member, Apache Stratos 
AMIE (SL)
Mobile: <a href="tel:07722%2069575" value="+49772269575" target="_blank">0772269575

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Gruss / regards

Jochen Traunecker
mailto: [hidden email]

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Lakmal Warusawithana
Director - Cloud Architecture; WSO2 Inc.
Mobile : <a href="tel:+94%2071%20428%209692" value="+94714289692" target="_blank">+94714289692


_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Harsha Kumara
Software Engineer, WSO2 Inc.
Mobile: <a href="tel:077%20550%205618" value="+94775505618" target="_blank">+94775505618
Blog:harshcreationz.blogspot.com

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Bhathiya Jayasekara
Associate Technical Lead,
WSO2 inc., http://wso2.com

Phone: <a href="tel:+94%2071%20547%208185" value="+94715478185" target="_blank">+94715478185



--
Harsha Kumara
Software Engineer, WSO2 Inc.
Mobile: <a href="tel:+94%2077%20550%205618" value="+94775505618" target="_blank">+94775505618
Blog:harshcreationz.blogspot.com

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Reply | Threaded
Open this post in threaded view
|

Re: [Architechture] [APIM] Label based Store nodes for API Manager

Thilini Shanika
In reply to this post by Bhathiya Jayasekara
Don't we need some place to manage these labels? If we forget about engaging the permission model for a moment, we may add labels when a store/gateway is started with a new label. But to remove such added labels, we may need some place to list them down. 

WDYT?
+1 to have a place to manage labels. When we consider the gateway label registration scenario, there is no mechanism to remove the labels that are not in use. If one of the gateways removed from the deployment or if one of the existing gateways changed the label and re-registered in APIM core, there is no way of removing the deprecated labels. Thus, it's better to have a label management functionality (may be in admin app).

On Tue, Jun 20, 2017 at 10:00 PM, Bhathiya Jayasekara <[hidden email]> wrote:
Hi all,

On Tue, Jun 20, 2017 at 7:43 PM, Harsha Kumara <[hidden email]> wrote:
Hi All,

Currently, we are adding labels through core API when gateway gets registered with the core. Since we don't have permissions for the gateway labels it allows publishers to select whatever gateway that they want to publish. Are we going to incorporate it with our permission model? This will also apply for the store labels as well. 

@praminda how are we plan to add labels before we going to attach them to the APIs?

Don't we need some place to manage these labels? If we forget about engaging the permission model for a moment, we may add labels when a store/gateway is started with a new label. But to remove such added labels, we may need some place to list them down. 

WDYT?

Thanks,
Bhathiya
 

Thanks,
Harsha

On Tue, Jun 20, 2017 at 1:47 PM, Lakmal Warusawithana <[hidden email]> wrote:
+1 Jochen, this is more cleaner and it is addressing governance aspect of the labels. 


On Tue, Jun 20, 2017 at 1:22 AM, Jochen Traunecker <[hidden email]> wrote:
Hi,

what about changing the meta-model a little bit and introduce another indirection : LABELSCOPE.  LABELS can be assigned to 1...n LABELSCOPES.

With this model, these use cases could get realised without confusing Publishers and avoiding redundancy in LABEL-Names (which should get avoided):

Use case : A Store and dedicated Gateway(s) for "Public APIs" - so everyone is free to sign up and subscribe
Use case: A B2B-Store with dedicated B2B-Gateways for "Business Customers" with invitation only
Use case: Internal API-Store and deployment to SECURE_ZONE_1 
Use case: internal API-Store and deployment to SECURE_ZONE_2

Publisher UI could filter labels based on LABELSCOPE and just render the ones needed for "Deployment to Gateway" selection UI element and "Visible in Store" selection UI component. Still the Label e.g. "PUBLIC" could be visible / assignable in both UI elements. 

With the options to define labels for Stores and Gateways there will be demand to govern and protect users from configuration mistakes. By that it would be just consequent to be able to specify, which label combinations are valid :-) I did not model this requirement. 

Furthermore there will be demand to define, which user/role is allowed, to assign specific labels. Only "public_publishers" are allowed to assign "public" label to APIs ...  

Ultimately, Labels could get used for "Publisher UIs". There are use cases, to expose a dedicated "Publisher UI" for internal APIs only, or a "Publisher UI" for some specific Business Unit X and so on. Such dedicated Publishers could limit / restrict the set of Labels assignable to APIs. 


LABEL
==============
LABEL_ID | NAME 
==============
1                | B2B
2                | PUBLIC
3                | INTERNAL
4                | SECURE_ZONE_1
5                | SECURE_ZONE_2

LABEL_API
===============
API_ID | LABEL_ID
===============

LABELSCOPE
================
LSCOPE_ID | NAME
================
1                   | GATEWAY
2                   | STORE


LABELSCOPE_LABEL
====================
LABEL_ID | LSCOPE_ID
====================
1               | 1
1               | 2
2               | 1
2               | 2   
3               | 2
4               | 1
5               | 1


Thanks,
Jochen

2017-06-19 21:43 GMT+02:00 Sajith Kariyawasam <[hidden email]>:
Hi Praminda, 

On Mon, Jun 19, 2017 at 11:05 PM, Lakmal Warusawithana <[hidden email]> wrote:
There are some use-cases for have multiple stores. yes it is store profile  (store REST API+ Store SPA + and Impel)

On Mon, Jun 19, 2017 at 10:25 PM, Bhathiya Jayasekara <[hidden email]> wrote:
Hi Praminda,

When we say a "store node", does that mean an APIM Core node, or a node with some kind of a profile with only store services?  

Thanks,
Bhathiya

On Mon, Jun 19, 2017 at 10:08 PM, Praminda Jayawardana <[hidden email]> wrote:
Hi All,

We've planned to introduce store labeling feature for API Manager 3.0.0. With this feature different business units inside an organizations will be able to publish their APIs in separate API Stores.

Ex:
Separate API Stores for Infra and Sales APIs.

Current plan is to utilize the same design as gateway label implementation with small set of changes. Therefore a Publisher of an API can select the Store label(s) he/she needs to publish the API and a Store node should be started with this specific label.
We are hoping to add following changes to current label implementation.

1. Add new column for label type: AM_LABELS
We can utilize the same label table used for storing gateway labels by introducing a new TYPE column to existing AM_LABELS table

==========================
LABEL_ID |  NAME   |  TYPE_ID
==========================
                 |               |

2. Add Label type table: AM_LABEL_TYPE
Table used to store label types. Currently only gateway and store labels

=====================
TYPE_ID |  TYPE_NAME
=====================
1              |  GATEWAY
2              |  STORE


What is the benefit of this AM_LABEL_TYPE table? Can't we just store the Type Name values (GATEWAY, STORE. etc.. ) in the Type column of AM_LABELS?
 
3. Add API-Label mapping table: AM_API_STORE_LABEL_MAPPING
New table is introduced to keep the mapping between an API and Labels

================
API_ID |  LABEL_ID
================
            |

Please let us know what do you think of the approach we have suggested.

Thanks,
Praminda

--

Praminda Jayawardana

Software Engineer
WSO2 Inc.; http://wso2.com
Mobile : <a href="tel:+94%2071%20659%200918" value="+94716590918" target="_blank">+94 (0) 716 590918



--
Bhathiya Jayasekara
Associate Technical Lead,
WSO2 inc., http://wso2.com

Phone: <a href="tel:+94%2071%20547%208185" value="+94715478185" target="_blank">+94715478185

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Lakmal Warusawithana
Director - Cloud Architecture; WSO2 Inc.
Mobile : <a href="tel:+94%2071%20428%209692" value="+94714289692" target="_blank">+94714289692


_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Sajith Kariyawasam
Associate Tech Lead
WSO2 Inc.; http://wso2.com
Committer and PMC member, Apache Stratos 
AMIE (SL)
Mobile: <a href="tel:07722%2069575" value="+49772269575" target="_blank">0772269575

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Gruss / regards

Jochen Traunecker
mailto: [hidden email]

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Lakmal Warusawithana
Director - Cloud Architecture; WSO2 Inc.
Mobile : <a href="tel:+94%2071%20428%209692" value="+94714289692" target="_blank">+94714289692


_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Harsha Kumara
Software Engineer, WSO2 Inc.
Mobile: <a href="tel:077%20550%205618" value="+94775505618" target="_blank">+94775505618
Blog:harshcreationz.blogspot.com

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Bhathiya Jayasekara
Associate Technical Lead,
WSO2 inc., http://wso2.com

Phone: <a href="tel:+94%2071%20547%208185" value="+94715478185" target="_blank">+94715478185



--
Thilini Shanika
Senior Software Engineer

WSO2, Inc.; http://wso2.com
20, Palmgrove Avenue, Colombo 3



_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Reply | Threaded
Open this post in threaded view
|

Re: [Architechture] [APIM] Label based Store nodes for API Manager

Pubudu Gunatilaka-2
Hi, 

We actually have a REST API to delete a given label. Also, for the initial version, we thought of simplifying the label scenario. In later releases, we can add an UI support to manage labels. 

I don't think we need to bring the permission model unless we provide gateways per user/group. In the store side, we have introduced an extension point to filter labels depends on the user.  

The story behind the label scenario is to simplify the dynamic gateway registration. For an example, consider a deployment which has multiple APIs deployed in public and private gateways. Now our requirement is to spin a new gateway in Singapore region and serve a particular API. What we need to do is to spin a gateway in that region with the new label and re-publish the API with the new label. We have used labels to manage gateways in this scenario.

If we are not allowing dynamic label registration, we can have admin API for labels. Yes, we can ship default labels. But when we need to bring up a new gateway, we have to make the REST calls to register the gateway. This is kind of a user interaction or maybe we can automate this based on the use case. But with dynamic label registration, we don't need to do anything specifically. If we consider a container scenario, we only need to pass an environment variable with the new label name to the container to spin up a new gateway container in a new region.

Thank you!
--
Pubudu Gunatilaka
Committer and PMC Member - Apache Stratos
Software Engineer 
WSO2, Inc.: http://wso2.com
mobile : <a href="tel:%2B94772207163" value="+94772207163" style="font-size:x-small;color:rgb(17,85,204)" target="_blank">+94774078049


_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Reply | Threaded
Open this post in threaded view
|

Re: [Architechture] [APIM] Label based Store nodes for API Manager

Isuru Haththotuwa


On Tue, Jun 20, 2017 at 11:16 PM, Pubudu Gunatilaka <[hidden email]> wrote:
Hi, 

We actually have a REST API to delete a given label. Also, for the initial version, we thought of simplifying the label scenario. In later releases, we can add an UI support to manage labels. 

I don't think we need to bring the permission model unless we provide gateways per user/group. In the store side, we have introduced an extension point to filter labels depends on the user.  
What would happen if a user deletes label that is already is used by a gateway? Or if all the labels are deleted? Wouldn't it impact the functionality of gateways? If it does, IMO we would need to have an authorization level for manipulating labels as well.

The story behind the label scenario is to simplify the dynamic gateway registration. For an example, consider a deployment which has multiple APIs deployed in public and private gateways. Now our requirement is to spin a new gateway in Singapore region and serve a particular API. What we need to do is to spin a gateway in that region with the new label and re-publish the API with the new label. We have used labels to manage gateways in this scenario.

If we are not allowing dynamic label registration, we can have admin API for labels. Yes, we can ship default labels. But when we need to bring up a new gateway, we have to make the REST calls to register the gateway. This is kind of a user interaction or maybe we can automate this based on the use case. But with dynamic label registration, we don't need to do anything specifically. If we consider a container scenario, we only need to pass an environment variable with the new label name to the container to spin up a new gateway container in a new region.

Thank you!
--
Pubudu Gunatilaka
Committer and PMC Member - Apache Stratos
Software Engineer 
WSO2, Inc.: http://wso2.com
mobile : <a href="tel:%2B94772207163" value="+94772207163" style="font-size:x-small;color:rgb(17,85,204)" target="_blank">+94774078049


_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Thanks and Regards,

Isuru H.
+94 716 358 048



_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Reply | Threaded
Open this post in threaded view
|

Re: [Architechture] [APIM] Label based Store nodes for API Manager

lakmal Warusawithana
In reply to this post by Pubudu Gunatilaka-2


On Tue, Jun 20, 2017 at 11:16 PM, Pubudu Gunatilaka <[hidden email]> wrote:
Hi, 

We actually have a REST API to delete a given label. Also, for the initial version, we thought of simplifying the label scenario. In later releases, we can add an UI support to manage labels. 

I don't think we need to bring the permission model unless we provide gateways per user/group. In the store side, we have introduced an extension point to filter labels depends on the user.  

The story behind the label scenario is to simplify the dynamic gateway registration. For an example, consider a deployment which has multiple APIs deployed in public and private gateways. Now our requirement is to spin a new gateway in Singapore region and serve a particular API. What we need to do is to spin a gateway in that region with the new label and re-publish the API with the new label. We have used labels to manage gateways in this scenario.

If we are not allowing dynamic label registration, we can have admin API for labels. Yes, we can ship default labels. But when we need to bring up a new gateway, we have to make the REST calls to register the gateway. This is kind of a user interaction or maybe we can automate this based on the use case. But with dynamic label registration, we don't need to do anything specifically. If we consider a container scenario, we only need to pass an environment variable with the new label name to the container to spin up a new gateway container in a new region.


IMO, but when we come to displaying labels in publisher, governance aspect going to be critical. If we going to add governance aspect, dynamic label registration has minimal advantage. In that case anyhow it need to go through the some kind of permission model.  

 
Thank you!
--
Pubudu Gunatilaka
Committer and PMC Member - Apache Stratos
Software Engineer 
WSO2, Inc.: http://wso2.com
mobile : <a href="tel:%2B94772207163" value="+94772207163" style="font-size:x-small;color:rgb(17,85,204)" target="_blank">+94774078049


_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Lakmal Warusawithana
Director - Cloud Architecture; WSO2 Inc.
Mobile : +94714289692


_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Reply | Threaded
Open this post in threaded view
|

Re: [Architechture] [APIM] Label based Store nodes for API Manager

Praminda Jayawardana
+1 for attaching permission model with labels.

As per current discussion we'll need following items added to our todo.
  1. Attach permission model with label.
  2. admin APIs to manage(CRUD operations) labels. There will be a UI in admin app.

Is there any other things we need to consider?

Thanks,
Praminda

On Wed, Jun 21, 2017 at 7:20 AM, Lakmal Warusawithana <[hidden email]> wrote:


On Tue, Jun 20, 2017 at 11:16 PM, Pubudu Gunatilaka <[hidden email]> wrote:
Hi, 

We actually have a REST API to delete a given label. Also, for the initial version, we thought of simplifying the label scenario. In later releases, we can add an UI support to manage labels. 

I don't think we need to bring the permission model unless we provide gateways per user/group. In the store side, we have introduced an extension point to filter labels depends on the user.  

The story behind the label scenario is to simplify the dynamic gateway registration. For an example, consider a deployment which has multiple APIs deployed in public and private gateways. Now our requirement is to spin a new gateway in Singapore region and serve a particular API. What we need to do is to spin a gateway in that region with the new label and re-publish the API with the new label. We have used labels to manage gateways in this scenario.

If we are not allowing dynamic label registration, we can have admin API for labels. Yes, we can ship default labels. But when we need to bring up a new gateway, we have to make the REST calls to register the gateway. This is kind of a user interaction or maybe we can automate this based on the use case. But with dynamic label registration, we don't need to do anything specifically. If we consider a container scenario, we only need to pass an environment variable with the new label name to the container to spin up a new gateway container in a new region.


IMO, but when we come to displaying labels in publisher, governance aspect going to be critical. If we going to add governance aspect, dynamic label registration has minimal advantage. In that case anyhow it need to go through the some kind of permission model.  

 
Thank you!
--
Pubudu Gunatilaka
Committer and PMC Member - Apache Stratos
Software Engineer 
WSO2, Inc.: http://wso2.com
mobile : <a href="tel:%2B94772207163" value="+94772207163" style="font-size:x-small;color:rgb(17,85,204)" target="_blank">+94774078049


_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Lakmal Warusawithana
Director - Cloud Architecture; WSO2 Inc.
Mobile : <a href="tel:+94%2071%20428%209692" value="+94714289692" target="_blank">+94714289692


_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--

Praminda Jayawardana

Software Engineer
WSO2 Inc.; http://wso2.com
Mobile : +94 (0) 716 590918

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Reply | Threaded
Open this post in threaded view
|

Re: [Architechture] [APIM] Label based Store nodes for API Manager

Praminda Jayawardana
Hi All,

I've updated the design as per the discussion in this thread.



Inline image 2



With this design API Publisher will be asked only to select one label (for both gateway and store). Which combination of gateway and store is applied for this particular API, depends on the label's scope. If label only has GATEWAY scope this API will be deployed on the gateway with selected label but it will not be attached with a specific store (will be visible in default store). If label has both GATEWAY and STORE scopes API will be deployed on a specific gateway and a store specified by that label.
When selecting label's, API Publisher will only see the labels he/she has access depending on the label permissions. Also dynamic label registration will not be available anymore as we need intermediate step of permission setting in label creation process.

Thanks,
Praminda


On Wed, Jun 21, 2017 at 3:43 PM, Praminda Jayawardana <[hidden email]> wrote:
+1 for attaching permission model with labels.

As per current discussion we'll need following items added to our todo.
  1. Attach permission model with label.
  2. admin APIs to manage(CRUD operations) labels. There will be a UI in admin app.

Is there any other things we need to consider?

Thanks,
Praminda

On Wed, Jun 21, 2017 at 7:20 AM, Lakmal Warusawithana <[hidden email]> wrote:


On Tue, Jun 20, 2017 at 11:16 PM, Pubudu Gunatilaka <[hidden email]> wrote:
Hi, 

We actually have a REST API to delete a given label. Also, for the initial version, we thought of simplifying the label scenario. In later releases, we can add an UI support to manage labels. 

I don't think we need to bring the permission model unless we provide gateways per user/group. In the store side, we have introduced an extension point to filter labels depends on the user.  

The story behind the label scenario is to simplify the dynamic gateway registration. For an example, consider a deployment which has multiple APIs deployed in public and private gateways. Now our requirement is to spin a new gateway in Singapore region and serve a particular API. What we need to do is to spin a gateway in that region with the new label and re-publish the API with the new label. We have used labels to manage gateways in this scenario.

If we are not allowing dynamic label registration, we can have admin API for labels. Yes, we can ship default labels. But when we need to bring up a new gateway, we have to make the REST calls to register the gateway. This is kind of a user interaction or maybe we can automate this based on the use case. But with dynamic label registration, we don't need to do anything specifically. If we consider a container scenario, we only need to pass an environment variable with the new label name to the container to spin up a new gateway container in a new region.


IMO, but when we come to displaying labels in publisher, governance aspect going to be critical. If we going to add governance aspect, dynamic label registration has minimal advantage. In that case anyhow it need to go through the some kind of permission model.  

 
Thank you!
--
Pubudu Gunatilaka
Committer and PMC Member - Apache Stratos
Software Engineer 
WSO2, Inc.: http://wso2.com
mobile : <a href="tel:%2B94772207163" value="+94772207163" style="font-size:x-small;color:rgb(17,85,204)" target="_blank">+94774078049


_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Lakmal Warusawithana
Director - Cloud Architecture; WSO2 Inc.
Mobile : <a href="tel:+94%2071%20428%209692" value="+94714289692" target="_blank">+94714289692


_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--

Praminda Jayawardana

Software Engineer
WSO2 Inc.; http://wso2.com
Mobile : <a href="tel:+94%2071%20659%200918" value="+94716590918" target="_blank">+94 (0) 716 590918



--

Praminda Jayawardana

Software Engineer
WSO2 Inc.; http://wso2.com
Mobile : +94 (0) 716 590918

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Reply | Threaded
Open this post in threaded view
|

Re: [Architechture] [APIM] Label based Store nodes for API Manager

lakmal Warusawithana
Hi Praminda,

Seems like this going to be quite complex to support all use-case what we have. May be simple permission model is ideal.

Please verify following use cases can support with the design.

General use-case
  1. By default (in fresh deployment) no labels are defined.
  2. When API's create no labels to attach
  3. GW and Store will start without any label
    1. Store will display API's which does not attach any label
    2. GW pull API's which does not attache any label

Multi GW and multi Store use-case
  1. Admin will create labels
    1. Label : US-WEST, type=gateway, Access URL = us-west.abc.com
    2. Label : US-EAST, type=gateway, Access URL = us-east.abc.com
    3. Label : ASIA, type=gateway, Access URL = asia.abc.com
    4. Label : US , type=store
    5. Label : ASIA, type=store
    6. Label : WORLD, type=store
  2. Admin should be able to set some permission to labels to cover #10,#11 use-case
  3. GW1, will start with US-WEST label and pull all APIs attach US-WEST label
  4. GW2 will start with US-EAST label and pull all APIs attach US-EAST label
  5. GW3 will start with ASIA label and pull all APIs attach ASIA label
  6. API1 will attach US-WEST, US-EAST gateway labels and US,WORLD store labels.
  7. API2 will attach US-WEST gateway label and US,WORLD store labels.
  8. API3 will attach US-EAST gateway label and US,WORLD store labels.
  9. API4 will attach ASIA gateway label and ASIA,WORLD store labels.
  10. US publisher team should only be able to attach US-WEST, US-EAST gateway labels and US,WORLD store labels. (other labels should not visible)
  11. ASIA publisher team should only be able to attach ASIA gateway label and ASIA,WORLD store labels. (other labels should not visible)

thanks

On Thu, Jun 22, 2017 at 2:13 PM, Praminda Jayawardana <[hidden email]> wrote:
Hi All,

I've updated the design as per the discussion in this thread.



Inline image 2



With this design API Publisher will be asked only to select one label (for both gateway and store). Which combination of gateway and store is applied for this particular API, depends on the label's scope. If label only has GATEWAY scope this API will be deployed on the gateway with selected label but it will not be attached with a specific store (will be visible in default store). If label has both GATEWAY and STORE scopes API will be deployed on a specific gateway and a store specified by that label.
When selecting label's, API Publisher will only see the labels he/she has access depending on the label permissions. Also dynamic label registration will not be available anymore as we need intermediate step of permission setting in label creation process.

Thanks,
Praminda


On Wed, Jun 21, 2017 at 3:43 PM, Praminda Jayawardana <[hidden email]> wrote:
+1 for attaching permission model with labels.

As per current discussion we'll need following items added to our todo.
  1. Attach permission model with label.
  2. admin APIs to manage(CRUD operations) labels. There will be a UI in admin app.

Is there any other things we need to consider?

Thanks,
Praminda

On Wed, Jun 21, 2017 at 7:20 AM, Lakmal Warusawithana <[hidden email]> wrote:


On Tue, Jun 20, 2017 at 11:16 PM, Pubudu Gunatilaka <[hidden email]> wrote:
Hi, 

We actually have a REST API to delete a given label. Also, for the initial version, we thought of simplifying the label scenario. In later releases, we can add an UI support to manage labels. 

I don't think we need to bring the permission model unless we provide gateways per user/group. In the store side, we have introduced an extension point to filter labels depends on the user.  

The story behind the label scenario is to simplify the dynamic gateway registration. For an example, consider a deployment which has multiple APIs deployed in public and private gateways. Now our requirement is to spin a new gateway in Singapore region and serve a particular API. What we need to do is to spin a gateway in that region with the new label and re-publish the API with the new label. We have used labels to manage gateways in this scenario.

If we are not allowing dynamic label registration, we can have admin API for labels. Yes, we can ship default labels. But when we need to bring up a new gateway, we have to make the REST calls to register the gateway. This is kind of a user interaction or maybe we can automate this based on the use case. But with dynamic label registration, we don't need to do anything specifically. If we consider a container scenario, we only need to pass an environment variable with the new label name to the container to spin up a new gateway container in a new region.


IMO, but when we come to displaying labels in publisher, governance aspect going to be critical. If we going to add governance aspect, dynamic label registration has minimal advantage. In that case anyhow it need to go through the some kind of permission model.  

 
Thank you!
--
Pubudu Gunatilaka
Committer and PMC Member - Apache Stratos
Software Engineer 
WSO2, Inc.: http://wso2.com
mobile : <a href="tel:%2B94772207163" value="+94772207163" style="font-size:x-small;color:rgb(17,85,204)" target="_blank">+94774078049


_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Lakmal Warusawithana
Director - Cloud Architecture; WSO2 Inc.
Mobile : <a href="tel:+94%2071%20428%209692" value="+94714289692" target="_blank">+94714289692


_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--

Praminda Jayawardana

Software Engineer
WSO2 Inc.; http://wso2.com
Mobile : <a href="tel:+94%2071%20659%200918" value="+94716590918" target="_blank">+94 (0) 716 590918



--

Praminda Jayawardana

Software Engineer
WSO2 Inc.; http://wso2.com
Mobile : <a href="tel:+94%2071%20659%200918" value="+94716590918" target="_blank">+94 (0) 716 590918

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Lakmal Warusawithana
Director - Cloud Architecture; WSO2 Inc.
Mobile : <a href="tel:+94%2071%20428%209692" value="+94714289692" target="_blank">+94714289692


_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Reply | Threaded
Open this post in threaded view
|

Re: [Architechture] [APIM] Label based Store nodes for API Manager

Pubudu Gunatilaka-2
Hi Lakmal,

I think we have to rethink about the general use-case scenario. I have missed some of the points during the offline discussion we had.

Let me first explain the current model. The label is a must for a gateway and gateway can have only one label. When you are spinning a new gateway, you can provide a label name with access urls. We manage access urls of the gateways using labels. For an API, you can select multiple labels. When you select an API in API Store, based on the attached labels to the API, we display the gateway endpoints where you can use to invoke the API.

For the general use case, if we are not mandating or introducing a default label, we need to find a way of displaying gateway urls. One of the options I have in mind is to introduce a default label. It has the access url of the gateway. Still, we can go with the admin API and move away from the dynamic gateway registration. This is more suitable in order to introduce the permission model to the labels. The label selection is not mandatory when creating an API. If the user hasn't selected any label, we can attach the default label. 

Thank you!
--
Pubudu Gunatilaka
Committer and PMC Member - Apache Stratos
Software Engineer 
WSO2, Inc.: http://wso2.com
mobile : <a href="tel:%2B94772207163" value="+94772207163" style="font-size:x-small;color:rgb(17,85,204)" target="_blank">+94774078049


_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Reply | Threaded
Open this post in threaded view
|

Re: [Architechture] [APIM] Label based Store nodes for API Manager

Jochen Traunecker
Hi Pubudu,

I'm wondering how Gateways will get registered that have no idea about the URLs they will be accessible? Sitting behind a load balancer and the URL of the LB might change etc. 

Is there some document / discussion explaining how Gateways will be registered to learn more about the approach?

Thanks,
Jochen

2017-06-23 8:07 GMT+02:00 Pubudu Gunatilaka <[hidden email]>:
Hi Lakmal,

I think we have to rethink about the general use-case scenario. I have missed some of the points during the offline discussion we had.

Let me first explain the current model. The label is a must for a gateway and gateway can have only one label. When you are spinning a new gateway, you can provide a label name with access urls. We manage access urls of the gateways using labels. For an API, you can select multiple labels. When you select an API in API Store, based on the attached labels to the API, we display the gateway endpoints where you can use to invoke the API.

For the general use case, if we are not mandating or introducing a default label, we need to find a way of displaying gateway urls. One of the options I have in mind is to introduce a default label. It has the access url of the gateway. Still, we can go with the admin API and move away from the dynamic gateway registration. This is more suitable in order to introduce the permission model to the labels. The label selection is not mandatory when creating an API. If the user hasn't selected any label, we can attach the default label. 

Thank you!
--
Pubudu Gunatilaka
Committer and PMC Member - Apache Stratos
Software Engineer 
WSO2, Inc.: http://wso2.com
mobile : <a href="tel:%2B94772207163" value="+94772207163" style="font-size:x-small;color:rgb(17,85,204)" target="_blank">+94774078049


_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Gruss / regards

Jochen Traunecker
mailto: [hidden email]

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Reply | Threaded
Open this post in threaded view
|

Re: [Architechture] [APIM] Label based Store nodes for API Manager

Pubudu Gunatilaka-2
Hi Jochen,

Yes, gateways will be sitting behind the load balancer. The basic idea of the initial design was when spinning up a gateway node in a cluster, we need to provide a label name and the access url of the gateway. So, this access url will be the load balancer url. We have already introduced an overwrite property, where you can change the access url of the label if needed. You can find the initial discussion mail thread with subject [1].

As we are to move towards a new Admin API for label registration, we can change the access urls and other details using the API.

[1] - [C5][APIM] Introducing labels based gateway environments in API Manager

Thank you!

On Fri, Jun 23, 2017 at 1:19 PM, Jochen Traunecker <[hidden email]> wrote:
Hi Pubudu,

I'm wondering how Gateways will get registered that have no idea about the URLs they will be accessible? Sitting behind a load balancer and the URL of the LB might change etc. 

Is there some document / discussion explaining how Gateways will be registered to learn more about the approach?

Thanks,
Jochen

2017-06-23 8:07 GMT+02:00 Pubudu Gunatilaka <[hidden email]>:
Hi Lakmal,

I think we have to rethink about the general use-case scenario. I have missed some of the points during the offline discussion we had.

Let me first explain the current model. The label is a must for a gateway and gateway can have only one label. When you are spinning a new gateway, you can provide a label name with access urls. We manage access urls of the gateways using labels. For an API, you can select multiple labels. When you select an API in API Store, based on the attached labels to the API, we display the gateway endpoints where you can use to invoke the API.

For the general use case, if we are not mandating or introducing a default label, we need to find a way of displaying gateway urls. One of the options I have in mind is to introduce a default label. It has the access url of the gateway. Still, we can go with the admin API and move away from the dynamic gateway registration. This is more suitable in order to introduce the permission model to the labels. The label selection is not mandatory when creating an API. If the user hasn't selected any label, we can attach the default label. 

Thank you!
--
Pubudu Gunatilaka
Committer and PMC Member - Apache Stratos
Software Engineer 
WSO2, Inc.: http://wso2.com
mobile : <a href="tel:%2B94772207163" value="+94772207163" style="font-size:x-small;color:rgb(17,85,204)" target="_blank">+94774078049


_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture




--
Gruss / regards

Jochen Traunecker
mailto: [hidden email]



--
Pubudu Gunatilaka
Committer and PMC Member - Apache Stratos
Software Engineer 
WSO2, Inc.: http://wso2.com
mobile : <a href="tel:%2B94772207163" value="+94772207163" style="font-size:x-small;color:rgb(17,85,204)" target="_blank">+94774078049


_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture