Re: [Dev] [APIM][C5] - Handling API's gateway label updates

[Lakmal Warusawithana]

On Fri, Jun 23, 2017 at 2:47 PM Nuwan Dias  wrote:

> I don't think we need to handle the situation of a Gateway changing its
> labels. That is an extremely unlikely use case and writing complex code to
> handle that situation is going to be a waste. If someone wants to change a
> label of the Gateway we can simply ask them to remove all APIs and start it
> as a fresh Gateway. This will make sure that it pulls all the relevant APIs
> only on startup.
>

+1, no need to handle this. They can start new gateway with new label, and
destroy previous one, if need.


> On Fri, Jun 23, 2017 at 2:40 PM, Harsha Kumara  wrote:
>
>> @Tharindu, will gateway change the labels? If a gateway changes the label
>> and starts it we are calling to core API to get the available APIs list for
>> that particular gateway. In order to handle the label change, we
>> can undeploy the APIs which are not under returned list of APIs.
>>
>> On Fri, Jun 23, 2017 at 2:06 PM, Tharindu Dharmarathna <
>> tharin...@wso2.com> wrote:
>>
>>> As offline discussion with Lakmal, We are not going to register gateway
>>> labels and access URLs on the apim core by Gateway startup.  And labels are
>>> managed by the admin can assign permissions to those labels to make who can
>>> see this labels. Then Gateway will only start with the predefined label.
>>>
>>> When Gateway gets to start it retrieve APIs according to label assigned.
>>> @All,
>>> How do we going to handle the already created APIs under the Gateway?
>>>
>>> In VM scenario if set of API artifacts (ballerina files) created under
>>> the gateway.
>>> Then Gateway started with the different label. We have a way to get a
>>> list of ballerina artifacts under file system and do the check for those
>>> its validity for that label.
>>>
>>> How do we going to handle above requirement from the file system?
>>>
>>> On Wed, Jun 21, 2017 at 7:24 AM, Isuru Haththotuwa 
>>> wrote:
>>>


 On Tue, Jun 20, 2017 at 8:29 PM, Nuwan Dias  wrote:

> I'm not in favor of using special headers or anything like that. What
> if we just send all API updates to all Gateways? Each Gateway upon
> receiving this event will request for the particular API from the Core. 
> The
> Core will only give that API to the Gateway if the Gateway's labels 
> matches
> that of the requesting Gateway. If it does not, the core will refuse to
> give the API to the Gateway and in that case if the Gateway already has
> that API deployed it should go and remove it from itself (same code that
> runs in case of an API delete event).
>
 This header based filtering is actually a useful feature in the general
 case IMO; sometimes we need events to be processed by specific clients
 (gateways), in other cases we might need to do a multicast for all clients.
 In such situations we can stop the payload being processed unnecessarily.
 If we have to process all such events at all gateways, it might leads to
 scalability issues specially in container based deployments.

>
> Thanks,
> NuwanD.
>
> On Tue, Jun 20, 2017 at 3:24 PM, Harsha Kumara 
> wrote:
>
>>
>>
>> On Tue, Jun 20, 2017 at 11:39 AM, Thilini Shanika 
>> wrote:
>>
>>> Hi All,
>>>
>>> As per the APIM C5 architecture, the gateways can be registered in
>>> APIM Core, specifying it's label and accessURLs. When creating/updating
>>> APIs, the API can be moved to a gateway by assigning the label of the
>>> gateway which registered under APIM Core. Once a label is assigned to an
>>> API, that particular API will be deployed and available to the
>>> gateway/gateways represented by the given label/labels.
>>>
>>> Basically, all the API related actions(API
>>> create/update/delete/status change) are published to JMS topic along 
>>> with
>>> label information. The gateways are responsible for listening to the 
>>> topic,
>>> capture events which are relevant and process them. Ideally, gateways
>>> should filter the events based on API label and only process the events
>>> generated for APIs which are assigned with their gateway labels and 
>>> rest of
>>> the events should be ignored.
>>>
>>> But when it comes to label update, the gateways should behave
>>> differently, due to the scenarios explained before. Though API label 
>>> update
>>> is populated as an API update event, some of the gateways have to 
>>> process
>>> this API updates differently(May be as an API create or may be as an API
>>> delete)
>>>
>>>- Moving API to a new gateway: When a new gateway label is
>>>assigned to an API, the event generated for the gateways with newly 
>>> added
>>>label/labels is an API create event and the API should be deployed 

Re: [Dev] [APIM][C5] - Handling API's gateway label updates

[Nuwan Dias]

I don't think we need to handle the situation of a Gateway changing its
labels. That is an extremely unlikely use case and writing complex code to
handle that situation is going to be a waste. If someone wants to change a
label of the Gateway we can simply ask them to remove all APIs and start it
as a fresh Gateway. This will make sure that it pulls all the relevant APIs
only on startup.

