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
