Hi Prabath, The reason behind using a single configuration file is to avoid the complexity of maintaining multiple configuration files and at the same time, since the configuration parsing is done in a central module and passes relevant configurations to relevant Notification Sending modules, Notification Sending components do not need to build their own configuration parses. Instead they can be initiated from the configuration passed by the management module.
At the same time, with this implementation, Notification Sending modules can have/maintain their own configuration files as well. On Tue, Dec 16, 2014 at 9:14 PM, Prabath Ariyarathna <[email protected]> wrote: > > Hi Hasitha. > > Is there are any special reason to use single configuration file for all > Notification sending modules instead of using a separate file for each > component? > > Regard, > > On Tue, Dec 16, 2014 at 7:57 PM, Hasintha Indrajee <[email protected]> > wrote: > >> Adding image >> >> *An Overview of the Architecture * >> >> >> >> >> On Tue, Dec 16, 2014 at 7:51 PM, Hasintha Indrajee <[email protected]> >> wrote: >>> >>> Hi all, >>> >>> The idea is to implement a generic and light weight Notification >>> Management module which is responsible for registering Notification Sending >>> modules dynamically, initialize them with relevant configurations, and >>> trigger the notification sending module on a particular event type if the >>> particular event type is subscribed by a Notification Sending module. >>> >>> E.g. suppose we need to call a REST endpoint with JSON content (PEP) on >>> an event of XACML policy update. The event is published to Notification >>> Management Component by the XACML component, which will trigger REST/JSON >>> notification sending module with the published event. >>> >>> *Notification Management Component* >>> >>> >>> - Exposes an interface for Notification Sending modules to register >>> and publish events. [1] >>> - Events are mediated from this management Component. >>> - Events published by publishers are queued and distributed to >>> Notification Sending modules asynchronously using a configurable size >>> thread pool. >>> - Events are published to Notification Sending Modules only if the >>> particular module is subscribed to the published event. >>> - Holds a common configuration file for all Notification Sending >>> modules and builds it at the time of initialization. At the time of >>> registering a Notification Sending module, it will be initialized using >>> relevant configurations to particular module. >>> - This configuration file is secured using secure vault. A sample >>> Configuration file is included below. >>> >>> *A Notification Sending Module (Email Message Module, REST/JSON module, >>> SMS module)* >>> >>> >>> - Modules are implemented and registered as OSGi services. New >>> Notification Sending Modules can be implemented and registered as per >>> requirements (e.g. - SMS sending module). >>> - A module can subscribe for several events. Each module is >>> configurable per event type. >>> - The two existing modules (Email, REST/JSON) have configurable >>> endpoints per event type and configurable templates per event type and >>> endpoint. These templates have place holders which will be replaced by >>> configurations from module level, subscription level and published event >>> information respectively. >>> >>> >>> *An Overview to the Architecture. * >>> >>> >>> >>> ** >>> >>> Following is a sample configuration property file which is read by >>> Notification Management Component. This could be used to hold properties >>> for all Notification Sending Modules, and will be passed relevant >>> properties to the init() method upon initialization. Sensitive information >>> is encrypted using secure vault. >>> >>> # name of the notification sending module >>> module.name.1=email >>> # name of the subscription >>> email.subscription.1=userOperation >>> # subscription properties >>> email.subscription.userOperation.template=templatePath/template1 >>> email.subscription.userOperation.salutation=Admin >>> email.subscription.userOperation.subject=User operation change >>> information >>> # name of the endpoint >>> email.subscription.userOperation.endpoint.1=privateMail >>> # endpoint properties >>> email.subscription.userOperation.endpoint.privateMail.address= >>> [email protected] <[email protected]> >>> email.subscription.userOperation.endpoint.privateMail.salutation=Admin >>> private mail >>> email.subscription.userOperation.endpoint.privateMail.subject= User >>> operation change information to private mail >>> >>> email.subscription.userOperation.endpoint.2=officeMail >>> email.subscription.userOperation.endpoint.officeMail.address= >>> [email protected] <[email protected]> >>> >>> email.subscription.2=policyUpdate >>> email.subscription.policyUpdate.template=templatePath/template2 >>> email.subscription.policyUpdate.salutation=Admin >>> email.subscription.policyUpdate.subject= policy update information mail >>> email.subscription.policyUpdate.endpoint.1=privateMail >>> email.subscription.policyUpdate.endpoint.privateMail.address= >>> [email protected] <[email protected]> >>> email.subscription.policyUpdate.endpoint.privateMail.salutation=Admin >>> private mail >>> email.subscription.policyUpdate.endpoint.privateMail.subject= policy >>> update information to private mail >>> >>> module.name.2=json >>> json.subscription.1=userOperation >>> json.subscription.userOperation.template=templatePath/jsonTemplate >>> json.subscription.userOperation.jsonId=3232 >>> json.subscription.userOperation.endpoint.1=pepEndpoint1 >>> json.subscription.userOperation.endpoint.pepEndpoint1.address= >>> https://localhost:8080/testEndpoint1 >>> >>> json.subscription.userOperation.endpoint.pepEndpoint1.username=testUsername >>> json.subscription.userOperation.endpoint. >>> # using secure vault >>> >>> pepEndpoint2.password=secretAlias:json.subscription.userOperation.endpoint.pepEndpoint2.password >>> >>> [1] >>> https://github.com/hasinthaindrajee/carbon-identity/blob/MsgComponents/components/identity/org.wso2.carbon.identity.notification.mgt/src/main/java/org/wso2/carbon/identity/notification/mgt/NotificationSendingModule.java >>> >> >> _______________________________________________ >> Architecture mailing list >> [email protected] >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > > -- > > *Prabath Ariyarathna* > > *Associate Technical Lead* > > *WSO2, Inc. * > > *lean . enterprise . middleware * > > > *Email: [email protected] <[email protected]>* > > *Blog: http://prabu-lk.blogspot.com <http://prabu-lk.blogspot.com>* > > *Flicker : https://www.flickr.com/photos/47759189@N08 > <https://www.flickr.com/photos/47759189@N08>* > > *Mobile: +94 77 699 4730 * > > > > > > > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > >
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