On Fri, Jun 23, 2017 at 2:40 PM, Harsha Kumara  wrote:

> @Tharindu, will gateway change the labels? If a gateway changes the label
> and starts it we are calling to core API to get the available APIs list for
> that particular gateway. In order to handle the label change, we
> can undeploy the APIs which are not under returned list of APIs.
>
> On Fri, Jun 23, 2017 at 2:06 PM, Tharindu Dharmarathna  > wrote:
>
>> As offline discussion with Lakmal, We are not going to register gateway
>> labels and access URLs on the apim core by Gateway startup.  And labels are
>> managed by the admin can assign permissions to those labels to make who can
>> see this labels. Then Gateway will only start with the predefined label.
>>
>> When Gateway gets to start it retrieve APIs according to label assigned.
>> @All,
>> How do we going to handle the already created APIs under the Gateway?
>>
>> In VM scenario if set of API artifacts (ballerina files) created under
>> the gateway.
>> Then Gateway started with the different label. We have a way to get a
>> list of ballerina artifacts under file system and do the check for those
>> its validity for that label.
>>
>> How do we going to handle above requirement from the file system?
>>
>> On Wed, Jun 21, 2017 at 7:24 AM, Isuru Haththotuwa 
>> wrote:
>>
>>>
>>>
>>> On Tue, Jun 20, 2017 at 8:29 PM, Nuwan Dias  wrote:
>>>
 I'm not in favor of using special headers or anything like that. What
 if we just send all API updates to all Gateways? Each Gateway upon
 receiving this event will request for the particular API from the Core. The
 Core will only give that API to the Gateway if the Gateway's labels matches
 that of the requesting Gateway. If it does not, the core will refuse to
 give the API to the Gateway and in that case if the Gateway already has
 that API deployed it should go and remove it from itself (same code that
 runs in case of an API delete event).

>>> This header based filtering is actually a useful feature in the general
>>> case IMO; sometimes we need events to be processed by specific clients
>>> (gateways), in other cases we might need to do a multicast for all clients.
>>> In such situations we can stop the payload being processed unnecessarily.
>>> If we have to process all such events at all gateways, it might leads to
>>> scalability issues specially in container based deployments.
>>>

 Thanks,
 NuwanD.

 On Tue, Jun 20, 2017 at 3:24 PM, Harsha Kumara 
 wrote:

>
>
> On Tue, Jun 20, 2017 at 11:39 AM, Thilini Shanika 
> wrote:
>
>> Hi All,
>>
>> As per the APIM C5 architecture, the gateways can be registered in
>> APIM Core, specifying it's label and accessURLs. When creating/updating
>> APIs, the API can be moved to a gateway by assigning the label of the
>> gateway which registered under APIM Core. Once a label is assigned to an
>> API, that particular API will be deployed and available to the
>> gateway/gateways represented by the given label/labels.
>>
>> Basically, all the API related actions(API
>> create/update/delete/status change) are published to JMS topic along with
>> label information. The gateways are responsible for listening to the 
>> topic,
>> capture events which are relevant and process them. Ideally, gateways
>> should filter the events based on API label and only process the events
>> generated for APIs which are assigned with their gateway labels and rest 
>> of
>> the events should be ignored.
>>
>> But when it comes to label update, the gateways should behave
>> differently, due to the scenarios explained before. Though API label 
>> update
>> is populated as an API update event, some of the gateways have to process
>> this API updates differently(May be as an API create or may be as an API
>> delete)
>>
>>- Moving API to a new gateway: When a new gateway label is
>>assigned to an API, the event generated for the gateways with newly 
>> added
>>label/labels is an API create event and the API should be deployed to 
>> the
>>gateway/gateway with newly added label/labels.
>>- Remove API from a gateway: When a label is removed from an API,
>>the event generated to the gateway with the removed label is an API 
>> delete
>>event and API should be undeployed from that gateway.
>>
>> We 

Re: [Dev] [APIM][C5] - Handling API's gateway label updates

[Harsha Kumara]

@Tharindu, will gateway change the labels? If a gateway changes the label
and starts it we are calling to core API to get the available APIs list for
that particular gateway. In order to handle the label change, we
can undeploy the APIs which are not under returned list of APIs.

On Fri, Jun 23, 2017 at 2:06 PM, Tharindu Dharmarathna 
wrote:

