Hi All, Day by day we are getting many requirements for exact same requirement. So i think we need to consider this for upcoming release. WDYT?
Thanks, sanjeewa. On Tue, Jan 26, 2016 at 2:17 PM, Joseph Fonseka <[email protected]> wrote: > 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>* > > -- *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
