Hi, Another aspect which I came recently with Nissan is publishing APIs to internal/external portals. Part of this requirement can be handled through GREG-Executors or though API import/Export capabilities consumed through some scripting or through a client application. However having first class support would make the solution much more elegant.
To my understanding when publishing an API the publisher push the metadata to the databases and then invokes APIs on the gateway to create the mediation scripts. But this knowledge of published APIs (What is saved to the AM_DB) should made available to store through a service call rather that through a shared db. So what I am thinking is instead of just publishing to gateways this should have some extensibility to publish to API store as well. An environment should consist as a combination of an Gateway Manager + optional store, and publishing from the publisher will be two fold 1. Publish to the Store - i.e. Through service call replace current db write with a service call to the store which in turn will do the db write. 2. Publish to the Gateway Manager Eranga. 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 > > -- Eranga Perera *Senior Lead Solutions Engineer* *WSO2, Inc. * Mobile : +94 72 778 4250 [email protected]
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