> As offline discussion with Lakmal, We are not going to register gateway
> labels and access URLs on the apim core by Gateway startup.  And labels are
> managed by the admin can assign permissions to those labels to make who can
> see this labels. Then Gateway will only start with the predefined label.
>
> When Gateway gets to start it retrieve APIs according to label assigned.
> @All,
> How do we going to handle the already created APIs under the Gateway?
>
> In VM scenario if set of API artifacts (ballerina files) created under the
> gateway.
> Then Gateway started with the different label. We have a way to get a list
> of ballerina artifacts under file system and do the check for those its
> validity for that label.
>
> How do we going to handle above requirement from the file system?
>
> On Wed, Jun 21, 2017 at 7:24 AM, Isuru Haththotuwa 
> wrote:
>
>>
>>
>> On Tue, Jun 20, 2017 at 8:29 PM, Nuwan Dias  wrote:
>>
>>> I'm not in favor of using special headers or anything like that. What if
>>> we just send all API updates to all Gateways? Each Gateway upon receiving
>>> this event will request for the particular API from the Core. The Core will
>>> only give that API to the Gateway if the Gateway's labels matches that of
>>> the requesting Gateway. If it does not, the core will refuse to give the
>>> API to the Gateway and in that case if the Gateway already has that API
>>> deployed it should go and remove it from itself (same code that runs in
>>> case of an API delete event).
>>>
>> This header based filtering is actually a useful feature in the general
>> case IMO; sometimes we need events to be processed by specific clients
>> (gateways), in other cases we might need to do a multicast for all clients.
>> In such situations we can stop the payload being processed unnecessarily.
>> If we have to process all such events at all gateways, it might leads to
>> scalability issues specially in container based deployments.
>>
>>>
>>> Thanks,
>>> NuwanD.
>>>
>>> On Tue, Jun 20, 2017 at 3:24 PM, Harsha Kumara  wrote:
>>>


 On Tue, Jun 20, 2017 at 11:39 AM, Thilini Shanika 
 wrote:

> Hi All,
>
> As per the APIM C5 architecture, the gateways can be registered in
> APIM Core, specifying it's label and accessURLs. When creating/updating
> APIs, the API can be moved to a gateway by assigning the label of the
> gateway which registered under APIM Core. Once a label is assigned to an
> API, that particular API will be deployed and available to the
> gateway/gateways represented by the given label/labels.
>
> Basically, all the API related actions(API create/update/delete/status
> change) are published to JMS topic along with label information. The
> gateways are responsible for listening to the topic, capture events which
> are relevant and process them. Ideally, gateways should filter the events
> based on API label and only process the events generated for APIs which 
> are
> assigned with their gateway labels and rest of the events should be
> ignored.
>
> But when it comes to label update, the gateways should behave
> differently, due to the scenarios explained before. Though API label 
> update
> is populated as an API update event, some of the gateways have to process
> this API updates differently(May be as an API create or may be as an API
> delete)
>
>- Moving API to a new gateway: When a new gateway label is
>assigned to an API, the event generated for the gateways with newly 
> added
>label/labels is an API create event and the API should be deployed to 
> the
>gateway/gateway with newly added label/labels.
>- Remove API from a gateway: When a label is removed from an API,
>the event generated to the gateway with the removed label is an API 
> delete
>event and API should be undeployed from that gateway.
>
> We came up with few solutions in order to handle label related API
> update events.
>
>- Introducing a new event on API label update:
>
>During an API update, we need to identify whether there is
> a label change and populate a label update event with label change details
> (ie: newly added label/previous labels).  The gateways can read the label
> change information and decide whether it is relevant to process the event
> and perform API deploy/undeploy actions accordingly.
>
>- Introducing a header/property to 

Re: [Dev] [APIM][C5] - Handling API's gateway label updates

[Tharindu Dharmarathna]

As offline discussion with Lakmal, We are not going to register gateway
labels and access URLs on the apim core by Gateway startup.  And labels are
managed by the admin can assign permissions to those labels to make who can
see this labels. Then Gateway will only start with the predefined label.

When Gateway gets to start it retrieve APIs according to label assigned.
@All,
How do we going to handle the already created APIs under the Gateway?

In VM scenario if set of API artifacts (ballerina files) created under the
gateway.
Then Gateway started with the different label. We have a way to get a list
of ballerina artifacts under file system and do the check for those its
validity for that label.

How do we going to handle above requirement from the file system?

On Wed, Jun 21, 2017 at 7:24 AM, Isuru Haththotuwa  wrote:

