Participants: Anjana Fernando, Manuranga Perera, Mohanadarshan
Vivekanandalingam, Paul Fremantle, Sanjiva Weerawarana, Senaka Fernando,
Shammi Jayasinghe, Srinath Perera, Sumedha Rubasinghe.
we have different event models
1.
Registry model
2.
Amila Event model - also used in MB WS-Eventing things that is dead
3.
ESB event thing ??
4.
For sending emails now CEP has a new one ..
5.
Registry also has send email thing ..
We agree JMS as the integration thing
Need MB with something not heavy .. like on MySQL
(side discussion : are we complicating our products by packing too many
components such as GIT ? )
like to have a single API that switch between internal and switch
In BAM we need a way to control amount of events actually send the BAM ..
so the user do not have to worry about that .. We need log4j levels and
appenders .. something like that with BAM event publishers ..
Another is email sending, but we decided this is different fom events. This
is inside in CEP, Reg, DSS, BAM. Need to merge.
Separation of Concerns
It was recognized that following applications are separate, and therefore
should be handled by different frameworks.
-
Logging
-
Data Publishing ( for analysis)
-
Notification
But some features, like filtering log level and topic (classname as in
log4j.properties) would be useful in each layer.
Notifications for people (via web UI or e-mail) is also different from the
notifications between components but former can possibly be built on latter.
Proposed Architecture for Notification
-
Will be based on JMS (messaging with hierarchical topics)
-
MB should have a light weight (non-Cassandra-based implementation)
-
MB config should be same across products
-
This embed MB will provide an API to which other component can publish
and listen to
-
Selected message queues can be persisted for later browsing (future
feature and implemented outside of MB. This is pretty much message box)
-
need a message box and with last mesages, like email message
-
distributed pub/sub across many machine - jms with lightweight version
of MB
-
should be fast when there are no listeners
Action Points
-
MB team
-
refactor “Amila” Event Component (shouldn’t have dependency on Axis).
-
implement a lightweight embeddable MB subset.
-
Fix how MB is configured within each product
-
BAM team
-
refactor BAM event publisher. (unrelated to notification system)
-
make the threading part independent from actual sender.
-
provide new appenders for data publisher (starting with google
analytics, thrift)
-
actual publishing should be turn on/off using log4j like config
We discussed and decided social / personal events are different from wso2
event model events due to security and persistence
--
With regards,
*Manu*ranga Perera.
phone : 071 7 70 20 50
mail : [email protected]
_______________________________________________
Architecture mailing list
[email protected]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
