Hi Thilini, If we are to proceed with option 2, we need to make sure that events of different topics are completely independant.
For example, if we have a separation of API publisher and API store, api publishing and subscription are 2 events that will be published to different topics. Since there's no ordering of event receipt from 2 different topics, it is possible for a gateway node to receive the 'subscription' notification before the 'publish' notification and this could lead to problems. Thank you, Sasikala On Tue, Apr 25, 2017 at 11:09 AM, Thilini Shanika <[email protected]> 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: [email protected] > > > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- Sasikala Kottegoda *Senior Software Engineer* WSO2 Inc., http://wso2.com/ lean. enterprise. middleware Mobile: +94 774835928 [image: https://wso2.com/signature] <https://wso2.com/signature>
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