>
>
> On Tue, Jun 20, 2017 at 8:29 PM, Nuwan Dias  wrote:
>
>> I'm not in favor of using special headers or anything like that. What if
>> we just send all API updates to all Gateways? Each Gateway upon receiving
>> this event will request for the particular API from the Core. The Core will
>> only give that API to the Gateway if the Gateway's labels matches that of
>> the requesting Gateway. If it does not, the core will refuse to give the
>> API to the Gateway and in that case if the Gateway already has that API
>> deployed it should go and remove it from itself (same code that runs in
>> case of an API delete event).
>>
> This header based filtering is actually a useful feature in the general
> case IMO; sometimes we need events to be processed by specific clients
> (gateways), in other cases we might need to do a multicast for all clients.
> In such situations we can stop the payload being processed unnecessarily.
> If we have to process all such events at all gateways, it might leads to
> scalability issues specially in container based deployments.
>
>>
>> Thanks,
>> NuwanD.
>>
>> On Tue, Jun 20, 2017 at 3:24 PM, Harsha Kumara  wrote:
>>
>>>
>>>
>>> On Tue, Jun 20, 2017 at 11:39 AM, Thilini Shanika 
>>> wrote:
>>>
 Hi All,

 As per the APIM C5 architecture, the gateways can be registered in APIM
 Core, specifying it's label and accessURLs. When creating/updating APIs,
 the API can be moved to a gateway by assigning the label of the gateway
 which registered under APIM Core. Once a label is assigned to an API, that
 particular API will be deployed and available to the gateway/gateways
 represented by the given label/labels.

 Basically, all the API related actions(API create/update/delete/status
 change) are published to JMS topic along with label information. The
 gateways are responsible for listening to the topic, capture events which
 are relevant and process them. Ideally, gateways should filter the events
 based on API label and only process the events generated for APIs which are
 assigned with their gateway labels and rest of the events should be
 ignored.

 But when it comes to label update, the gateways should behave
 differently, due to the scenarios explained before. Though API label update
 is populated as an API update event, some of the gateways have to process
 this API updates differently(May be as an API create or may be as an API
 delete)

- Moving API to a new gateway: When a new gateway label is assigned
to an API, the event generated for the gateways with newly added
label/labels is an API create event and the API should be deployed to 
 the
gateway/gateway with newly added label/labels.
- Remove API from a gateway: When a label is removed from an API,
the event generated to the gateway with the removed label is an API 
 delete
event and API should be undeployed from that gateway.

 We came up with few solutions in order to handle label related API
 update events.

- Introducing a new event on API label update:

During an API update, we need to identify whether there is a
 label change and populate a label update event with label change details
 (ie: newly added label/previous labels).  The gateways can read the label
 change information and decide whether it is relevant to process the event
 and perform API deploy/undeploy actions accordingly.

- Introducing a header/property to force every API gateway to
process an label update related event:

 If there is a label update, a property is set to JMS event
 so that every gateway should process the events generated with that
 particular property. Ideally, the gateways process API events
 generated with its own gateway label, but in this case, they have to
 process the event if it comes with this property.

>>> +1 for the approach as we can handle through the API update event. 

Re: [Dev] [APIM][C5] - Handling API's gateway label updates

[Isuru Haththotuwa]

On Tue, Jun 20, 2017 at 8:29 PM, Nuwan Dias  wrote:

> I'm not in favor of using special headers or anything like that. What if
> we just send all API updates to all Gateways? Each Gateway upon receiving
> this event will request for the particular API from the Core. The Core will
> only give that API to the Gateway if the Gateway's labels matches that of
> the requesting Gateway. If it does not, the core will refuse to give the
> API to the Gateway and in that case if the Gateway already has that API
> deployed it should go and remove it from itself (same code that runs in
> case of an API delete event).
>
This header based filtering is actually a useful feature in the general
case IMO; sometimes we need events to be processed by specific clients
(gateways), in other cases we might need to do a multicast for all clients.
In such situations we can stop the payload being processed unnecessarily.
If we have to process all such events at all gateways, it might leads to
scalability issues specially in container based deployments.

