Hi Sabeena,

On Thu, Nov 30, 2017 at 9:39 AM, Sabeena Kumrawadu <[email protected]> wrote:

> 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.
>

Do we use a custom parameter in the swagger file for this or are we using a
already defined one? Can you provide bit information on how it is set the
swagger 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
>>>>>> <https://maps.google.com/?q=20,+Palm+Grove,+Colombo+03,+Sri+Lanka&entry=gmail&source=g>
>>>>>> 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
>> <https://maps.google.com/?q=20,+Palm+Grove,+Colombo+03,+Sri+Lanka&entry=gmail&source=g>
>> 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
> <https://maps.google.com/?q=20,+Palm+Grove,+Colombo+03,+Sri+Lanka&entry=gmail&source=g>
> Mobile: +94 71 0372856 <+94%2071%20037%202856>
> Email: [email protected]
> [image: http://wso2.com/signature] <http://wso2.com/signature>
>
>


-- 
Regards,
Chamila Adhikarinayake
Senior Software Engineer
WSO2, Inc.
Mobile - +94712346437
Email  - [email protected]
Blog  -  http://helpfromadhi.blogspot.com/
_______________________________________________
Architecture mailing list
[email protected]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Reply via email to