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. 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 Blogs : https://medium.com/@lakwarus/ http://lakmalsview.blogspot.com/
_______________________________________________ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