>
> Thanks,
> NuwanD.
>
> On Tue, Jun 20, 2017 at 3:24 PM, Harsha Kumara  wrote:
>
>>
>>
>> On Tue, Jun 20, 2017 at 11:39 AM, Thilini Shanika 
>> wrote:
>>
>>> Hi All,
>>>
>>> As per the APIM C5 architecture, the gateways can be registered in APIM
>>> Core, specifying it's label and accessURLs. When creating/updating APIs,
>>> the API can be moved to a gateway by assigning the label of the gateway
>>> which registered under APIM Core. Once a label is assigned to an API, that
>>> particular API will be deployed and available to the gateway/gateways
>>> represented by the given label/labels.
>>>
>>> Basically, all the API related actions(API create/update/delete/status
>>> change) are published to JMS topic along with label information. The
>>> gateways are responsible for listening to the topic, capture events which
>>> are relevant and process them. Ideally, gateways should filter the events
>>> based on API label and only process the events generated for APIs which are
>>> assigned with their gateway labels and rest of the events should be
>>> ignored.
>>>
>>> But when it comes to label update, the gateways should behave
>>> differently, due to the scenarios explained before. Though API label update
>>> is populated as an API update event, some of the gateways have to process
>>> this API updates differently(May be as an API create or may be as an API
>>> delete)
>>>
>>>- Moving API to a new gateway: When a new gateway label is assigned
>>>to an API, the event generated for the gateways with newly added
>>>label/labels is an API create event and the API should be deployed to the
>>>gateway/gateway with newly added label/labels.
>>>- Remove API from a gateway: When a label is removed from an API,
>>>the event generated to the gateway with the removed label is an API 
>>> delete
>>>event and API should be undeployed from that gateway.
>>>
>>> We came up with few solutions in order to handle label related API
>>> update events.
>>>
>>>- Introducing a new event on API label update:
>>>
>>>During an API update, we need to identify whether there is a
>>> label change and populate a label update event with label change details
>>> (ie: newly added label/previous labels).  The gateways can read the label
>>> change information and decide whether it is relevant to process the event
>>> and perform API deploy/undeploy actions accordingly.
>>>
>>>- Introducing a header/property to force every API gateway to
>>>process an label update related event:
>>>
>>> If there is a label update, a property is set to JMS event
>>> so that every gateway should process the events generated with that
>>> particular property. Ideally, the gateways process API events
>>> generated with its own gateway label, but in this case, they have to
>>> process the event if it comes with this property.
>>>
>> +1 for the approach as we can handle through the API update event. What
>> information are we going to send with this property? Is it only specify
>> label change? I think we will need to send the label changes as we will
>> need to  process it from the gateway side. Somecases we will need to remove
>> the API from particulae gateway during a label change.
>>
>>>
>>> Any suggestions on this? Your thoughts and suggestions are highly
>>> appreciated
>>>
>>> Thanks
>>> Thilini
>>>
>>> --
>>> Thilini Shanika
>>> Senior Software Engineer
>>> WSO2, Inc.; http://wso2.com
>>> 20, Palmgrove Avenue, Colombo 3
>>>
>>> E-mail: tgtshan...@gmail.com
>>>
>>>
>>
>>
>> --
>> Harsha Kumara
>> Software Engineer, WSO2 Inc.
>> Mobile: +94775505618 <+94%2077%20550%205618>
>> Blog:harshcreationz.blogspot.com
>>
>
>
>
> --
> Nuwan Dias
>
> Software Architect - WSO2, Inc. http://wso2.com
> email : nuw...@wso2.com
> Phone : +94 777 775 729 <077%20777%205729>
>



-- 
Thanks and Regards,

Isuru H.
+94 716 358 048* 

Re: [Dev] [APIM][C5] - Handling API's gateway label updates

[Harsha Kumara]

On Tue, Jun 20, 2017 at 8:29 PM, Nuwan Dias  wrote:

> I'm not in favor of using special headers or anything like that. What if
> we just send all API updates to all Gateways? Each Gateway upon receiving
> this event will request for the particular API from the Core. The Core will
> only give that API to the Gateway if the Gateway's labels matches that of
> the requesting Gateway. If it does not, the core will refuse to give the
> API to the Gateway and in that case if the Gateway already has that API
> deployed it should go and remove it from itself (same code that runs in
> case of an API delete event).
>
Yes it would be more consistent. If we send changed labels in a header, we
might can reduce calls to the core but it's very minimal.

