On Wed, Apr 26, 2017 at 11:02 AM, Lakmal Warusawithana <lak...@wso2.com> wrote:
> > > On Wed, Apr 26, 2017 at 10:51 AM, Manoj Gunawardena <man...@wso2.com> > wrote: > >> Are we going to use durable subscription here? When ever gw node down and >> re start, >> it should fetch messages which add to the topic during the down time. >> In case durable subscription what is the mechanism to create client id >> for each gw.Is that discussed and confirm? >> > > No, we are not going to use durable topic. > Sorry I mean to say durable subscription. > New gateways (scaling) or if we restart a gateway, existing APIs will > fetch via API Manager core. Only new API (after boot up) notifications are > getting via the topic and actual API will fetch from the core. ( we can try > what sanjeewa mention - getting API from the topic - but previous APIs need > to fetch from the core) > > >> >> On Tue, Apr 25, 2017 at 2:20 PM, Sanjeewa Malalgoda <sanje...@wso2.com> >> wrote: >> >>> API create/update/delete are similar type of events IMO. After we >>> getting any event for these what we have to do is redeploy API or discard >>> it. IMO if possible we should try to avoid web service call based update >>> and send ballerina file with event itself(if its not heavy object). Other >>> type of event is subscription change(which originates from API store). And >>> for the throttling we need another topic. So as i see we can survive with >>> only 3 topics at the moment. >>> >>> Thanks, >>> sanjeewa. >>> >>> On Tue, Apr 25, 2017 at 11:44 AM, Nuwan Dias <nuw...@wso2.com> wrote: >>> >>>> The type of events we're talking about here are rare events. API >>>> creation, subscription, etc won't happen that frequently. So I don't think >>>> there will be much load on the broker as such. >>>> >>>> Architecturally having separate topics will be clean. The code and the >>>> error handling parameters (dead letter queue) can be defined per event >>>> type. However I think it'll cause additional burden to the Gateway since >>>> the Gateway now has to establish and maintain several connections to the >>>> broker. And since these connections need to happen at startup, each >>>> connection that needs to be established adds up to the startup time of the >>>> Gateway. So I would prefer to minimize the number of topics as much as >>>> possible. >>>> >>>> On Tue, Apr 25, 2017 at 11:09 AM, Thilini Shanika <thili...@wso2.com> >>>> wrote: >>>> >>>>> Hi All, >>>>> >>>>> According to APIM C5 architecture, the events like API create, API >>>>> lifecycle status change, API subscriptions are notified to APIM gateway >>>>> via >>>>> JMS topic/topics in the broker. >>>>> >>>>> Following diagram depicts how APIM core, broker and gateway components >>>>> interact when there is an event generated from Core. >>>>> >>>>> >>>>> Following are the two options we came up while implementing above >>>>> event publishing scenario from APIM Core --> Broker --> Gateways. >>>>> >>>>> *1) Publishing all the events to a common topic * >>>>> >>>>> A single topic is maintained in broker and all the gateways are >>>>> subscribed to this common topic. APIM core publishes all the events >>>>> generated from APIM to this particular topic. After topic subscription, >>>>> the >>>>> gateways keep listening to the topic and once a notification is received, >>>>> it has to be filtered to identify the event type and perform the required >>>>> action. The events like API create, lifecycle status change, API >>>>> subscription etc are getting published through this common topic and the >>>>> event type has to be reflected in the notification itself so that the >>>>> gateways can identify the notification and decide what has to be performed >>>>> next. In this case, it has to maintain a single connection to JMS topic >>>>> from each gateway. >>>>> >>>>> >>>>> >>>>> >>>>> *2) Maintaining dedicated topics for each event type* >>>>> >>>>> In this option, we can either maintain dedicated topic for each event >>>>> type (API Create, API publish, API subscription) or maintain dedicated >>>>> topics for API publisher, API store events. As per this solution, the >>>>> gateways have to subscribe to all these topics and keep listening to all >>>>> of >>>>> them. In that case, gateways have to establish and maintain more >>>>> connections with the broker, since there are several topic subscriptions. >>>>> Once a notification is generated from APIM and published to the relevant >>>>> topic, that particular notification is received by the relevant gateway >>>>> service and process the message to perform the next action. But, the >>>>> filtering logic which has to be executed in ballerina gateway side is less >>>>> complex in this solution. >>>>> >>>>> >>>>> >>>>> What would be the best option here? Your suggestions and comments are >>>>> highly appreciated. >>>>> >>>>> Thanks >>>>> Thilini >>>>> >>>>> >>>>> >>>>> -- >>>>> Thilini Shanika >>>>> Senior Software Engineer >>>>> WSO2, Inc.; http://wso2.com >>>>> 20, Palmgrove Avenue, Colombo 3 >>>>> >>>>> E-mail: tgtshan...@gmail.com >>>>> >>>>> >>>> >>>> >>>> -- >>>> Nuwan Dias >>>> >>>> Software Architect - WSO2, Inc. http://wso2.com >>>> email : nuw...@wso2.com >>>> Phone : +94 777 775 729 <077%20777%205729> >>>> >>> >>> >>> >>> -- >>> >>> *Sanjeewa Malalgoda* >>> WSO2 Inc. >>> Mobile : +94713068779 <+94%2071%20306%208779> >>> >>> <http://sanjeewamalalgoda.blogspot.com/>blog >>> :http://sanjeewamalalgoda.blogspot.com/ >>> <http://sanjeewamalalgoda.blogspot.com/> >>> >>> >>> >>> _______________________________________________ >>> Architecture mailing list >>> Architecture@wso2.org >>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>> >>> >> >> >> -- >> Manoj Gunawardena >> Tech Lead >> WSO2, Inc.: http://wso2.com >> lean.enterprise.middleware >> Mobile : +94 77 2291643 >> > > > > -- > Lakmal Warusawithana > Director - Cloud Architecture; WSO2 Inc. > Mobile : +94714289692 <+94%2071%20428%209692> > Blogs : https://medium.com/@lakwarus/ > http://lakmalsview.blogspot.com/ > > -- Lakmal Warusawithana Director - Cloud Architecture; WSO2 Inc. Mobile : +94714289692 Blogs : https://medium.com/@lakwarus/ http://lakmalsview.blogspot.com/
_______________________________________________ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
