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
