On Mon, May 28, 2018 at 5:57 PM Rajith Roshan <[email protected]> wrote:

> I think we have to decide whether we are going to allow users to edit
> generated bal files. If so then they can write some custom logic and
> generate the balx files. If we are not allowing them to edit bal files then
> micro gw will be only pass through with some filters.
>

I thought we already in agreement of shipping  only proxy capability in
this release.


> On Mon, May 28, 2018 at 5:30 PM Isuru Haththotuwa <[email protected]> wrote:
>
>>
>>
>> On Mon, May 28, 2018 at 5:03 PM, Sanjeewa Malalgoda <[email protected]>
>> wrote:
>>
>>>
>>>
>>> On Mon, May 28, 2018 at 3:23 PM, Harsha Kumara <[email protected]> wrote:
>>>
>>>> Hi All,
>>>>
>>>> We are working on releasing a ballerina based micro gateway with APIM
>>>> 2.5.0. We are providing are Cli Tool which allow users to generate
>>>> ballerina executables and runtime archives based on provided 
>>>> configurations.
>>>>
>>>> High Level Architecture
>>>> [image: image.png]
>>>>
>>>> *Micro gateway distribution structure*
>>>>
>>>> micro-gw
>>>>     ├── bin
>>>>     │   ├── micro-gw.bat
>>>>     │   └── micro-gw.sh
>>>>     ├── lib
>>>>     │   └── ballerina-0.970.0
>>>>     ├── temp
>>>>     │   └── path.txt
>>>>     └── templates
>>>>         ├── api.mustache
>>>>         ├── config.mustache
>>>>         └── gateway_config.mustache
>>>>         └── policy_template.mustache
>>>>
>>>>
>>>> *Core Cli Commands*
>>>>
>>>>    - *micro-gw setup/init (with inputs username, label name and
>>>>    password(*optional
>>>> *)) *
>>>>       - This command will create basic project structure. Initially
>>>>       consumer key and secret will be generated by taking user inputs and
>>>>       retrieve the api definitions of given label type in the argument. If 
>>>> user
>>>>       provides new label, there will be new directory structure for that 
>>>> label
>>>>       will be created under projects directory.
>>>>       - *projects* directory contains directories for each label and
>>>>       ballerina source file will be created for each API under particular 
>>>> label
>>>>       - *config.yaml* contains configurations related to publisher,
>>>>       key manager connections, consumer key and secret which are common 
>>>> across
>>>>       all labels
>>>>       - *gateway_config.yaml* contains configurations specific to
>>>>       labels such as docker/kubernetes
>>>>
>>>> Shouldn't we provide  publisher URL along with this command? If
>>> publisher is hosted server and micro gateway runs within local machine then
>>> we may need to point to that publisher(something similar to current micro
>>> gateway scenario).
>>>
>> The init/setup command will only create the project structure.
>> Communicating with the Publisher, pulling the API definition and building
>> the corresponding .balx file & the runnable distribution happens with the
>> build command.
>>
>>>
>>>>
>>>> *           Generated Project Structure*
>>>>
>>>> micro-gw-resources
>>>>
>>>>     ├── conf
>>>>
>>>>     │   └── config.yaml
>>>>
>>>>     └── projects (folder name is same as label name)
>>>>
>>>>         ├── accounts
>>>>
>>>>         │   ├── src
>>>>
>>>>         │   │   ├── companyAccounts_v1.0.0.bal
>>>>
>>>>         │   │   └── salesforce_v1.0.0.bal
>>>>
>>>>         │   └── target
>>>>
>>>>         │       ├── accounts.balx
>>>>
>>>>         │       └── accounts.zip
>>>>
>>>>         ├── finance
>>>>
>>>>         │   ├── src
>>>>
>>>>         │   │   ├── invoices_v2.0.0.bal
>>>>
>>>>         │   │   └── payments_v2.1.0.bal
>>>>
>>>>         │   └── target
>>>>
>>>>         │       ├── finance.balx
>>>>
>>>>         │       └── finance.zip
>>>>
>>>>         ├── gateway-config
>>>>
>>>>         │   └── gateway-config.yaml
>>>>
>>>>         └── sales
>>>>
>>>>             ├── src
>>>>
>>>>             │   ├── customers_v3.0.0.bal
>>>>
>>>>             │   └── leads_v4.0.0.bal
>>>>
>>>>             └── target
>>>>
>>>>                 ├── sales.balx
>>>>
>>>>                 └── sales.zip
>>>>
>>>> I think we can directly point this directory to composer and implement
>>> some custom mediation logic there. In case synapse API have its own
>>> mediation sequence which we cannot directly translate to ballerina.
>>>
>> This would be a limitation. Running any custom mediation sequences in the
>> micro gw will not be supported.
>>
>>>
>>>>    - *micro-gw build (with inputs label name)*
>>>>       - This command build single balx out of all APIs belongs to
>>>>       given label. If docker/kubernetes configurations specified, then
>>>>       archive will be generated. This archive will embeds bre, generated 
>>>> balx
>>>>       which someone can take and run without configuring anything.
>>>>       - This command also outputs APIs which have updated and commands
>>>>       which are available to run in target folder
>>>>    - *micro-gw run (with label name)*
>>>>       - This command will use to run the balx generated for given
>>>>       label.
>>>>
>>>> Please share your suggestions and improvements.
>>>>
>>>>
>>>> Thanks,
>>>> Harsha
>>>> --
>>>> Harsha Kumara
>>>> Associate Technical Lead, WSO2 Inc.
>>>> Mobile: +94775505618
>>>> Blog:harshcreationz.blogspot.com
>>>>
>>>
>>>
>>>
>>> --
>>> *Sanjeewa Malalgoda*
>>> WSO2 Inc.
>>> Mobile : +94 712933253
>>>
>>> <http://sanjeewamalalgoda.blogspot.com/>blog
>>> :http://sanjeewamalalgoda.blogspot.com/
>>> <http://sanjeewamalalgoda.blogspot.com/>
>>>
>>>
>>>
>>
>>
>> --
>> Thanks and Regards,
>>
>> Isuru H.
>> +94 716 358 048* <http://wso2.com/>*
>>
>>
>>
>
> --
> Rajith Roshan
> Senior Software Engineer, WSO2 Inc.
> Mobile: +94-717-064-214
>
-- 
Sent from Gmail Mobile
_______________________________________________
Architecture mailing list
[email protected]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Reply via email to