>
> Thanks,
> NuwanD.
>
> On Tue, Jun 20, 2017 at 3:24 PM, Harsha Kumara  wrote:
>
>>
>>
>> On Tue, Jun 20, 2017 at 11:39 AM, Thilini Shanika 
>> wrote:
>>
>>> Hi All,
>>>
>>> As per the APIM C5 architecture, the gateways can be registered in APIM
>>> Core, specifying it's label and accessURLs. When creating/updating APIs,
>>> the API can be moved to a gateway by assigning the label of the gateway
>>> which registered under APIM Core. Once a label is assigned to an API, that
>>> particular API will be deployed and available to the gateway/gateways
>>> represented by the given label/labels.
>>>
>>> Basically, all the API related actions(API create/update/delete/status
>>> change) are published to JMS topic along with label information. The
>>> gateways are responsible for listening to the topic, capture events which
>>> are relevant and process them. Ideally, gateways should filter the events
>>> based on API label and only process the events generated for APIs which are
>>> assigned with their gateway labels and rest of the events should be
>>> ignored.
>>>
>>> But when it comes to label update, the gateways should behave
>>> differently, due to the scenarios explained before. Though API label update
>>> is populated as an API update event, some of the gateways have to process
>>> this API updates differently(May be as an API create or may be as an API
>>> delete)
>>>
>>>- Moving API to a new gateway: When a new gateway label is assigned
>>>to an API, the event generated for the gateways with newly added
>>>label/labels is an API create event and the API should be deployed to the
>>>gateway/gateway with newly added label/labels.
>>>- Remove API from a gateway: When a label is removed from an API,
>>>the event generated to the gateway with the removed label is an API 
>>> delete
>>>event and API should be undeployed from that gateway.
>>>
>>> We came up with few solutions in order to handle label related API
>>> update events.
>>>
>>>- Introducing a new event on API label update:
>>>
>>>During an API update, we need to identify whether there is a
>>> label change and populate a label update event with label change details
>>> (ie: newly added label/previous labels).  The gateways can read the label
>>> change information and decide whether it is relevant to process the event
>>> and perform API deploy/undeploy actions accordingly.
>>>
>>>- Introducing a header/property to force every API gateway to
>>>process an label update related event:
>>>
>>> If there is a label update, a property is set to JMS event
>>> so that every gateway should process the events generated with that
>>> particular property. Ideally, the gateways process API events
>>> generated with its own gateway label, but in this case, they have to
>>> process the event if it comes with this property.
>>>
>> +1 for the approach as we can handle through the API update event. What
>> information are we going to send with this property? Is it only specify
>> label change? I think we will need to send the label changes as we will
>> need to  process it from the gateway side. Somecases we will need to remove
>> the API from particulae gateway during a label change.
>>
>>>
>>> Any suggestions on this? Your thoughts and suggestions are highly
>>> appreciated
>>>
>>> Thanks
>>> Thilini
>>>
>>> --
>>> Thilini Shanika
>>> Senior Software Engineer
>>> WSO2, Inc.; http://wso2.com
>>> 20, Palmgrove Avenue, Colombo 3
>>>
>>> E-mail: tgtshan...@gmail.com
>>>
>>>
>>
>>
>> --
>> Harsha Kumara
>> Software Engineer, WSO2 Inc.
>> Mobile: +94775505618 <+94%2077%20550%205618>
>> Blog:harshcreationz.blogspot.com
>>
>
>
>
> --
> Nuwan Dias
>
> Software Architect - WSO2, Inc. http://wso2.com
> email : nuw...@wso2.com
> Phone : +94 777 775 729 <+94%2077%20777%205729>
>



-- 
Harsha Kumara
Software Engineer, WSO2 Inc.
Mobile: +94775505618
Blog:harshcreationz.blogspot.com
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] [APIM][C5] - Handling API's gateway label updates

[Nuwan Dias]

I'm not in favor of using special headers or anything like that. What if we
just send all API updates to all Gateways? Each Gateway upon receiving this
event will request for the particular API from the Core. The Core will only
give that API to the Gateway if the Gateway's labels matches that of the
requesting Gateway. If it does not, the core will refuse to give the API to
the Gateway and in that case if the Gateway already has that API deployed
it should go and remove it from itself (same code that runs in case of an
API delete event).

Thanks,
NuwanD.

On Tue, Jun 20, 2017 at 3:24 PM, Harsha Kumara  wrote:

>
>
> On Tue, Jun 20, 2017 at 11:39 AM, Thilini Shanika 
> wrote:
>
>> Hi All,
>>
>> As per the APIM C5 architecture, the gateways can be registered in APIM
>> Core, specifying it's label and accessURLs. When creating/updating APIs,
>> the API can be moved to a gateway by assigning the label of the gateway
>> which registered under APIM Core. Once a label is assigned to an API, that
>> particular API will be deployed and available to the gateway/gateways
>> represented by the given label/labels.
>>
>> Basically, all the API related actions(API create/update/delete/status
>> change) are published to JMS topic along with label information. The
>> gateways are responsible for listening to the topic, capture events which
>> are relevant and process them. Ideally, gateways should filter the events
>> based on API label and only process the events generated for APIs which are
>> assigned with their gateway labels and rest of the events should be
>> ignored.
>>
>> But when it comes to label update, the gateways should behave
>> differently, due to the scenarios explained before. Though API label update
>> is populated as an API update event, some of the gateways have to process
>> this API updates differently(May be as an API create or may be as an API
>> delete)
>>
>>- Moving API to a new gateway: When a new gateway label is assigned
>>to an API, the event generated for the gateways with newly added
>>label/labels is an API create event and the API should be deployed to the
>>gateway/gateway with newly added label/labels.
>>- Remove API from a gateway: When a label is removed from an API, the
>>event generated to the gateway with the removed label is an API delete
>>event and API should be undeployed from that gateway.
>>
>> We came up with few solutions in order to handle label related API update
>> events.
>>
>>- Introducing a new event on API label update:
>>
>>During an API update, we need to identify whether there is a
>> label change and populate a label update event with label change details
>> (ie: newly added label/previous labels).  The gateways can read the label
>> change information and decide whether it is relevant to process the event
>> and perform API deploy/undeploy actions accordingly.
>>
>>- Introducing a header/property to force every API gateway to process
>>an label update related event:
>>
>> If there is a label update, a property is set to JMS event so
>> that every gateway should process the events generated with that particular
>> property. Ideally, the gateways process API events generated with its own
>> gateway label, but in this case, they have to process the event if it comes
>> with this property.
>>
> +1 for the approach as we can handle through the API update event. What
> information are we going to send with this property? Is it only specify
> label change? I think we will need to send the label changes as we will
> need to  process it from the gateway side. Somecases we will need to remove
> the API from particulae gateway during a label change.
>
>>
>> Any suggestions on this? Your thoughts and suggestions are highly
>> appreciated
>>
>> Thanks
>> Thilini
>>
>> --
>> Thilini Shanika
>> Senior Software Engineer
>> WSO2, Inc.; http://wso2.com
>> 20, Palmgrove Avenue, Colombo 3
>>
>> E-mail: tgtshan...@gmail.com
>>
>>
>
>
> --
> Harsha Kumara
> Software Engineer, WSO2 Inc.
> Mobile: +94775505618 <+94%2077%20550%205618>
> Blog:harshcreationz.blogspot.com
>



