Hi All,
We quickly went through code and checked how we can accommodate this change
with minimum changes to current implementation.
I can see 2 places where we can plug this as extension (and let users to
implement as per requirements).
API publisher is the only component that need direct API gateway access.
Other components do not need direct API gateway access. And gateway will
use other components.
01. Extract interface from APIGatewayAdminClient and make it pluggable.
Then we may need to implement API related methods, secure
vault(according to requirements) related methods and sequence related
methods there.
As of now we have abstract class for admin client and implementation
is APIGatewayAdminClient.
In that case we need to implement like 15 methods which are coupled
to our current synapse based gateway.
02. Extract interface from APIGatewayManager and let users to do their
implementation based on it and plug it to publisher.
Then we will have interface similar to below and its more generic
than previously mentioned implementation.
public interface APIGatewayManagerInterface {
Map<String, String> publishToGateway(API api, APITemplateBuilder
builder, String tenantDomain);
Map<String, String> removeFromGateway(API api, String tenantDomain);
Map<String, String> removeDefaultAPIFromGateway(API api, String
tenantDomain);
boolean isAPIPublished(API api, String tenantDomain)throws
APIManagementException;
}
Both of these implementations should support multiple environment use case.
In APIGatewayManager we are checking multiple environments and if we
used APIGatewayManager as extension point then users are free to
implement that logic as well.
However this pluggable component need to have access to API Manager
configuration reader and get certain properties(environment details,
gateway url etc) from that.
Next we need to think about what we are going to do for handlers and
custom sequences.
As per offline chat with chanakaF next version of gateway will have
some mechanism to extend mediation sequence.
And also there will be alternative for handlers.
So we may use them while doing implementation for new gateway.
For both of these implementations we need to make APITemplateBuilder
pluggable(this builder is responsible for create API description based
on predefined template).
Then we can maintain template builder for each gateway type.
WDYT?
Thanks,
sanjeewa.
On Tue, Jan 19, 2016 at 10:25 AM, Kasun Indrasiri <[email protected]> wrote:
> @Sanjeewa,
> I think we have to provide an abstraction from API-M (something like
> GWInterface) so that an implementation of that GWInterface can dynamically
> register with API-M through OSGi. That implementation contains all the
> logic required to publish a given API to the GW that we are planning to
> integrate with. There will be quite a few things that we have to do this to
> work, but in the long run this will be quite useful.
>
> @Shiro: Yes, if we manage to do this, theoretically we can integrate with
> any GW. But I'm not sure whether its a common requirement at the moment.
>
> On Mon, Jan 18, 2016 at 11:39 PM, Shiro Kulatilake <[email protected]> wrote:
>
>> Hi,
>>
>> Are we looking at making it possible to plug in any gateway - i.e. WSO2
>> or non-WSO2 ? - If yes that would be great.
>> However then
>> - the API definition itself might have to be customizable - or extensible
>> from a base model
>> - the "object" that is propagated to the gateway of choice needs to be
>> anything as well
>>
>> Isn't this the same thing that we do with Greg today to publish APIs to
>> different gateways through registry extensions ?
>>
>> Thank you,
>> Shiro
>>
>> On Mon, Jan 18, 2016 at 11:20 PM, Sanjeewa Malalgoda <[email protected]>
>> wrote:
>>
>>> Hi kasun,
>>> If we consider current architecture publisher will call to rest api
>>> admin service and push api configurations created using velosity template.
>>> If we are having similar service in new gateway and created velosity
>>> template according to new definition we can easily push apis to new
>>> gateway.
>>> If need we may provide extension point to api publishing. Then we will
>>> have complete API object in extesion and we can publish to any custom
>>> gateway as we need.
>>> Store do not need direct service access of gateway.
>>>
>>> Thanks
>>> sanjeewa.
>>>
>>> sent from my phone
>>> On Jan 18, 2016 10:59 PM, "Kasun Indrasiri" <[email protected]> wrote:
>>>
>>>> Hi,
>>>>
>>>> When it comes to moving API-M to the new GW in the future, I think
>>>> having the $subject would be really helpful. This would allow us to plug
>>>> any arbitrary GW impl along with the required wrappers (implementing the
>>>> API-GW abstractions).
>>>>
>>>> WDYT?
>>>>
>>>> Thanks,
>>>> Kasun.
>>>>
>>>> --
>>>> Kasun Indrasiri
>>>> Software Architect
>>>> WSO2, Inc.; http://wso2.com
>>>> lean.enterprise.middleware
>>>>
>>>> cell: +94 77 556 5206
>>>> Blog : http://kasunpanorama.blogspot.com/
>>>>
>>>> _______________________________________________
>>>> Architecture mailing list
>>>> [email protected]
>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>>
>>>>
>>> _______________________________________________
>>> Architecture mailing list
>>> [email protected]
>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>
>>>
>>
>>
>> --
>>
>>
>> *Shiroshica Kulatilake | Solutions Architect, WSO2 Inc.+94 776523867
>> <%2B94%20776523867> *
>>
>> _______________________________________________
>> Architecture mailing list
>> [email protected]
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
>
> --
> Kasun Indrasiri
> Software Architect
> WSO2, Inc.; http://wso2.com
> lean.enterprise.middleware
>
> cell: +94 77 556 5206
> Blog : http://kasunpanorama.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
