When we load subscriptions at server startup we should be able to configure it IMO.
- Some users may need to have faster startup - fully automated containerized deployments faster startup is critical. - Others may need fast first response - For normal scale out users usually do not care about startup delay. To support both of them lets make startup part configurable like discussed here. Thanks, sanjeewa. On Thu, Jan 12, 2017 at 8:48 PM, Bhathiya Jayasekara <[email protected]> wrote: > Hi Hasitha, > > On Thu, Jan 12, 2017 at 5:55 PM, Hasitha Hiranya <[email protected]> > wrote: > >> Hi, >> >> >> >> On Thu, Jan 12, 2017 at 5:12 PM, Nuwan Dias <[email protected]> wrote: >> >>> >>> >>> On Wed, Jan 11, 2017 at 6:40 PM, Bhathiya Jayasekara <[email protected]> >>> wrote: >>> >>>> Hi all, >>>> >>>> Up to APIM 2.x.x (C4 implementation), APIM had its own key management >>>> component, and subscription validation was done by that component when a >>>> token validation request is received to the keymanager. But with C5 >>>> implementation, a vanilla Identity Server will be acting as the keymanager. >>>> Because of that, we can't do subscription validation at keymanger anymore. >>>> >>>> >>>> Therefore, with C5, the plan is to do the subscription validation at >>>> gateway itself. But, since gateways don't have direct access to the >>>> database (as it should be able to run in DMZ), we should have a way to get >>>> subscription data to gateway nodes. Here is the suggested design. >>>> >>>> Gateways can receive subscription data in 2 ways. >>>> >>>> 1) Load all subscription data at server startup >>>> >>>> For this, APIM Core component will have a service to return all >>>> subscriptions of all APIs. >>>> >>> >> Does this mean after startup, if a subscription is done it is not >> notified to the gareway? >> > > No, new subscriptions are notified through a JMS topic. > > >> Should all subscriptions synced to all GW nodes, or subscriptions are >> distributed between the nodes? >> > > All gateways should subscribe to the topic. There will be no syncing > between gateway nodes. > > >> >> >>> >>> I think this API should accept the number of Subs to load on startup. In >>> the initial version we will support 0 and all only. 0 being the default >>> (which means we load Subs on demand). Moving forward we can enhance this by >>> using different policies such as 'most recent', 'most used', etc. >>> >>>> >>>> 2) Load subscription data on-demand depending on the API requests it >>>> receives. >>>> >>>> For this, APIM Core component will have a service to return >>>> subscriptions of a given API. >>>> >>> >> This can introduce some latency to the first request to fetch the >> subscriptions. I guess the delay is fine if it is in an acceptable range. >> > > Yes, we need to measure it and optimize. > > >> >> >>> >>>> In either case, gateways store received subscription data in an >>>> in-memory data structure. Therefore, gateways should receive subscription >>>> updates (new subscriptions/unsubscribe notifications etc.) too. We are >>>> planning to do this using a JMS topic. (This will not be limited to JMS and >>>> will be configurable later.) When there are any updates to subscriptions, >>>> APIM Core component will add that information to a topic, to which gateways >>>> are subscribed to. Then gateways can update their subscription data which >>>> they have stored in memory. >>>> >>>> This means all the GW nodes should be able to open AMQP(JMS) >> connections from them thro DMZ. We should use JMS over SSL? >> > > I'm not sure if SSL can help here. However, we may need it if there are > any security concerns. > > Thanks, > Bhathiya > > >> >> >>> Then we will have a handler at the gateway (most probably the Key >>>> validation handler itself) to use stored subscription data to validate >>>> subscriptions of incoming requests. >>>> >>>> >>>> Note: The subscription data received by the gateway from APIM core will >>>> contain certain API and Application related information as well. The reason >>>> is that we have decided to generate JWT tokens at gateway nodes. So we need >>>> those data to include in the JWT. >>>> >>>> Thanks, >>>> -- >>>> *Bhathiya Jayasekara* >>>> *Senior Software Engineer,* >>>> *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/>* >>>> >>> >>> >>> >>> -- >>> Nuwan Dias >>> >>> Software Architect - WSO2, Inc. http://wso2.com >>> email : [email protected] >>> Phone : +94 777 775 729 <077%20777%205729> >>> >>> _______________________________________________ >>> Architecture mailing list >>> [email protected] >>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>> >>> >> >> >> -- >> *Hasitha Abeykoon* >> Senior Software Engineer; WSO2, Inc.; http://wso2.com >> *cell:* *+94 719363063* >> *blog: **abeykoon.blogspot.com* <http://abeykoon.blogspot.com> >> >> > > > -- > *Bhathiya Jayasekara* > *Senior Software Engineer,* > *WSO2 inc., http://wso2.com <http://wso2.com>* > > *Phone: +94715478185 <071%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 > > -- *Sanjeewa Malalgoda* WSO2 Inc. Mobile : +94713068779 <http://sanjeewamalalgoda.blogspot.com/>blog :http://sanjeewamalalgoda.blogspot.com/ <http://sanjeewamalalgoda.blogspot.com/>
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
