I don't like the idea of supporting this as a first class feature. Are we talking about supporting publishing to external Gateways as a first class feature or as extension points which one needs to write?
If its the former, I think its a slippery slope. Which Gateways should we support? Which versions? As they introduce newer versions, do we change our code to support them as well? If we go down this slope there will be more and more requests to support more and more Gateways and it'll end up being un-manageable. If its the latter, we've already done that with several Gateways at the moment. We use Registry Handlers, LC executors, etc to do this. So what's lacking from a product PoV to publish to external Gateways if we're considering doing this via extensions? Making an API available on a third party Gateway is just the tip of the Iceberg. There are lots more to think about. Ex: Mediation Policies, when publishing to a WSO2 ESB (Gateway), we know how to provide a mediation extension (by writing a code snippet using Syanpse). But if we're publishing to some other Gateway, it won't be the same. And it won't be easy generalizing that as well. Same applies to response caching, URI-templates, etc. I can imagine going for a connector kind of approach where we might maintain these extensions as connectors with a separate lifecycle as opposed to the product lifecycle. But I'm -1 on making this a first class feature of the product. I do think we already have the necessary extension points to do this without much trouble even today. Perhaps we can revisit what we've already done to publish to external Gateways and see what the pain points are. Thanks, NuwanD. On Tue, Jul 26, 2016 at 12:17 PM, Susinda Perera <[email protected]> wrote: > +1 for supporting pluggable gateways (both wso2 and other) as we see this > requirement is arising. > Just another idea, How about api runtime stat reporting, are we going to > include this in the interface definition, or let the gateway to handle its > own stats. > > > > On Tue, Jul 26, 2016 at 9:10 AM, Sanjeewa Malalgoda <[email protected]> > wrote: > >> Created entry to track this for future release. >> >> Thanks, >> sanjeewa. >> >> On Mon, Jul 25, 2016 at 3:35 PM, Isabelle Mauny <[email protected]> >> wrote: >> >>> Agreed that making this pluggable is important, although it poses >>> interesting management issues (the publishing experience in particular). >>> >>> Another design point, after discussing with a key prospect: ability to >>> decentralize the administration of the GWs by getting them to pull their >>> configuration from the central repository. All the APIs are managed >>> centrally (as in metadata management) but are executed in a decentralized >>> way (in different countries for example). Monitoring is central though. >>> >>> Isabelle. >>> >>> ------------------------------------------------------------------------------------- >>> *Isabelle Mauny* >>> VP, Product Strategy - WSO2, Inc. - http://wso2.com/ >>> On Mon, Jul 25, 2016 at 11:54 AM, Sanjeewa Malalgoda <[email protected]> >>> wrote: >>> >>>> 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/> >>>> >>>> >>>> >>> >> >> >> -- >> >> *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 >> >> > > > -- > *Susinda Perera* > Software Engineer > B.Sc.(Eng), M.Sc(Computer Science), AMIE(SL) > Mobile:(+94)716049075 > Blog: susinda.blogspot.com > WSO2 Inc. http://wso2.com/ > Tel : 94 11 214 5345 Fax :94 11 2145300 > > > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- Nuwan Dias Software Architect - WSO2, Inc. http://wso2.com email : [email protected] Phone : +94 777 775 729
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
