Hi all, I’m wondering about a few fundamental concepts of C5 based API-Manager and the planned pull approach of deployment of APIs.
Topic 1 Will upcoming API-Manager based on C5 support both concepts: Concept A Publisher is aware of Gateway(s) / Clusters of Gateways / Gateway Environments. Gateways still will pull APIs, getting triggered by Publisher (JMS Backchannel) but this is hidden from the users of Publisher. Users still “push” APIs to the Gateway(s), although technically it is the other way around. Users of APIs will get all information about endpoints of APIs in each environment from API-Publisher and they will get informed about API-Publisher about the publishing state (maybe a intermediate state is necessary ‘marked to get published” and ‘successfully published to gateways’). Concept B Publisher is not aware of Gateway(s) at all and just serves API-Definitions, API-Policies and so on. Gateways will pull APIs, maybe still subscribe to a topic of Publisher to get triggered, but it will be totally up to the API-Runtime to manage endpoints and share endpoint information with clients. All concepts are valid use cases and there are environments where all concepts will be in place in parallel. TOPIC 2 Cluster of Gateways: is it planned that each individual member of cluster of Gateways will pull the APIs from Publisher or will there be some manager - worker concept in place where just the manager pulls and triggers the deployment within the cluster? As far as I followed this discussion, there will be no manager - worker concept anymore. TOPIC 3 Pulling APIs and JMS : Will it be mandatory to establish a JMS connection between Gateway(s) and Publisher? Or is this an optional feature? Do you have plans to use some messaging protocol that can be used over Websockets ? There are setups, where native JMS connections are not possible at all due to networking policies. Will it be possible to define some periodic timer (or whatever trigger) in Gateway to pull APIs without establishing a JMS / Messaging relationship to Publisher? TOPIC 4 Labels and Selectors: Can an API have more than one Label assigned? Can a Gateway ask for APIs using more than one Label? This would end in a n x m relationship which some setups might ask for. TOPIC 5 Abstract APIs / Templates: There are use cases where one API can get deployed into several API-Runtimes (not related to stages). Endpoints of an API are runtime specific (both of them: how to invoke the API as a client and endpoint of to be invoked service). There are planned setups in complex organisations where a centralised API-Management (Store, Publisher and Repository) will manage potentially a lot of API-Runtimes. In each API-Runtime there will be a common set of APIs like services for master data lookup and so on. Each of these common APIs will have its very own endpoint in each API-Runtime (both endpoints, endpoint of the API and the backend service endpoint), but the API by itself is considered to be the “same” across all Runtimes. Will this use case be covered at all as it has some impact on deployment of APIs? Looking forward for your feedback. Thanks, Jochen On 9 February 2017 at 07:24:38, Pubudu Gunatilaka ([email protected]) wrote: Hi, Please find the answers inline. On Thu, Feb 9, 2017 at 11:18 AM, Shani Ranasinghe <[email protected]> wrote: > > > On Thu, Feb 9, 2017 at 11:08 AM, Rukshan Premathunga <[email protected]> > wrote: > >> Hi all, >> >> Another confusion scenario is some GW nodes are get register and again >> could be down. The another GW will register with same label and diffrent >> URL. In this case are we allowed to update existing level-GW_url or >> disallow to register that GW? >> >> Also if existing GW url is changed how we gonna edit the label? Since we >> have not provide label editing UI feature, we should update the label info >> that are reading from configuration. >> >> If you consider a production deployment, most of the time (always) gateways will be fronted with a load balancer. Basically url of the gateway will be the hostname which points to the load balancer. As long as we keep this hostname of the load balancer unchange, behavior of the gateways does not matter. But changing the URL of an exisiting label could be useful if there is a change. May be we can provide a system parameter called 'overwrite_labels' to overwrite the URL of the gateways. By going forward, there will be no any configuration file for configuring labels. This make sure that we are not binded to a configuration file and allowing users to add any label by starting up a new gateway node. > Thanks and Regards >> >> On Wed, Feb 8, 2017 at 6:03 PM, Pubudu Gunatilaka <[email protected]> >> wrote: >> >>> Hi Shani, >>> >>> Initially, you cannot update or delete a particular label. But you can >>> add a new label by starting up a new gateway with a new label. Then if you >>> need to change the particular label in an API, you need to update that API. >>> >>> So in that case, there would be a sorting based on the label on the > publisher side? would there be an update all also? Another thing, what if > a label is not given at start up for the gateway? does that mean that > gateway will serve all API's? > For the initial implementation we haven't thought of having sorting based on the label and update all feature. In the future we will add these features. We are not mandating the providing a label at API creation stage. There will be default label which will assign if there aren't any label selection. Basically, default label will provide to the gateway node and if you haven't change that label value, default gateway will be served the API requests which have default label in the API. If there isn't any label given at startup of the gateway, that gateway will not serve any API. By doing this we enforce the gateway node to have at least the default label value. Thank you! -- *Pubudu Gunatilaka* Committer and PMC Member - Apache Stratos Software Engineer WSO2, Inc.: http://wso2.com mobile : +94774078049 <%2B94772207163> _______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
