> > You mean notification management component parse common configuration file > and pass relevant configurations to the notification sending modules at the > time of registering > Yes, Management component passes the relevant configurations and initialize them.
or notification sending modules retrieve required configurations from the > management module at the real time? > Notification Sending Modules do not retrieve configurations themselves. > > If configurations are injected to relevant notification module at the time > of registering, do we need to restart the notification sending OSGI bundles > to effect any configuration changes? > Yes, Anyway configurations are only effective after restarting. > > > On Wed, Dec 17, 2014 at 10:09 AM, Hasintha Indrajee <[email protected]> > wrote: >> >> 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 >> >> > > -- > > *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
