Hi all, WSO2 Offline Microgateway has been released with the WSO2 API-M8 release, and the documentation could be found here <https://docs.wso2.com/display/AM300/Micro+API+Gateway>.
As of the implementation, Microgateway requires only the API file, and its API keys. Here the API keys are being passed via the API Swagger JSON file. Each of the API keys, which are defined in the API Swagger file, is taken as a subscription. [image: Inline image 1] So now you need to provide both the API Swagger JSON file and the API Ballerina file of each API. In the above diagram the Local File Storage refers to the collection of such files plus the microConf.json file, which provides the Gateway configuration details. (In the M8 release, this file is provided by default.) These Gateway Configurations are passed to analytics and throttling functionalities. But as of the current implementation they are not yet enabled. The flow of the Microgateway is very similar to the normal WSO2 API Gateway flow, other than for the fact that in the Microgateway the caches are loaded using the API Swagger JSON files. As depicted in the diagram above, after the authentication process has completed successfully, the API Ballerina files are used to create a client connector to the actual API target. Thank you and Best Regards. On Thu, Aug 31, 2017 at 12:55 PM, Sabeena Kumrawadu <[email protected]> wrote: > Hi All, > > Updates on the offline micro-gateway > > -At the moment the carbon-apimgt does not support the JSON repo, as it is > using Ballerina 0.89. > this can be resolved as soon as the carbon-apimgt is upgraded to > Ballerina 0.93 > > -In the normal gateway initializing process, there require a lot of other > data for throttling & analytics. There for it is being dicussed to wirte a > seperate service for the micro gateway initializing. When this service is > being called the throttling and analytics handlers can be commented in the > deployment.yaml > (to avoid throttling and analytics.) > > -The repo will be identified by reading an environment variable, when the > offline gateway is inintializing. > > Would like to know about the suggestions on improving the design. > > Thank you, > Regards. > > On Tue, Aug 1, 2017 at 9:26 AM, Sanjeewa Malalgoda <[email protected]> > wrote: > >> >> >> On Tue, Aug 1, 2017 at 6:12 AM, Isuru Haththotuwa <[email protected]> >> wrote: >> >>> On Mon, Jul 31, 2017 at 2:51 PM, Sanjeewa Malalgoda <[email protected]> >>> wrote: >>> >>>> >>>> >>>> On Fri, Jul 28, 2017 at 1:12 PM, Sabeena Kumrawadu <[email protected]> >>>> wrote: >>>> >>>>> Hi all, >>>>> >>>>> APIM V3 supports micro API Gateway. With the micro API Gateway we are >>>>> supporting gateway to run offline mode. In a normal API Gateway, a call is >>>>> made to the APIM core at the gateway initialization time, to retrieve the >>>>> data, as depicted in the diagram below. >>>>> >>>>> [image: Screenshot from 2017-07-26 17-16-48.png] >>>>> >>>>> Also, normal API Gateway will call keymanager introspect call to >>>>> validate OAuth token which is hard to run as offline mode. >>>>> >>>>> >>>>> In the offline mode, the gateway maintains an API registry, where the >>>>> relevant information is loaded at the gateway startup, either from the >>>>> file >>>>> system or from an external APIM deployment (ex. API cloud). As the initial >>>>> phase of the project we are going to implement to load the gateway >>>>> from a local file system. The data here is stored as JSON objects, and are >>>>> kept in separate folders, as shown in the diagram below.The file system is >>>>> stored in a folder structure, where it contains subfolders for each of >>>>> keys, subscriptions, applications, endpoints etc. >>>>> >>>>> >>>>> >>>>> >>>>> [image: Screenshot from 2017-07-27 14-17-02.png] >>>>> Here we need to write a bootstrap script, which will initialize API >>>>> gateway from local file system or retrieve the data from the API cloud. In >>>>> this manner, the cache is loaded and the gateway totally relies on it, so >>>>> now the gateway itself has the capability to validate the access token. >>>>> Moreover the gateway will not call the APIM Core at the gateway >>>>> initialization time, or any other APIM component. The gateway will run as >>>>> a >>>>> standalone component. >>>>> >>>>> It is also planned to use a JWT as the next step of this >>>>> implementation, that is to allow the user to make a JWT-attached API call >>>>> to the gateway. Once the user sends the JWT with the API call, the gateway >>>>> should be able to authenticate the user, using the public key. >>>>> >>>> Supporting JWT based authentication/ user identification is first class >>>> feature and there is nothing to to do with offline gateways IMO. If we use >>>> API keys concept then authorized user will be available in validation >>>> information. >>>> >>> Once we have first class support for JWT token, we should be able to use >>> that instead of API keys for both authentication & authorization. AFAIU API >>> Keys can be used for user identification only. >>> >> Access token associated with user, application and subscription. So with >> access token we should be able to get all relevant details. Self contained >> token is also a good idea. >> >>> >>>>> >>>>> As with now, once the offline API gateway receives any API call, it >>>>> will be validated via the already existing file system as below. >>>>> >>>> We may not need file system here. API gateway have its own way of >>>> caching validation information and subscription data. If we can utilize >>>> same(with no expiry time) then we do not need additional layer. Then we >>>> will not need additional implementation for this. What off line mode need >>>> to do is simply feed cache. There can be edge cases where we have large >>>> number of entries which cause cache evictions. >>>> >>> AFAIU reading from file system/calling an external APIM deployment is >>> done to get the data to populate the cache. Hence, there should be an >>> additional layer (ex.: a handler/script) which will read the details from >>> either the file system/ via an API call at the startup. >>> >>>> >>>> Are we going to engage different set of handlers for offline gateways? >>>> Or modify same handlers to support gateway mode as well? >>>> >>> IMO we should try to use the same set of handler for the both modes, and >>> dynamically disengage the handlers based on a configuration at runtime. >>> Maintaining two sets of handlers might not scalable. >>> >> Yes its good if we can have same set of handlers which handles online >> offline gateway traffic. >> >> Thanks, >> sanjeewa. >> >>> >>>> Thanks, >>>> sanjeewa. >>>> >>>>> [image: Screenshot from 2017-07-27 17-09-15.png] >>>>> >>>>> >>>>> Note: >>>>> >>>>> - Throttling is not handled in the offline mode. >>>>> - While in the offline mode, the Gateway will not receive any >>>>> messages from the JMS topic, on API create/update. >>>>> >>>>> >>>>> Feedback on the improvement for the design is much appreciated. >>>>> >>>>> Thank you, >>>>> Best Regards. >>>>> >>>>> -- >>>>> *Sabeena Kumarawadu* | Software Engineering Intern >>>>> WSO2 Lanka (Pvt) Ltd. >>>>> #20, Palm Grove, Colombo 03, Sri Lanka >>>>> Mobile: +94 71 0372856 <071%20037%202856> >>>>> Email: [email protected] >>>>> [image: http://wso2.com/signature] <http://wso2.com/signature> >>>>> >>>>> >>>> >>>> >>>> -- >>>> >>>> *Sanjeewa Malalgoda* >>>> WSO2 Inc. >>>> Mobile : +94713068779 <071%20306%208779> >>>> >>>> <http://sanjeewamalalgoda.blogspot.com/>blog >>>> :http://sanjeewamalalgoda.blogspot.com/ >>>> <http://sanjeewamalalgoda.blogspot.com/> >>>> >>>> >>>> >>> >>> >>> -- >>> Thanks and Regards, >>> >>> Isuru H. >>> +94 716 358 048 <071%20635%208048>* <http://wso2.com/>* >>> >>> >>> >> >> >> -- >> >> *Sanjeewa Malalgoda* >> WSO2 Inc. >> Mobile : +94713068779 <+94%2071%20306%208779> >> >> <http://sanjeewamalalgoda.blogspot.com/>blog >> :http://sanjeewamalalgoda.blogspot.com/ >> <http://sanjeewamalalgoda.blogspot.com/> >> >> >> > > > -- > *Sabeena Kumarawadu* | Software Engineering Intern > WSO2 Lanka (Pvt) Ltd. > #20, Palm Grove, Colombo 03, Sri Lanka > Mobile: +94 71 0372856 <+94%2071%20037%202856> > Email: [email protected] > [image: http://wso2.com/signature] <http://wso2.com/signature> > > -- *Sabeena Kumarawadu* | Software Engineering Intern WSO2 Lanka (Pvt) Ltd. #20, Palm Grove, Colombo 03, Sri Lanka Mobile: +94 71 0372856 Email: [email protected] [image: http://wso2.com/signature] <http://wso2.com/signature>
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
