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 <[email protected]> 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 < > [email protected]> 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 <[email protected]>: >> >>> Hi Praminda, >>> >>> On Mon, Jun 19, 2017 at 11:05 PM, Lakmal Warusawithana <[email protected]> >>> 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 < >>>> [email protected]> 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 < >>>>> [email protected]> 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 : +94 (0) 716 590918 <+94%2071%20659%200918> >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> *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/>* >>>>> >>>>> _______________________________________________ >>>>> Architecture mailing list >>>>> [email protected] >>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>> >>>>> >>>> >>>> >>>> -- >>>> Lakmal Warusawithana >>>> Director - Cloud Architecture; WSO2 Inc. >>>> Mobile : +94714289692 <+94%2071%20428%209692> >>>> Blogs : https://medium.com/@lakwarus/ >>>> http://lakmalsview.blogspot.com/ >>>> >>>> >>>> _______________________________________________ >>>> Architecture mailing list >>>> [email protected] >>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>> >>>> >>> >>> >>> -- >>> Sajith Kariyawasam >>> *Associate Tech Lead* >>> *WSO2 Inc.; http://wso2.com <http://wso2.com/>* >>> *Committer and PMC member, Apache Stratos * >>> *AMIE (SL)* >>> *Mobile: 0772269575 <07722%2069575>* >>> >>> _______________________________________________ >>> Architecture mailing list >>> [email protected] >>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>> >>> >> >> >> -- >> Gruss / regards >> >> Jochen Traunecker >> mailto: [email protected] >> >> _______________________________________________ >> Architecture mailing list >> [email protected] >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > > > -- > Lakmal Warusawithana > Director - Cloud Architecture; WSO2 Inc. > Mobile : +94714289692 <+94%2071%20428%209692> > Blogs : https://medium.com/@lakwarus/ > http://lakmalsview.blogspot.com/ > > > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- Harsha Kumara Software Engineer, WSO2 Inc. Mobile: +94775505618 Blog:harshcreationz.blogspot.com
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
