I feel this functionality will be required in many other places. Thus should be designed in a generalized manner.
The most obvious place I can think of right now is, AppFactory deploying applications into different environments. Same can be applicable for Carbon Apps as well. The generalized design should support: 1. N number of environments 2. Ability to mark default deployment environments 3. @ the point of publishing an API, a list of deployment environments will appear for selection Same pattern be extended in the APaaS world, where a given API can be published into multiple stores. We also need to critically analyze the model followed by deployment synchronizer as it is solving some what similar problem. On Wed, Jul 17, 2013 at 5:14 PM, Samisa Abeysinghe <[email protected]> wrote: > Is the design such that, if we want more than 2 environments, that can be > facilitated? > > > On Wed, Jul 17, 2013 at 3:02 PM, Nuwan Dias <[email protected]> wrote: > >> Hi, >> >> This is regarding supporting multiple environments (production/sandbox) >> for the API Gateway. Currently API Manager allows having two endpoints per >> API. These are the production and sandbox endpoints. Although the sandbox >> endpoint is supposed to be used for testing purposes, both production and >> sandbox traffic is handled through a single Gateway. This can cause the >> production Gateway be loaded with test traffic as well. >> >> This feature is to allow having two Gateway nodes (at least) for serving >> production and sandbox traffic separately. Following is how it is supposed >> to work. >> >> 1. When an API is published, it will be deployed on both the production >> and sandbox Gateway nodes. >> 2. The production Gateway will only serve production traffic and the >> sandbox Gateway will only serve sandbox traffic. >> 3. The Gateway will use the token type (production or sandbox) to >> identify requests being received. >> 4. The Token endpoint (/token) will remain same on both nodes. The token >> being generated will depend on the type of consumer-key/consumer-secret >> used. >> 5. Both Gateway nodes will share a single APIMGT database. This is where >> information related to APIs, Applications, Token, etc are stored. This will >> be the same database as used by the publisher/store nodes. >> >> Currently an xml template is used for generating an API configuration >> (synapse configuration). To allow the above mentioned feature to work, a >> separate xml template will have to be maintained for each endpoint type >> (production template and sandbox template). >> >> The api-manger.xml currently defines the location (url) of the Gateway. A >> similar configuration will be introduced to define the location of the >> sandbox Gateway. The API Store will display both endpoints accordingly. >> >> Thoughts/Suggestions welcome. >> >> Thanks, >> NuwanD. >> >> -- >> Nuwan Dias >> >> Senior Software Engineer - WSO2, Inc. http://wso2.com >> email : [email protected] >> Phone : +94 777 775 729 >> >> _______________________________________________ >> Architecture mailing list >> [email protected] >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > > > -- > > Thanks, > Samisa... > > Samisa Abeysinghe > VP Engineering > WSO2 Inc. > http://wso2.com > http://wso2.org > > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- /sumedha b : bit.ly/sumedha
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
