Hi All +1 for making the new GW pluggable.
Apart from defining a GWInterface we might have to generalize some UI parts ie mediation, advance endpoint configs which are currently specific to ESB or those UI parts also needs to be pluggable. Regards Jo On Tue, Jan 26, 2016 at 12:29 PM, Sanjeewa Malalgoda <[email protected]> wrote: > 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/> > > > -- -- *Joseph Fonseka* WSO2 Inc.; http://wso2.com lean.enterprise.middleware mobile: +94 772 512 430 skype: jpfonseka * <http://lk.linkedin.com/in/rumeshbandara>*
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