-- 
Nuwan Dias

Software Architect - WSO2, Inc. http://wso2.com
email : nuw...@wso2.com
Phone : +94 777 775 729
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] [APIM][C5] - Handling API's gateway label updates

[Harsha Kumara]

On Tue, Jun 20, 2017 at 11:39 AM, Thilini Shanika  wrote:

> Hi All,
>
> As per the APIM C5 architecture, the gateways can be registered in APIM
> Core, specifying it's label and accessURLs. When creating/updating APIs,
> the API can be moved to a gateway by assigning the label of the gateway
> which registered under APIM Core. Once a label is assigned to an API, that
> particular API will be deployed and available to the gateway/gateways
> represented by the given label/labels.
>
> Basically, all the API related actions(API create/update/delete/status
> change) are published to JMS topic along with label information. The
> gateways are responsible for listening to the topic, capture events which
> are relevant and process them. Ideally, gateways should filter the events
> based on API label and only process the events generated for APIs which are
> assigned with their gateway labels and rest of the events should be
> ignored.
>
> But when it comes to label update, the gateways should behave differently,
> due to the scenarios explained before. Though API label update is populated
> as an API update event, some of the gateways have to process this API
> updates differently(May be as an API create or may be as an API delete)
>
>- Moving API to a new gateway: When a new gateway label is assigned to
>an API, the event generated for the gateways with newly added label/labels
>is an API create event and the API should be deployed to the
>gateway/gateway with newly added label/labels.
>- Remove API from a gateway: When a label is removed from an API, the
>event generated to the gateway with the removed label is an API delete
>event and API should be undeployed from that gateway.
>
> We came up with few solutions in order to handle label related API update
> events.
>
>- Introducing a new event on API label update:
>
>During an API update, we need to identify whether there is a
> label change and populate a label update event with label change details
> (ie: newly added label/previous labels).  The gateways can read the label
> change information and decide whether it is relevant to process the event
> and perform API deploy/undeploy actions accordingly.
>
>- Introducing a header/property to force every API gateway to process
>an label update related event:
>
> If there is a label update, a property is set to JMS event so
> that every gateway should process the events generated with that particular
> property. Ideally, the gateways process API events generated with its own
> gateway label, but in this case, they have to process the event if it comes
> with this property.
>
+1 for the approach as we can handle through the API update event. What
information are we going to send with this property? Is it only specify
label change? I think we will need to send the label changes as we will
need to  process it from the gateway side. Somecases we will need to remove
the API from particulae gateway during a label change.

>
> Any suggestions on this? Your thoughts and suggestions are highly
> appreciated
>
> Thanks
> Thilini
>
> --
> Thilini Shanika
> Senior Software Engineer
> WSO2, Inc.; http://wso2.com
> 20, Palmgrove Avenue, Colombo 3
>
> E-mail: tgtshan...@gmail.com
>
>


-- 
Harsha Kumara
Software Engineer, WSO2 Inc.
Mobile: +94775505618
Blog:harshcreationz.blogspot.com
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] [APIM][C5] - Handling API's gateway label updates

[Fazlan Nazeem]

On Tue, Jun 20, 2017 at 11:39 AM, Thilini Shanika  wrote:

