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
