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 <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
