1
FORM 2
THE PATENTS ACT, 1970 (39 OF
1970)
&
THE PATENT RULES, 2003
COMPLETE SPECIFICATION
(See section 10 and rule 13)
“METHOD AND SYSTEM FOR MANAGING EVENTS USING AN EVENT
ROUTING MANAGEMENT MODULE”
We, Jio Platforms Limited, an Indian National, of Office - 101, Saffron, Nr. Centre Point,
Panchwati 5 Rasta, Ambawadi, Ahmedabad - 380006, Gujarat, India.
The following specification particularly describes the invention and the manner in which it is
to be performed.
2
METHOD AND SYSTEM FOR MANAGING EVENTS USING AN EVENT
ROUTING MANAGEMENT MODULE
TECHNICAL FIELD
[0001] Embodiments of the present disclosure generally relate to network performance
management systems. More particularly, embodiments of the present disclosure relate to
managing events using an event routing management (ERM) module.
BACKGROUND
[0002] The following description of the related art is intended to provide background
information pertaining to the field of the disclosure. This section may include certain aspects
of the art that may be related to various features of the present disclosure. However, it should
be appreciated that this section is used only to enhance the understanding of the reader with
respect to the present disclosure, and not as admissions of the prior art.
[0003] A network function virtualization (NFV) software defined networking (SDN) server is
based on micro service architecture. These microservices servers have specific task and
functionality which they all need to perform. The microservices servers work in tandem to
achieve the overall functionality of the NFV SDN server. Each microservice server has exposed
certain application programming interfaces (APIs) which are called by other microservices
servers. In conventional network implementations, a crisscross model has been adopted, where
each microservice server is communicating with all the other microservice servers directly.
Thus, there exists a need for a server that it can route event requests of one microservices server
to another.
[0004] Thus, there exists an imperative need in the art for a system and a method for event
routing management, which the present disclosure aims to address.
SUMMARY
3
[0005] This section is provided to introduce certain aspects of the present disclosure in a
simplified form that are further described below in the detailed description. This summary is
not intended to identify the key features or the scope of the claimed subject matter.
[0006] An aspect of the present disclosure may relate to a method for managing events using
an event routing management (ERM) module. The method comprises receiving, by an elastic
load balancer (ELB) unit, from one or more publishing microservice (MS) modules, one or
more events. Further, the method comprises publishing, by a publish handler, the received one
or more events facilitating dynamic event subscription management. Furthermore, the method
comprises notifying, by a notify handler, the published one or more events to one or more
subscriber microservice (MS) modules. Hereinafter, the method comprises storing, by a storage
unit, in a database, a set of transactional logs data associated with the one or more events.
[0007] In an exemplary aspect of the present disclosure, the one or more publishing MS
modules correspond to microservices that generate and send the one or more events to the
Event Routing Manager (ERM).
[0008] In an exemplary aspect of the present disclosure, the step of notifying, by the notify
handler [306], the published one or more events to the one or more subscriber MS modules is
based on a set of context metadata information associated with each of the one or more events.
[0009] In an exemplary aspect of the present disclosure, the set of context metadata
information comprises details to identify context of the one or more events, wherein the set of
context metadata comprises at least an end point information associated with the one or more
events, priority level of the one or more events, and subscriber ID for each of the one or more
events.
[0010] In an exemplary aspect of the present disclosure, the one or more events are categorized
based on at least a type or purpose, wherein the one or more events comprises at least one of:
a user registered event, a payment event, and an order placed event.
[0011] In an exemplary aspect of the present disclosure, the method comprises providing, by
the one or more subscriber MS modules, to the ERM module using a subscribe handler, the set
of context metadata information based on at least one of a subscribing action, and an
4
unsubscribing action. The at least one of the subscribing action, and the unsubscribing action
is associated with an event from the one or more events.
[0012] In an exemplary aspect of the present disclosure, the method comprises receiving, by
each of the one or more subscriber MS modules, a notification associated with one or more
target events from the published one or more events, and wherein the notification is based on
the subscribing action associated with the one or more target events.
[0013] In an exemplary aspect of the present disclosure, the method comprises checking, by
the subscribe handler, a status of the one or more subscriber MS modules. The step of checking
the status of the one or more subscriber MS modules comprises identifying, by the subscribe
handler, a first request from the one or more subscriber MS modules for unsubscribing from a
first target event.
[0014] In an exemplary aspect of the present disclosure, the method comprises removing, by
the subscribe handler, a set of target context metadata information, and wherein the set of target
context metadata information is associated with identification of the first request.
[0015] In an exemplary aspect of the present disclosure, the method comprises managing, by
a fault, configuration, accounting, performance and security (FCAPS) unit, a set of
performance counter data and a set of alarm data, and wherein the set of performance counter
data and the set of alarm data are associated with functions of an operations and management
(OAM) module connected with at least the ERM module.
[0016] In an exemplary aspect of the present disclosure, the set of transactional logs data
comprises at least one of: context metadata information, FCAPS performance counter data,
FCAPS alarm data, types of microservice nodes, registration data of the microservice nodes,
deregistration data of the microservice nodes, subscription data of the microservice nodes, and
unsubscribe data of the microservice nodes for the one or more events.
[0017] Another aspect of the present disclosure may relate to a system for managing events
using an event routing management (ERM) module. The system comprises an elastic load
balancer (ELB) unit configured to receive, from one or more publishing microservice (MS)
modules, one or more events. The system further comprises a publish handler connected to at
5
least the ELB unit. The publish handler is configured to publish the received one or more events
facilitating dynamic event subscription management. The system further comprises a notify
handler connected to at least the publish handler. The notify handler is configured to notify the
published one or more events to one or more subscriber microservice (MS) modules. The
system further comprises a storage unit connected to at least the notify handler. The storage
unit is configured to store, in a database, a set of transactional logs data associated with the one
or more events.
[0018] Yet another aspect of the present disclosure may relate to a non-transitory computer
readable storage medium storing instructions for managing events using an event routing
management (ERM) module, the instructions include executable code which, when executed
by one or more units of a system cause an elastic load balancer (ELB) unit to receive, from one
or more publishing microservice (MS) modules, one or more events. The instructions when
executed by the system further cause a publish handler unit to publish the received one or more
events facilitating dynamic event subscription management. The instructions when executed
by the system further cause a notify handler unit to notify the published one or more events to
one or more subscriber microservice (MS) modules. The instructions when executed by the
system further cause a storage unit to store, in a database, a set of transactional logs data
associated with the one or more events.
OBJECTS OF THE INVENTION
[0019] Some of the objects of the present disclosure, which at least one embodiment disclosed
herein satisfies are listed herein below.
[0020] It is an object of the present disclosure to provide a system and a method for event
routing management.
[0021] It is another object of the present disclosure to provide a solution which acts as a central
service to keep information of all events in a network.
[0022] It is yet another object of the present disclosure to provide a solution that enables storing
transactional logs in a database server, which would be helpful to debug in case of event failure.
6
[0023] It is yet another object of the present disclosure to provide a solution that allows
addition of new events to an ERM server dynamically, thereby reducing code overhead in the
event any microservice server wants to use same event functionality which is already being
used by other microservice server.
[0024] It is yet another object of the present disclosure to provide a solution that enables
parallel, or sequential message delivery can be defined for each event that has multiple
subscriber server.
[0025] It is yet another object of the present disclosure to provide a solution that supports
redundancy in the event one ERM server goes down.
DESCRIPTION OF THE DRAWINGS
[0026] The accompanying drawings, which are incorporated herein, and constitute a part of
this disclosure, illustrate exemplary embodiments of the disclosed methods and systems in
which like reference numerals refer to the same parts throughout the different drawings.
Components in the drawings are not necessarily to scale, emphasis instead being placed upon
clearly illustrating the principles of the present disclosure. Also, the embodiments shown in the
figures are not to be construed as limiting the disclosure, but the possible variants of the method
and system according to the disclosure are illustrated herein to highlight the advantages of the
disclosure. It will be appreciated by those skilled in the art that disclosure of such drawings
includes disclosure of electrical components or circuitry commonly used to implement such
components.
[0027] FIG. 1 illustrates an exemplary block diagram representation of event routing manager
(ERM) architecture, in accordance with exemplary implementations of the present disclosure.
[0028] FIG.2 illustrates an exemplary implementation of an ERM Redundant model, in
accordance with exemplary implementations of the present disclosure.
[0029] FIG. 3 illustrates an implementation of the ERM method flow, in accordance with
exemplary implementations of the present disclosure.
7
[0030] FIG. 4 illustrates an exemplary block diagram of a computing device upon which the
features of the present disclosure may be implemented in accordance with exemplary
implementation of the present disclosure.
[0031] FIG. 5 illustrates an exemplary block diagram of a system for managing events using
an event routing management (ERM) module, in accordance with exemplary implementations
of the present disclosure.
[0032] FIG. 6 illustrates a method flow diagram for managing events using an event routing
management (ERM) module, in accordance with exemplary implementations of the present
disclosure.
[0033] The foregoing shall be more apparent from the following more detailed description of
the disclosure.
DETAILED DESCRIPTION
[0034] In the following description, for the purposes of explanation, various specific details
are set forth in order to provide a thorough understanding of embodiments of the present
disclosure. It will be apparent, however, that embodiments of the present disclosure may be
practiced without these specific details. Several features described hereafter may each be used
independently of one another or with any combination of other features. An individual feature
may not address any of the problems discussed above or might address only some of the
problems discussed above.
[0035] The ensuing description provides exemplary embodiments only, and is not intended to
limit the scope, applicability, or configuration of the disclosure. Rather, the ensuing description
of the exemplary embodiments will provide those skilled in the art with an enabling description
for implementing an exemplary embodiment. It should be understood that various changes may
be made in the function and arrangement of elements without departing from the spirit and
scope of the disclosure as set forth.
[0036] Specific details are given in the following description to provide a thorough
understanding of the embodiments. However, it will be understood by one of ordinary skill in
8
the art that the embodiments may be practiced without these specific details. For example,
circuits, systems, processes, and other components may be shown as components in block
diagram form in order not to obscure the embodiments in unnecessary detail.
[0037] Also, it is noted that individual embodiments may be described as a process which is
depicted as a flowchart, a flow diagram, a data flow diagram, a structure diagram, or a block
diagram. Although a flowchart may describe the operations as a sequential process, many of
the operations may be performed in parallel or concurrently. In addition, the order of the
operations may be re-arranged. A process is terminated when its operations are completed but
could have additional steps not included in a figure.
[0038] The word “exemplary” and/or “demonstrative” is used herein to mean serving as an
example, instance, or illustration. For the avoidance of doubt, the subject matter disclosed
herein is not limited by such examples. In addition, any aspect or design described herein as
“exemplary” and/or “demonstrative” is not necessarily to be construed as preferred or
advantageous over other aspects or designs, nor is it meant to preclude equivalent exemplary
structures and techniques known to those of ordinary skill in the art. Furthermore, to the extent
that the terms “includes,” “has,” “contains,” and other similar words are used in either the
detailed description or the claims, such terms are intended to be inclusive—in a manner similar
to the term “comprising” as an open transition word—without precluding any additional or
other elements.
[0039] As used herein, a “processing unit” or “processor” or “operating processor” includes
one or more processors, wherein processor refers to any logic circuitry for processing
instructions. A processor may be a general-purpose processor, a special purpose processor, a
conventional processor, a digital signal processor, a plurality of microprocessors, one or more
microprocessors in association with a (Digital Signal Processing) DSP core, a controller, a
microcontroller, Application Specific Integrated Circuits, Field Programmable Gate Array
circuits, any other type of integrated circuits, etc. The processor may perform signal coding
data processing, input/output processing, and/or any other functionality that enables the
working of the system according to the present disclosure. More specifically, the processor or
processing unit is a hardware processor.
9
[0040] As used herein, “a user equipment”, “a user device”, “a smart-user-device”, “a smartdevice”, “an electronic device”, “a mobile device”, “a handheld device”, “a wireless
communication device”, “a mobile communication device”, “a communication device” may
be any electrical, electronic and/or computing device or equipment, capable of implementing
the features of the present disclosure. The user equipment/device may include, but is not limited
to, a mobile phone, smart phone, laptop, a general-purpose computer, desktop, personal digital
assistant, tablet computer, wearable device or any other computing device which is capable of
implementing the features of the present disclosure. Also, the user device may contain at least
one input means configured to receive an input from at least one of a transceiver unit, a
processing unit, a storage unit, a detection unit and any other such unit(s) which are required
to implement the features of the present disclosure.
[0041] As used herein, “storage unit” or “memory unit” refers to a machine or computerreadable medium including any mechanism for storing information in a form readable by a
computer or similar machine. For example, a computer-readable medium includes read-only
memory (“ROM”), random access memory (“RAM”), magnetic disk storage media, optical
storage media, flash memory devices or other types of machine-accessible storage media. The
storage unit stores at least the data that may be required by one or more units of the system to
perform their respective functions.
[0042] As used herein “interface” or “user interface” refers to a shared boundary across which
two or more separate components of a system exchange information or data. The interface may
also be referred to a set of rules or protocols that define communication or interaction of one
or more modules or one or more units with each other, which also includes the methods,
functions, or procedures that may be called.
[0043] All modules, units, components used herein, unless explicitly excluded herein, may be
software modules or hardware processors, the processors being a general-purpose processor, a
special purpose processor, a conventional processor, a digital signal processor (DSP), a
plurality of microprocessors, one or more microprocessors in association with a DSP core, a
controller, a microcontroller, Application Specific Integrated Circuits (ASIC), Field
Programmable Gate Array circuits (FPGA), any other type of integrated circuits, etc.
10
[0044] As used herein the transceiver unit include at least one receiver and at least one
transmitter configured respectively for receiving and transmitting data, signals, information or
a combination thereof between units/components within the system and/or connected with the
system.
[0045] As discussed in the background section, the current known solutions have several
shortcomings. The present disclosure aims to overcome the above-mentioned and other
existing problems in this field of technology by providing method and system of managing
events using an event routing management (ERM) module.
[0046] Referring to FIG. 1, an illustration of an exemplary block diagram representation of
event routing manager (ERM) architecture [100], in accordance with exemplary
implementations of the present disclosure is shown.
[0047] The system comprises one or more microservices, a MS-x [104], an event routing
manager (ERM) module [102], a NoSQL database [124], an operation and management
(OAM) interface [126], a command line interface (CLI) [128], an elastic load balancer (ELB)
[130a], an ELB [132b], an ELB [134c] for a MS-a [130], a MS-b [132] and a MS-c [134]
respectively.
[0048] Further, the ERM module [102] comprises an elastic load balancer (ELB) [106], a
publish handler [108], a logging service [112], a bootstrap service unit [114], a database (DB)
client [116], a fault, configuration, accounting, performance and security (FCAPS) handler
[118], a notify handler [120] and a data modelling service [122]. In general, the logging service
[112] is used to record information about the events that occur within a system or application,
such as errors and user actions. The data modelling service [122] utilizes non-relational
database (such as NOSQL) for data modelling in to manage and control mapping of
information (such as events, publisher, subscriber).
[0049] The one or more microservices are implemented in a network function virtualization
(NFV) and software defined network (SDN) design function module which is based on
microservice architecture. Each of the one or more microservices have specific tasks and
functionality which each of the one or more microservices perform. Each of the microservices
in combination achieve overall functionality of the NFV SDN module.
11
[0050] The MS-x [104] refers to a publisher microservice. The MS-x [104] publishes an event
and sends it to the ELB [106] of the ERM [1042].
[0051] The ERM module [102] is a system to route events from one microservice to another
efficiently instead of adopting a crisscross model as is implemented in the known in the art
inventions, where each of the microservice communicates to the other microservices directly.
The ERM module [102] routes the events between each of the microservices by using a publish
subscribe model. The ERM module [102] maintains a list of a publisher microservice and a
subscriber microservice for each event from one or more events. Based on the event list, the
ERM module [102] delivers the events to each of the subscriber microservices. The ERM
module [102] is configured to perform the routing via an instance of the ERM module [102].
If one ERM instance goes down, a second instance may be configured to route the event.
[0052] The bootstrap service unit [114] in the ERM module [102] is configured to initiate all
the modules in the ERM [102] in order to manage event routing between the one or more
microservices.
[0053] The FCAPS handler [118] is conjured to manage faults, configuration, accounting,
performance and security related functionality of the ERM module [102]. The FCAPS handler
[118] is interfacing with the OAM [126] via an OAM client.
[0054] The notify handler [120] is configured to notify the published one or more events to
one or more subscriber microservice (MS) modules. The one or more subscriber MS modules
are components that receive notifications about the one or more events from the ERM module
[102]. Examples of the one or more subscriber MS modules include “User Notification
Service” that sends alerts or notifications to users (e.g., email, SMS) when certain events occur,
like a user registration or order placement, and “Analytics Service” that processes event data
to derive insights or generate reports. For example, it may analyse user registration events to
determine trends. In addition, example of the one or more subscriber MS modules may include
“Payment Processing Service” that is used for payment events to confirm transactions and may
trigger follow-up actions, such as sending receipts or updating user accounts.
12
[0055] The notify handler [120] may send a notification via message, alert, and the like. The
notify handler [120] may send the notification by parallel message delivery or sequential
message delivery.
[0056] The database (DB) client [116] is configured to interact with the NoSQL database [124]
to store a set of transactional logs data.
[0057] The OAM [126] is a central connecting point of all the microservices. The
microservices may register, deregister and reregister with the OAM [126] using the OAM
client.
[0058] The NoSQL database [124] refers to a non-relational database. The non-relational
database stores data in a non-tabular form and is more flexible than a traditional, SQL-based
database structure. The NoSQL database [124] interacts with the DB client [116] to store the
list of events, a context metadata information of each of the one or more microservices.
[0059] The CLI [128] refers to a text-based interface for a user to interact with the ERM [102].
The CLI [128] allows users to interact with the ERM [102] by entering text based commands
in a hardware like a keyboard, and the like. The CLI [128] does not use visual elements like
icons, etc.
[0060] The MS-a [130], the MS-b [132], and the MS-c [134] refers to the subscriber
microservice. The event published by the MS-x [104] may be routed to at least one of the MSa [130], the MS-b [132] and the MS-c [134] based on the event list stored at the ERM [102].
[0061] Referring to FIG. 2, an exemplary implementation of an ERM Redundant model [200],
in accordance with exemplary implementations of the present disclosure is shown.
[0062] As shown in FIG. 2, an exemplary architecture of the ERM Redundant model [200]
comprises a user interface (UI) [202] or a user experience (UX), an elastic load balancer (ELB)
1 [204], an ELB 2 [206], an identity and access management (IAM) unit [208], an event routing
manager (ERM) unit [102], an ELB 3 [212], an ELB 4 [214], a microservice system [216], an
elastic search database [218], an orchestration manager (OAM) interface [126], and a Central
Log Management System (CLMS) [222], wherein all the components are assumed to be
13
connected to each other in a manner as obvious to the person skilled in the art for implementing
features of the present disclosure. The microservice system [216] may comprise multiple
microservice instances a MS 1 [216-1], a MS 2 [216-2], a MS 3 [216-3],….., a MS N [216-N].
The CLMS [222] facilitates a centralised process to manage and monitor log information of all
microservices. In addition, the CLMS [222] helps to view the log or trace in one interface/GUI
in a distributed process or microservice deployment.
[0063] The UI [202] refers to a system to interact with the system architecture [200] by a user.
The user may be a system operator, a network consumer, and the like. The UI [202] may be
one of a graphical user interface (GUI), a command line interface, and the like. In an
implementation of the present disclosure, the UI [202] is the CLI [128] as depicted in FIG. 1.
The CLI refers to a text-based interface to interact with the system [200] as by the user. The
user may input text lines called as command lines in the CLI to access the event in the system.
[0064] The ELB 1 [204], the ELB 2 [206], the ELB 3 [212], and the ELB 4 [214] are exemplary
ELBs. The system may include ‘N’ number of ELBs. The ELBs are configured to distribute
the load on the microservice instances the MS 1 [216-2], the MS 2 [216-2], …. The MS N
[216-N]. The ELBs are further configured to distribute traffic of incoming events based on
availability of the microservice instances. The distribution of traffic enhances fault tolerance.
The fault tolerance refers to a capability of the microservice system [216] to handle failures
even when one of the microservice instances fail.
[0065] The IAM unit [208] refers to a unit that verifies identity of the user who is trying to
access a system, a network or a database. The verification may include entering a password, a
biometric, and the like. Based on the authentication, the IAM unit [208] may authorise access
for the user. The verification and the authorisation ensures that the user who is making the
access request gets access to the system, and the user has the right level of access to the system,
the database, or the network. Further, the IAM unit [208] is configured to define roles and
access privileges of the user.
[0066] The ERM module [102] is a system to route events from one microservice to another
efficiently instead of adopting a crisscross model as is implemented in the known in the art
inventions, where each of the microservice communicates to the other microservices directly.
The ERM [102] routes the events between each of the microservices by using a publish
14
subscribe model. The ERM [102] maintains a list of a publisher microservice and a subscriber
microservice for each event from one or more events. Based on the event list, the ERM [102]
delivers the events to each of the subscriber microservices.
[0067] The microservice system [216] refers to a system to perform a specific function. In one
example, the microservice system [216] includes one or more microservice instances. The one
or more microservice instances handles requests related to the specific function. Each of the
microservice instance may be served by at least two ELB units. For instance, the MS 1 [216-
1] may be served by the ELB 3 [212] and the ELB 4 [214]. The one or more MS instances may
have an active status or an inactive status.
[0068] The elastic search database [218] refers to a database that organizes data into
documents. The documents are grouped into different headers based on characteristics of the
data. The elastic search database [218] stores, performs searches and analyses the data quickly
and in real-time to give a response in milliseconds. The elastic search database [218] produces
a fast search response based on performing the search in the header instead of the whole data.
[0069] The OAM interface [126] is a framework that stores data of the instances of the
microservices. The data includes but may not be limited to an internet protocol (IP) address, a
port, a server disk location. The OAM interface [126] is further configured to maintain a pingpong communication with all the instances of the microservice system [216]. The OAM
interface [126] maintains the ping-pong communication to check whether an instance is
running or is down.
[0070] Referring to FIG. 3, an implementation of the ERM method flow [300], in accordance
with exemplary implementations of the present disclosure is shown.
[0071] In order to manage event routing, a bootstrap service unit [114] of ERM module [102]
is configured to initiate all modules of ERM module [102]. The ERM module [102] is further
configured to receive an event from a publisher MS1 [302] and a publisher MS2 [304].
[0072] Further, the ERM module [102] is configured to publish the event received from the
publisher handler [108].
15
[0073] The ERM module [102] is configured to notify via the notify handler [118] to at least
one of a subscriber MS1 [306], a subscriber MS2 [308] and a subscriber MS3 [310] based on
the list of events and the list of publisher MS and subscriber MS for each of the event from the
list of events stored in the NoSQL database [124]. If the subscriber MS modules are more than
one subscriber MS module for the event, the notify handler [506] may be configured to send
the notification via parallel message delivery. In another example, the notification may be sent
via sequential delivery. The parallel delivery refers to sending the notification to each of the
one or more subscriber MS modules together at same time, whereas the sequential delivery
refers to delivering the notification in a pre-defined sequence. The predefined sequence may
be defined by the user.
[0074] The notification may be provided to the one or more subscriber MS based on a context
metadata information provided by the one or more subscriber MS to the ERM module [102]
while subscribing to the event received from the publish handler [108].
[0075] For instance, as shown in FIG. 3, the subscriber MS1 [306] and the subscriber MS3
[308] are configured to be routed for event 1 published by the publisher MS1 [302], the ERM
module 1[02] may send the notification via the notify handler [120] to both the subscriber MS
via parallel message delivery or sequential message delivery. Similarly, the subscriber MS3
[310] is configured to be routed for event 2 published by the publisher MS2 [304], a notification
may be sent to the subscriber MS3 [310] for the event2.
[0076] The FCAPS handler [118] is configured to manage a set of performance counter data
and a set of alarm data. The set of performance counter data and the set of alarm data are
associated with functions of an operations and management (OAM) module [126] as depicted
in FIG. 1. Since the OAM module [126] is the central connecting point for all the microservices,
faults, configuration, accounting, performance and security of all the microservices may be
monitored via the OAM module [126]. In one example, the FCAPS handler [118] detects and
manages faults at each of the microservice. Further the FCAPS handler [118] may monitor and
manage changes in configuration of each of the microservice. Further, the FCAPS handler
[118] may track usage data and allocate costs to the user accordingly. Furthermore, the FCAPS
handler [118] may monitor performance metrics like one of a latency, bandwidth, etc. to ensure
that each of the microservice is performing properly. Further, the FCAPS handler [118] may
implement security policies and monitor each of the microservice for any potential breach to
16
ensure security of the ERM module [102]. The set of performance counter data corresponds to
collection and analysis of the performance metrics and the set of alarm data refers to monitoring
faults at each of the microservice. Based on detection of a fault, the FCAPS handler [118] may
generate an alarm to alert the user or to the OAM module [126] to fix the faults.
[0077] Furthermore, an ERM server is further configured to store transactional logs in a
database server (not shown in FIG. 3).
[0078] For each of the one or more events transmitted by the publishing MS1 [302] or the
publishing MS2 [304], the publish handler [108] is configured to send a response to the
publishing MS1 [302] or the publishing MS2 [304]. The response includes but may not be
limited to a delivery report to confirm delivery of the one or more events. In case of a timeout
for the published event from the one or more subscriber MS modules, the subscribe handler
[508] attempts re-delivery for a pre-defined number of times. The pre-defined number of times
may be defined by the ERM module [102]. In case the delivery of the published event fails
even after retrying for the pre-defined number of times, the publish handler [108] informs the
same to the one or more publishing MS modules in the response.
[0079] In one implementation, if the subscriber MS3 [310] sends a request to the ERM module
[102] to remove the subscriber MS3 [310] from the event, the context metadata is used to
identify the event from which subscription needs to be removed. By referencing an identifier
of the subscriber MS3 [310], the context metadata associated with the subscriber MS3 [310],
the subscriber MS3 [310] may efficiently locate and unsubscribe the subscriber MS3 [310]
from the event to ensure no further notifications is sent.
[0080] Referring to FIG. 4, an exemplary block diagram of a computing device [400] upon
which the features of the present disclosure may be implemented in accordance with exemplary
implementation of the present disclosure. In an implementation, the computing device [400]
may also implement a method for managing events using an event routing management (ERM)
module utilising the system. In another implementation, the computing device [400] itself
implements the method for managing events using an event routing management (ERM)
module, using one or more units configured within the computing device [400], wherein said
one or more units are capable of implementing the features as disclosed in the present
disclosure.
17
[0081] The computing device [400] may include a bus [402] or other communication
mechanism for communicating information, and a hardware processor [404] coupled with bus
[402] for processing information. The hardware processor [404] may be, for example, a
general-purpose microprocessor. The computing device [400] may also include a main memory
[406], such as a random access memory (RAM), or other dynamic storage device, coupled to
the bus [402] for storing information and instructions to be executed by the processor [404].
The main memory [406] also may be used for storing temporary variables or other intermediate
information during execution of the instructions to be executed by the processor [404]. Such
instructions, when stored in non-transitory storage media accessible to the processor [404],
render the computing device [400] into a special-purpose machine that is customized to
perform the operations specified in the instructions. The computing device [400] further
includes a read only memory (ROM) [408] or other static storage device coupled to the bus
[402] for storing static information and instructions for the processor [404].
[0082] A storage device [410], such as a magnetic disk, optical disk, or solid-state drive is
provided and coupled to the bus [402] for storing information and instructions. The computing
device [400] may be coupled via the bus [402] to a display [412], such as a cathode ray tube
(CRT), Liquid crystal Display (LCD), Light Emitting Diode (LED) display, Organic LED
(OLED) display, etc. for displaying information to a computer user. An input device [414],
including alphanumeric and other keys, touch screen input means, etc. may be coupled to the
bus [402] for communicating information and command selections to the processor [404].
Another type of user input device may be a cursor controller [416], such as a mouse, a trackball,
or cursor direction keys, for communicating direction information and command selections to
the processor [404], and for controlling cursor movement on the display [412]. This input
device typically has two degrees of freedom in two axes, a first axis (e.g., x) and a second axis
(e.g., y), that allow the device to specify positions in a plane.
[0083] The computing device [400] may implement the techniques described herein using
customized hard-wired logic, one or more ASICs or FPGAs, firmware and/or program logic
which in combination with the computing device [400] causes or programs the computing
device [400] to be a special-purpose machine. According to one implementation, the techniques
herein are performed by the computing device [400] in response to the processor [404]
executing one or more sequences of one or more instructions contained in the main memory
18
[406]. Such instructions may be read into the main memory [406] from another storage
medium, such as the storage device [410]. Execution of the sequences of instructions contained
in the main memory [406] causes the processor [404] to perform the process steps described
herein. In alternative implementations of the present disclosure, hard-wired circuitry may be
used in place of or in combination with software instructions.
[0084] The computing device [400] also may include a communication interface [418] coupled
to the bus [402]. The communication interface [418] provides a two-way data communication
coupling to a network link [420] that is connected to a local network [422]. For example, the
communication interface [418] may be an integrated services digital network (ISDN) card,
cable modem, satellite modem, or a modem to provide a data communication connection to a
corresponding type of telephone line. As another example, the communication interface [418]
may be a local area network (LAN) card to provide a data communication connection to a
compatible LAN. Wireless links may also be implemented. In any such implementation, the
communication interface [418] sends and receives electrical, electromagnetic or optical signals
that carry digital data streams representing various types of information.
[0085] The computing device [400] can send messages and receive data, including program
code, through the network(s), the network link [420] and the communication interface [418].
In an example, a server [430] might transmit a requested code for an application program
through the Internet [428], the ISP [426], the local network [422], the host [424] and the
communication interface [418]. The received code may be executed by the processor [404] as
it is received, and/or stored in the storage device [410], or other non-volatile storage for later
execution.
[0086] The present disclosure is implemented by a system [400] (as shown in FIG. 4). In an
implementation, the system [400] may include the computing device [400] (as shown in FIG.
4). It is further noted that the computing device [400] is able to perform the steps of a method
[500] (as shown in FIG. 5).
[0087] Referring to FIG. 5, an exemplary block diagram of a system [500] for managing events
using an event routing management (ERM) module is shown, in accordance with the exemplary
implementations of the present disclosure. The system [500] comprises at least one elastic load
balancer (ELB) unit [502], at least one publish handler [504], at least one notify handler [506],
19
at least one subscribe handler [508], at least one storage unit [510] and at least one fault,
configuration, accounting, performance and security (FCAPS) module [512]. Also, all of the
components/ units of the system [500] are assumed to be connected to each other unless
otherwise indicated below. As shown in the figures all units shown within the system should
also be assumed to be connected to each other. Also, in FIG. 5 only a few units are shown,
however, the system [500] may comprise multiple such units or the system [500] may comprise
any such numbers of said units, as required to implement the features of the present disclosure.
Further, in an implementation, the system [500] may be present in a user device to implement
the features of the present disclosure. The system [500] may be a part of the user device / or
may be independent of but in communication with the user device (may also referred herein as
a UE). In another implementation, the system [500] may reside in a server or a network entity.
In yet another implementation, the system [500] may reside partly in the server/ network entity
and partly in the user device.
[0088] The system [500] is configured for managing events using an event routing
management (ERM) module [102], with the help of the interconnection between the
components/units of the system [500]. In one example, a first instance of the ERM module
[102] is managing the events. In another example, if the first instance of the ERM module [102]
goes down, a second instance may be configured to manage the events.
[0089] The ELB unit [502] is configured to receive one or more events from one or more
publishing microservice (MS) modules. The one or more publishing MS modules corresponds
to microservices that generate and send the one or more events to the Event Routing Manager
(ERM) module [502] as depicted in FIG. 1. The one or more events are categorized based on
at least a type or purpose. The type of the one or more events includes but may not be limited
to a user registered event, a payment event, an order placed event. For example, the one or
more publishing MS modules detects a new user getting registered to a system, the one or more
publishing MS module is configured to detect ‘a user registered’. The user registered event
may be required by one or more subscriber microservice (MS) modules to perform a function
based on the registration of the user. In an embodiment, the type of the one or more events
defines what each event represents. Further, the purpose of the one or more events (e.g.,
Transactional, Informational, System Event) categorizes events based on their role, providing
context of the one or more events. In general, the context of an event refers to the specific
circumstances, conditions, and attributes surrounding its occurrence. The context of the one or
20
more events facilitates interpreting the event's significance and implications. The subscriber
MS modules refer to the microservices that are configured to perform specific task based on
the event. For instance, a microservice A may send a welcome message to the user, a
microservice B needs to monitor usage of the system by the user, etc. The ELB module [502]
transmits the one or more events to the publish handler [504].
[0090] The publish handler [504] is configured to publish the received one or more events. To
publish the received one or more events, the publisher handler [504] may receive and identify
the one or more events.
[0091] The notify handler [506] is configured to notify the published one or more events to the
one or more subscriber microservice (MS) modules. In one example, a notification may be sent
via a message, alert, and the like. In one example, if the subscriber MS modules are more than
one subscriber MS module for the event, the notify handler [506] may be configured to send
the notification via parallel message delivery. In another example, the notification may be sent
via sequential delivery. The parallel delivery refers to sending the notification to each of the
one or more subscriber MS modules together at same time, whereas the sequential delivery
refers to delivering the notification in a pre-defined sequence. The predefined sequence may
be defined by the user.
[0092] When the one or more subscriber MS modules subscribes to the ERM module [102],
the one or more subscriber MS modules are configured to provide a set of context metadata
information based on at least one of a subscribing action, and an unsubscribing action. The set
of context metadata is provided to the ERM module [102] using the subscribe handler [508].
The set of context metadata information corresponds to information required to identify nature
or context of the one or more events. The set of context metadata includes but may not be
limited to at least end point information associated with the one or more events, priority level
of the one or more events, and subscriber ID for each of the one or more events. The endpoint
information refers to an identifier of the endpoint, where the endpoint may be any physical
device connected to the network, including computers, laptops, mobile phones. An example of
the endpoint information may be an internet protocol (IP) address.
[0093] For example, if a payment event is triggered by a user's mobile app, the endpoint
information may include the mobile device's IP address and potentially other identifiers (like
21
device ID). In an example, the identifier of the endpoint may lie within the context metadata
that the subscriber MS module provide to the ERM module [102] through the subscribe handler
[508]. The identifier is not explicitly defined in a specific physical location, but rather are part
of a data structure managed by the subscribe handler [508].
[0094] In an example, the event can be defined as a notification of a significant change or
occurrence within the system [500] that other components or services might be interested in.
Examples of events include user actions (like signing up), system changes (like database
updates), or external triggers (like payment confirmations). Further, in an embodiment, event
may be of several types and may vary in nature (as defined above). Some of the events may be
transactional (e.g., a completed order), while others could be informational (e.g., a service
being updated). Each event carries data relevant to the change, which is essential for
subscribers to react appropriately.
[0095] The at least one of the subscribing action and the unsubscribing action is associated
with an event from the one or more events. The storage unit [510] stores a list of one or more
publisher MS modules and the one or more subscriber MS modules for each event from one or
more events. Based on the event list and the published one or more events, the one or more
subscriber MS modules may subscribe or unsubscribe to the ERM module [102].
[0096] When the one or more subscriber MS modules wants to subscribe to an event, the one
or more subscriber MS modules may communicate with the subscribe handler [508]. The one
or more subscriber MS modules may send a request to the ERM module [102] that includes the
context metadata. The context metadata is created and sent to the ERM module [102], enabling
the system to register the microservice as a subscriber to specific events. The ERM module
[102] stores the context metadata to route notifications. The context metadata are stored in the
storage unit [510].
[0097] When the one or more subscriber MS modules wants to unsubscribe from the event, the
one or more subscriber MS modules interacts with the ERM module via the subscribe handler
[508]. The one or more subscriber MS modules sends a request to the remove subscription for
the event. During unsubscribing, the context metadata is used to identify the event from which
subscription needs to be removed. By referencing an identifier of the one or more subscriber
MS modules and the context metadata associated with the one or more subscriber MS modules,
22
the subscribe handler [508] may efficiently locate and unsubscribe the one or more subscriber
MS modules from the event to ensure no further notifications is sent.
[0098] In an embodiment, the subscribe handler [508] is configured to check a status of the
one or more subscriber MS modules by identifying a first request from the one or more
subscriber MS modules for unsubscribing from a first target event. In addition, the subscribe
handler [508] is configured to remove a set of target context metadata information. The set of
target context metadata information is associated with identification of the first request. The
set of target context metadata information associated with identification of the first request
refers to how specific pieces of context metadata are linked to a particular action (like an
unsubscribe request) made by the subscriber microservice (MS) module. The target context
metadata may include all relevant details about the event, such as: “Subscriber ID” that
identifies which subscriber made the request, “Event Type” that specifies which event the
unsubscribe action pertains to, “Timestamp” that indicates when the request was made. The
identification of the first request means that the system [500] may track and distinguish this
particular unsubscribe request from others ensuring that when the subscriber requests to
unsubscribe from an event, the system [500] can accurately retrieve and reference the
associated metadata to process the request effectively.
[0099] The FCAPS module [512] is configured to manage a set of performance counter data
and a set of alarm data. The set of performance counter data and the set of alarm data are
associated with functions of an operations and management (OAM) module [126] as depicted
in FIG. 1. Since the OAM module [126] is the central connecting point for all the microservices,
faults, configuration, accounting, performance and security of all the microservices may be
monitored via the OAM module [126]. In one example, the FCAPS module [512] detects and
manages faults at each of the microservice. Further the FCAPS module [512] may monitor and
manage changes in configuration of each of the microservice. Further, the FCAPS module
[512] may track usage data and allocate costs to the user accordingly. Furthermore, the FCAPS
module [512] may monitor performance metrics like one of a latency, bandwidth, etc. to ensure
that each of the microservice is performing properly. Further, the FCAPS module [512] may
implement security policies and monitor each of the microservice for any potential breach to
ensure security of the ERM module [102]. The set of performance counter data corresponds to
collection and analysis of the performance metrics and the set of alarm data refers to monitoring
23
faults at each of the microservice. Based on detection of a fault, the FCAPS module [512] may
generate an alarm to alert the user or to the OAM module [126] to fix the faults.
[0100] The storage unit [510] stores in a database, a set of transactional logs data associated
with the one or more events. The set of transactional logs refers to a list of one or more publisher
MS modules and the one or more subscriber MS modules for each event from one or more
events. Based on the event list and the published one or more events, the one or more subscriber
MS modules may subscribe or unsubscribe to the ERM module [102].
[0101] Further in one example, for each of the one or more events transmitted by the one or
more publishing MS modules, the publish handler [504] is configured to send a response to the
one or more publishing MS modules. The response includes but may not be limited to a delivery
report to confirm delivery of the one or more events. In case of a timeout for the published
event from the one or more subscriber MS modules, the subscribe handler [508] attempts redelivery for a pre-defined number of times. The pre-defined number of times may be defined
by the system [500]. In case the delivery of the published event fails even after retrying for the
pre-defined number of times, the publish handler [504] informs the same to the one or more
publishing MS modules in the response.
[0102] Referring to FIG. 6, an exemplary method flow diagram [600] for managing events
using an event routing management (ERM) module, in accordance with exemplary
implementations of the present disclosure is shown. In an implementation the method [600] is
performed by the system [500]. Further, in an implementation, the system [500] may be present
in a server device to implement the features of the present disclosure. Also, as shown in FIG.
6, the method [600] starts at step [602].
[0103] At step [604], the method [600] comprises receiving, by an elastic load balancer (ELB)
unit [502], from one or more publishing microservice (MS) modules, one or more events. The
one or more publishing MS modules corresponds to microservices that generate and send the
one or more events to the Event Routing Manager (ERM) module [502] as depicted in FIG. 1.
The one or more events are categorized based on at least a type or purpose. The type of the one
or more events includes but may not be limited to a user registered event, a payment event, an
order placed event. For example, the one or more publishing MS modules detects a new user
getting registered to a system, the one or more publishing MS module is configured to detect
24
‘a user registered’. The user registered event may be required by one or more subscriber
microservice (MS) modules to perform a function based on the registration of the user. The
subscriber MS modules refers to the microservices that are configured to perform specific task
based on the event. For instance, a microservice A may send a welcome message to the user, a
microservice B needs to monitor usage of the system by the user, etc. The ELB module [502]
transmits the one or more events to the publish handler [504].
[0104] At step [606], the method [600] comprises publishing, by a publish handler [504], the
received one or more events facilitating dynamic event subscription management. To publish
the received one or more events, the publish handler [504] may receive and identify the one or
more events. In an embodiment, the dynamic event subscription management facilitates
flexible subscription to events, allowing subscriber services to dynamically manage their
interest in certain events, thereby enhancing responsiveness and adaptability to changing
business needs. In other words, the dynamic event subscription management allows services to
adjust their subscriptions to events based on their current needs or conditions. In an example,
dynamic event subscription herein refers to as analytics service that is dynamically subscribed
to following events: order creation, order update, order cancellation, and the like.
[0105] Next at step [608], the method [600] comprises notifying, by a notify handler [506], the
published one or more events to one or more subscriber microservice (MS) modules.
[0106] In one example, a notification may be sent via a message, alert, and the like. In one
example, if the subscriber MS modules are more than one subscriber MS module for the event,
the notify handler [506] may be configured to send the notification via parallel message
delivery. In another example, the notification may be sent via sequential delivery. The parallel
delivery refers to sending the notification to each of the one or more subscriber MS modules
together at same time, whereas the sequential delivery refers to delivering the notification in a
pre-defined sequence. The predefined sequence may be defined by the user.
[0107] When the one or more subscriber MS modules subscribes to the ERM module [102],
the one or more subscriber MS modules are configured to provide a set of context metadata
information based on at least one of a subscribing action, and an unsubscribing action. The set
of context metadata is provided to the ERM module [102] using the subscribe handler [508].
The set of context metadata information corresponds to information required to identify nature
25
or context of the one or more events. The set of context metadata includes but may not be
limited to at least end point information associated with the one or more events, priority level
of the one or more events, and subscriber ID for each of the one or more events. The endpoint
information refers to an identifier of the endpoint, where the endpoint may be any physical
device connected to the network, including computers, laptops, mobile phones. An example of
the endpoint information may be an internet protocol (IP) address. In an example, the identifier
of the endpoint may lie within the context metadata that the subscriber MS module provide to
the ERM module [102] through the subscribe handler [508]. The identifier is not explicitly
defined in a specific physical location, but rather are part of a data structure managed by the
subscribe handler [508].
[0108] The at least one of the subscribing action and the unsubscribing action is associated
with an event from the one or more events. The subscribe handler [508] is configured to
maintain a list of one or more publisher MS modules and the one or more subscriber MS
modules for each event from one or more events. Based on the event list and the published one
or more events, the one or more subscriber MS modules may subscribe or unsubscribe to the
ERM module [102].
[0109] When the one or more subscriber MS modules wants to subscribe to an event, the one
or more subscriber MS modules may communicate with the subscribe handler [508]. The one
or more subscriber MS modules may send a request to the ERM module [102] that includes the
context metadata. The context metadata is created and sent to the ERM module [102], enabling
the system to register the microservice as a subscriber to specific events. The ERM module
[102] stores the context metadata to route notifications. The context metadata are stored in the
storage unit [510].
[0110] When the one or more subscriber MS modules wants to unsubscribe from the event, the
one or more subscriber MS modules interacts with the ERM module via the subscribe handler
[508]. The one or more subscriber MS modules sends a request to the remove subscription for
the event. During unsubscribing, the context metadata is used to identify the event from which
subscription needs to be removed. By referencing an identifier of the one or more subscriber
MS modules and the context metadata associated with the one or more subscriber MS modules,
the subscribe handler [508] may efficiently locate and unsubscribe the one or more subscriber
MS modules from the event to ensure no further notifications is sent.
26
[0111] The FCAPS module [512] is configured to manage a set of performance counter data
and a set of alarm data. The set of performance counter data and the set of alarm data are
associated with functions of an operations and management (OAM) module [126] as depicted
in FIG. 1. Since the OAM module [126] is the central connecting point for all the microservices,
faults, configuration, accounting, performance and security of all the microservices may be
monitored via the OAM module [126]. In one example, the FCAPS module [512] detects and
manages faults at each of the microservice. Further the FCAPS module [512] may monitor and
manage changes in configuration of each of the microservice. Further, the FCAPS module
[512] may track usage data and allocate costs to the user accordingly. Furthermore, the FCAPS
module [512] may monitor performance metrics like one of a latency, bandwidth, etc. to ensure
that each of the microservice is performing properly. Further, the FCAPS module [512] may
implement security policies and monitor each of the microservice for any potential breach to
ensure security of the ERM module [102]. The set of performance counter data corresponds to
collection and analysis of the performance metrics and the set of alarm data refers to monitoring
faults at each of the microservice. Based on detection of a fault, the FCAPS module [512] may
generate an alarm to alert the user or to the OAM module [126] to fix the faults.
[0112] Next at step [610], the method [600] comprises storing, by the storage unit [510], in a
database, a set of transactional logs data associated with the one or more events. The set of
transactional logs refers to a list of one or more publisher MS modules and the one or more
subscriber MS modules for each event from one or more events. Based on the event list and
the published one or more events, the one or more subscriber MS modules may subscribe or
unsubscribe to the ERM module [102].
[0113] Further, in one example, for each of the one or more events transmitted by the one or
more publishing MS modules, the publish handler [504] is configured to send a response to the
one or more publishing MS modules. The response includes but may not be limited to a delivery
report to confirm delivery of the one or more events. In case of a timeout for the published
event from the one or more subscriber MS modules, the subscribe handler [508] attempts redelivery for a pre-defined number of times. The pre-defined number of times may be defined
by the system [500]. In case the delivery of the published event fails even after retrying for the
pre-defined number of times, the publish handler [504] informs the same to the one or more
publishing MS modules in the response.
27
[0114] The method [600] terminates at step [612].
[0115] The present disclosure further discloses a non-transitory computer readable storage
medium storing instructions for managing events using an event routing management (ERM)
module [102], the instructions include executable code which, when executed by one or more
units of a system, cause the elastic load balancer (ELB) unit [502] to receive, from one or more
publishing microservice (MS) modules, one or more events. The instructions when executed
by the system further cause the publish handler unit [504] to publish the received one or more
events facilitating dynamic event subscription management. The instructions when executed
by the system further cause the notify handler unit [506] to notify the published one or more
events to one or more subscriber microservice (MS) modules. The instructions when executed
by the system further cause the storage unit [510] to store, in a database, a set of transactional
logs data associated with the one or more events.
[0116] As is evident from the above, the present disclosure provides a technically advanced
solution for managing events using an event routing management (ERM) module. The present
solution provides a system and a method for event routing management. The system and
method provided by the present solution acts as a central service to keep information of all
events in a network. The present disclosure further enables storing transactional logs in a
database server, which would be helpful to debug in case of event failure. The system and
method allows addition of new events to an ERM server dynamically, thereby reducing code
overhead in the event any microservice server wants to use same event functionality which is
already being used by other microservice server. Further, the present disclosure provides a
solution that enables parallel or sequential message delivery can be defined for each event that
has multiple subscriber server. The present disclosure further provides a solution that supports
redundancy in the event one ERM server goes down.
[0117] While considerable emphasis has been placed herein on the disclosed implementations,
it will be appreciated that many implementations can be made and that many changes can be
made to the implementations without departing from the principles of the present disclosure.
These and other changes in the implementations of the present disclosure will be apparent to
those skilled in the art, whereby it is to be understood that the foregoing descriptive matter to
be implemented is illustrative and non-limiting.
28
[0118] Further, in accordance with the present disclosure, it is to be acknowledged that the
functionality described for the various components/units can be implemented interchangeably.
While specific embodiments may disclose a particular functionality of these units for clarity, it
is recognized that various configurations and combinations thereof are within the scope of the
disclosure. The functionality of specific units as disclosed in the disclosure should not be
construed as limiting the scope of the present disclosure. Consequently, alternative
arrangements and substitutions of units, provided they achieve the intended functionality
described herein, are considered to be encompassed within the scope of the present disclosure.
29
We Claim:
1. A method for managing events using an event routing management (ERM) module
[102], the method comprising:
- receiving, by an elastic load balancer (ELB) unit [502], from one or more publishing
microservice (MS) modules, one or more events;
- publishing, by a publish handler [504], the received one or more events facilitating
dynamic event subscription management;
- notifying, by a notify handler [506], the published one or more events to one or
more subscriber microservice (MS) modules; and
- storing, by a storage unit [510], in a database, a set of transactional logs data
associated with the one or more events.
2. The method as claimed in claim 1, wherein the one or more publishing MS modules
correspond to microservices that generate and send the one or more events to the Event
Routing Manager (ERM) module [102].
3. The method as claimed in claim 1, wherein the step of notifying, by the notify handler
[506], the published one or more events to the one or more subscriber MS modules is
based on a set of context metadata information associated with each of the one or more
events.
4. The method as claimed in claim 3, wherein the set of context metadata information
comprises details to identify context of the one or more events, wherein the set of
context metadata comprises at least an end point information associated with the one or
more events, priority level of the one or more events, and subscriber ID for each of the
one or more events.
5. The method as claimed in claim 1, wherein the one or more events are categorized based
on at least a type or purpose, wherein the one or more events comprises at least one of:
a user registered event, a payment event, and an order placed event.
6. The method as claimed in claim 3, wherein the method comprises providing, by the one
or more subscriber MS modules, to the ERM module [102] using a subscribe handler
[508], wherein the set of context metadata information based on at least one of a
subscribing action, and an unsubscribing action, and wherein the at least one of the
30
subscribing action, and the unsubscribing action is associated with an event from the
one or more events.
7. The method as claimed in claim 3, wherein the method comprises receiving, by each of
the one or more subscriber MS modules, a notification associated with one or more
target events from the published one or more events, and wherein the notification is
based on the subscribing action associated with the one or more target events.
8. The method as claimed in claim 3, wherein the method comprises checking, by the
subscribe handler [508], a status of the one or more subscriber MS modules, and
wherein the step of checking the status of the one or more subscriber MS modules
comprises identifying, by the subscribe handler [508], a first request from the one or
more subscriber MS modules for unsubscribing from a first target event.
9. The method as claimed in claim 6, wherein the method comprises removing, by the
subscribe handler [508], a set of target context metadata information, and wherein the
set of target context metadata information is associated with identification of the first
request.
10. The method as claimed in claim 1, wherein the method comprises managing, by a fault,
configuration, accounting, performance and security (FCAPS) unit, a set of
performance counter data and a set of alarm data, and wherein the set of performance
counter data and the set of alarm data are associated with functions of an operations and
management (OAM) module connected with at least the ERM module [102].
11. The method as claimed in claim 1, wherein the set of transactional logs data comprises
at least one of: context metadata information, FCAPS performance counter data,
FCAPS alarm data, types of microservice nodes, registration data of the microservice
nodes, deregistration data of the microservice nodes, subscription data of the
microservice nodes, and unsubscribe data of the microservice nodes for the one or more
events.
12. A system for managing events using an event routing management (ERM) module
[102], the system comprising:
- an elastic load balancer (ELB) unit [502] configured to receive, from one or more
publishing microservice (MS) modules, one or more events;
31
- a publish handler [504] connected to at least the ELB unit [502], and configured to
publish the received one or more events facilitating dynamic event subscription
management;
- a notify handler [506] connected to at least the publish handler [504], and
configured to notify the published one or more events to one or more subscriber
microservice (MS) modules; and
- a storage unit [510] connected to at least the notify handler [506], and configured
to store, in a database, a set of transactional logs data associated with the one or
more events.
13. The system as claimed in claim 12, wherein the one or more publishing MS modules
correspond to microservices that generate and send the one or more events to the Event
Routing Manager (ERM) module [102].
14. The system as claimed in claim 12, wherein the notify handler [506] is configured to
notify the published one or more events to the one or more subscriber MS modules,
based on a set of context metadata information associated with each of the one or more
events.
15. The system as claimed in claim 12, wherein the set of context metadata information
comprises details to identify nature or context of the one or more events, wherein the
set of context metadata comprises at least end point information associated with the one
or more events, priority level of the one or more events, and subscriber ID for each of
the one or more events.
16. The system as claimed in claim 12, wherein the one or more events are categorized
based on at least a type or purpose, wherein the one or more events comprises at least
one of: a user registered event, a payment event, and an order placed event.
17. The system as claimed in claim 12, wherein the one or more subscriber MS modules
are configured to provide, to the ERM module [102] using a subscribe handler [508],
wherein the set of context metadata information based on at least one of a subscribing
action, and an unsubscribing action, and wherein the at least one of the subscribing
action and the unsubscribing action is associated with an event from the one or more
events.
32
18. The system as claimed in claim 14, wherein each of the one or more subscriber MS
modulesis configured to receive a notification associated with one or more target events
from the published one or more events, and wherein the notification is based on the
subscribing action associated with the one or more target events.
19. The system as claimed in claim 17, wherein the subscribe handler [508] is configured
to check a status of the one or more subscriber MS modules, and wherein, to check the
status of the one or more subscriber MS modules, the subscribe handler [508] is
configured to identify a first request from the one or more subscriber MS modules for
unsubscribing from a first target event.
20. The system as claimed in claim 17, wherein the subscribe handler [508] is configured
to remove a set of target context metadata information, and wherein the set of target
context metadata information is associated with an identification of the first request.
21. The system as claimed in claim 12, wherein the system comprises a fault, configuration,
accounting, performance and security (FCAPS) module [512], wherein the FCAPS
module [512] is configured to manage a set of performance counter data and a set of
alarm data, and wherein the set of performance counter data and the set of alarm data
are associated with functions of an operations and management (OAM) module
connected with at least the ERM module [102].
22. The system as claimed in claim 12, wherein the set of transactional logs data comprises
at least one of: context metadata information, FCAPS performance counter data,
FCAPS alarm data, type of microservice nodes, registration data of the microservice
nodes, deregistration data of the microservice nodes, subscription data of the
microservice nodes, and unsubscribe data of the microservice nodes for the one or more
events.