Hi Jochen, Please find the answers inline.
On Tue, Feb 14, 2017 at 1:52 PM, Jochen Traunecker < [email protected]> wrote: > 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. > C5 based API Manager will support only the pull based approach due to the drawbacks and feedbacks we received. Some of the drawbacks are mentioned above in the mailing thread. > > 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. > Yes, there will be no manager - worker concept in C5 for gateways. Every gateway node needs to pull the relevant API artifact from the publisher node. > > 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? > As we are going with the pull based approach, we need to have a notification mechanism for the gateway node to get the updates of APIs. Initial release will have the JMS based notification mechanism. Later releases will focus on plugging any other notification mechanisms. > 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. > Yes, API can have multiple labels. Also a gateway can have multiple labels. When requesting the APIs, gateway node will provide multiple labels and if the API is matched with the given labels, API can be retrieved. > 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? > If I rephrase the requirement, an API can have multiple backend enpoints for different runtimes. There is a plan to cover this aspect as well. > > Looking forward for your feedback. > > Thanks, > Jochen > > 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
