I am +1 with option 2 but not with separate topics for each and every event types. Like you have suggested we can have separation like API publisher, API store events. It will give a clean architectural view and we can have clean gateway logic for each event types.
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 > > -- 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