> Hi All,
>
> As per the APIM C5 architecture, the gateways can be registered in APIM
> Core, specifying it's label and accessURLs. When creating/updating APIs,
> the API can be moved to a gateway by assigning the label of the gateway
> which registered under APIM Core. Once a label is assigned to an API, that
> particular API will be deployed and available to the gateway/gateways
> represented by the given label/labels.
>
> Basically, all the API related actions(API create/update/delete/status
> change) are published to JMS topic along with label information. The
> gateways are responsible for listening to the topic, capture events which
> are relevant and process them. Ideally, gateways should filter the events
> based on API label and only process the events generated for APIs which are
> assigned with their gateway labels and rest of the events should be
> ignored.
>
> But when it comes to label update, the gateways should behave differently,
> due to the scenarios explained before. Though API label update is populated
> as an API update event, some of the gateways have to process this API
> updates differently(May be as an API create or may be as an API delete)
>
>- Moving API to a new gateway: When a new gateway label is assigned to
>an API, the event generated for the gateways with newly added label/labels
>is an API create event and the API should be deployed to the
>gateway/gateway with newly added label/labels.
>- Remove API from a gateway: When a label is removed from an API, the
>event generated to the gateway with the removed label is an API delete
>event and API should be undeployed from that gateway.
>
> We came up with few solutions in order to handle label related API update
> events.
>
>- Introducing a new event on API label update:
>
>During an API update, we need to identify whether there is a
> label change and populate a label update event with label change details
> (ie: newly added label/previous labels).  The gateways can read the label
> change information and decide whether it is relevant to process the event
> and perform API deploy/undeploy actions accordingly.
>
>- Introducing a header/property to force every API gateway to process
>an label update related event:
>
> If there is a label update, a property is set to JMS event so
> that every gateway should process the events generated with that particular
> property. Ideally, the gateways process API events generated with its own
> gateway label, but in this case, they have to process the event if it comes
> with this property.
>

+1 for this approach. I think we should name this property in a generic way
so that, we could use the same property to indicate that any event with
this property should be processed by all gateways so that we could use it
to similar usecases in future.

>
> Any suggestions on this? Your thoughts and suggestions are highly
> appreciated
>
> Thanks
> Thilini
>
> --
> Thilini Shanika
> Senior Software Engineer
> WSO2, Inc.; http://wso2.com
> 20, Palmgrove Avenue, Colombo 3
>
> E-mail: tgtshan...@gmail.com
>
>
> ___
> Dev mailing list
> Dev@wso2.org
> http://wso2.org/cgi-bin/mailman/listinfo/dev
>
>


-- 
Thanks & Regards,

Fazlan Nazeem

*Senior Software Engineer*

*WSO2 Inc*
Mobile : +94772338839
<%2B94%20%280%29%20773%20451194>
fazl...@wso2.com
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

[Dev] [APIM][C5] - Handling API's gateway label updates

[Thilini Shanika]

Hi All,

As per the APIM C5 architecture, the gateways can be registered in APIM
Core, specifying it's label and accessURLs. When creating/updating APIs,
the API can be moved to a gateway by assigning the label of the gateway
which registered under APIM Core. Once a label is assigned to an API, that
particular API will be deployed and available to the gateway/gateways
represented by the given label/labels.

Basically, all the API related actions(API create/update/delete/status
change) are published to JMS topic along with label information. The
gateways are responsible for listening to the topic, capture events which
are relevant and process them. Ideally, gateways should filter the events
based on API label and only process the events generated for APIs which are
assigned with their gateway labels and rest of the events should be
ignored.

But when it comes to label update, the gateways should behave differently,
due to the scenarios explained before. Though API label update is populated
as an API update event, some of the gateways have to process this API
updates differently(May be as an API create or may be as an API delete)

   - Moving API to a new gateway: When a new gateway label is assigned to
   an API, the event generated for the gateways with newly added label/labels
   is an API create event and the API should be deployed to the
   gateway/gateway with newly added label/labels.
   - Remove API from a gateway: When a label is removed from an API, the
   event generated to the gateway with the removed label is an API delete
   event and API should be undeployed from that gateway.

We came up with few solutions in order to handle label related API update
events.

   - Introducing a new event on API label update:

   During an API update, we need to identify whether there is a
label change and populate a label update event with label change details
(ie: newly added label/previous labels).  The gateways can read the label
change information and decide whether it is relevant to process the event
and perform API deploy/undeploy actions accordingly.

   - Introducing a header/property to force every API gateway to process an
   label update related event:

If there is a label update, a property is set to JMS event so
that every gateway should process the events generated with that particular
property. Ideally, the gateways process API events generated with its own
gateway label, but in this case, they have to process the event if it comes
with this property.

Any suggestions on this? Your thoughts and suggestions are highly
appreciated

Thanks
Thilini

-- 
Thilini Shanika
Senior Software Engineer
WSO2, Inc.; http://wso2.com
20, Palmgrove Avenue, Colombo 3

E-mail: tgtshan...@gmail.com
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev