HI Pubudu, 1. Who will be responsible for creating these labels? I guess, it should be created from Admin Portal and those labels should be propagated to store, publisher, gateway.
2. How do you restrict the users invoking from different gateway environments? Allowing to invoke from provided gateway environment. We can't validate from Key Manager since Key Manager can be anything which adheres OAuth 2 spec. They don't need to know anything related labels. 3. How do you map users to labels? Who will map the users? If an admin does this, on which basis labels will be assigned to users? 4. We can't let the users create label because it reflects the internal gateway deployment pattern. On Wed, Feb 8, 2017 at 5:03 AM, Ishara Cooray <isha...@wso2.com> wrote: > Hi Pubudu, > > What will be the behavior when an api is updated > > 1. From API publisher UI > 2. From the api artifact itself(if it is allowed). > > > Thanks & Regards, > Ishara Cooray > Senior Software Engineer > Mobile : +9477 262 9512 <+94%2077%20262%209512> > WSO2, Inc. | http://wso2.com/ > Lean . Enterprise . Middleware > > On Tue, Feb 7, 2017 at 10:49 PM, Nuwan Dias <nuw...@wso2.com> wrote: > >> Hi Matteo, >> >> To give you some context, this model is suggested for API Manager version >> 3.0.0 which will be on a new Carbon platform version, version 5. Its >> literarily a rewrite of the current API Manager product and hence we're >> rethinking and redesigning all features. >> >> What we're trying to achieve here is to give the ability for APIs to be >> deployed in separate zones. i.e. Internally accessible vs publicly >> accessible. How we supported this earlier was by making the API Publisher >> push APIs to Gateways in different zones when the APIs were being >> published. But deploying APIs in the API Publishing process had its own set >> of problems such as >> >> 1. When it was required to publish to many Gateway, the publishing >> process consumed a lot of time. >> 2. If the API deployment failed partially, we had to record the failures >> while still changing the state of the API. The API publishers had to later >> republish. >> 3. If a new zone is added later, the API publishers had to republish the >> APIs to the new zone. >> >> Most of these problems stemmed from the fact that we were using a "Push" >> model of APIs instead of a "Pull". The model suggested for API Manager >> 3.0.0 is a "Pull" model by which we try to achieve a lot of dynamicity and >> make the API Publishing process more robust at the same time. >> >> Thanks, >> NuwanD. >> >> On Tue, Feb 7, 2017 at 9:53 PM, Matteo Bordin <matteo.bor...@profesia.it> >> wrote: >> >>> Hello >>> why does not it be possible to use the feature “Environment”? >>> I mean the configuration into the api-manager.xml file >>> “<APIGateway> >>> <!-- The environments to which an API will be published --> >>> <Environments> >>> <!-- Environments can be of different types. Allowed values >>> are 'hybrid', 'production' and 'sandbox'. >>> An API deployed on a 'production' type gateway will >>> only support production keys >>> An API deployed on a 'sandbox' type gateway will only >>> support sandbox keys >>> An API deployed on a 'hybrid' type gateway will support >>> both production and sandbox keys. --> >>> <!-- api-console element specifies whether the environment >>> should be listed in API Console or not --> >>> <Environment type="hybrid" api-console="true"> >>> <Name>Production and Sandbox</Name> >>> <Description>This is a hybrid gateway that handles both >>> production and sandbox token traffic.</Description> >>> <!-- Server URL of the API gateway --> >>> <ServerURL>https://localhost:$ >>> {mgt.transport.https.port}${carbon.context}services/</ServerURL> >>> <!-- Admin username for the API gateway. --> >>> <Username>${admin.username}</Username> >>> <!-- Admin password for the API gateway.--> >>> <Password>${admin.password}</Password> >>> <!-- Endpoint URLs for the APIs hosted in this API >>> gateway.--> >>> <GatewayEndpoint>http://${carb >>> on.local.ip}:${http.nio.port},https://${carbon.local.ip}:${h >>> ttps.nio.port}</GatewayEndpoint> >>> </Environment> >>> </Environments> >>> </APIGateway> “ >>> >>> So we create more than one environment, one for each “label”, the >>> configuration could be: one api gateway manager for environment and any >>> number of gateway for manager. >>> When you deploy the API you can decide where you would like to deploy >>> your API, the publisher using the admin service publish the API into the >>> correct gateway, in the store you can see the url of the gateway where you >>> have deployed the API. >>> Probably I don not understand the requirements. >>> Could you provide us a real use case? >>> This is my two cents! >>> >>> bye >>> Matteo >>> >>> >>> Matteo Bordin >>> Profesia s.r.l. - http://www.profesia.it >>> via Po, 1 - 10124 Torino (TO) Tel +39 011 0120371 >>> <+39%20011%20012%200371> Fax +39 011 3710371 <+39%20011%20371%200371> >>> Piazzale Luigi Sturzo, 15 - 00144 Roma Tel +39 06 87811323 >>> <+39%2006%208781%201323> >>> Cell: +39 346 017 91 68 >>> Skype: matteobordin >>> eMail: matteo.bor...@profesia.it >>> — >>> “Profesia, innovation in action" >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> On 7 Feb 2017, at 15:01, Pubudu Gunatilaka <pubu...@wso2.com> wrote: >>> >>> Hi, >>> >>> There can be situations where we need to host public gateways for public >>> traffic as well as private gateways for internal traffic. In general, there >>> can be different gateway environments which serve particular APIs. The >>> publisher can decide which API should be served by which gateway >>> environment. >>> >>> The flow is as follows. >>> >>> <Labels based GWs.jpg> >>> >>> >>> 1. When creating an API, the publisher can decide the labels for an API. >>> Labels can be public, private, etc. Users can define labels based on their >>> use cases. Once the API is published, an event is published to the topic. >>> 2. Gateways are subscribed to the particular topics at the startup and >>> they will receive the API publishing event. Gateways are capable of loading >>> APIs on demand as well as able to load when API is published. Gateways >>> should be started with a label. For an example, the public gateway should >>> be started providing an argument at startup with label value public. This >>> is to identify the environment. >>> 3. When requesting a particular API from the publisher, the gateway >>> should provide the label value. The publisher will check the available >>> labels in the API and the gateway only receives the API only if there is a >>> match for the given label in the API. >>> 4. Key validation. >>> >>> In Store, there will be a REST API to get the label information which >>> contains the label name and the URL of the gateway. This is used to display >>> the gateway URLs in the API store. By default, it will display all the >>> available environments. There is an extension point which users can use to >>> restrict showing particular gateway endpoints based on the user who logs >>> into the API store. >>> >>> *Note: *These gateway environments are not same as having Dev , QA and >>> Prod environments of the API Manager deployment. Dev, QA, Prod environments >>> are called stages in API Manager from C5 onwards. In a particular stage, >>> there can be different gateway environments. >>> >>> Please share your thoughts. >>> >>> Thank you! >>> -- >>> *Pubudu Gunatilaka* >>> Committer and PMC Member - Apache Stratos >>> Software Engineer >>> WSO2, Inc.: http://wso2.com >>> mobile : +94774078049 <%2B94772207163> >>> >>> _______________________________________________ >>> Architecture mailing list >>> Architecture@wso2.org >>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>> >>> >>> >>> _______________________________________________ >>> Architecture mailing list >>> Architecture@wso2.org >>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>> >>> >> >> >> -- >> Nuwan Dias >> >> Software Architect - WSO2, Inc. http://wso2.com >> email : nuw...@wso2.com >> Phone : +94 777 775 729 <+94%2077%20777%205729> >> >> _______________________________________________ >> Architecture mailing list >> Architecture@wso2.org >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > > _______________________________________________ > Architecture mailing list > Architecture@wso2.org > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- Thanks Abimaran Kugathasan Senior Software Engineer - API Technologies Email : abima...@wso2.com Mobile : +94 773922820 <http://stackoverflow.com/users/515034> <http://lk.linkedin.com/in/abimaran> <http://www.lkabimaran.blogspot.com/> <https://github.com/abimarank> <https://twitter.com/abimaran>
_______________________________________________ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
