On 09/16/2011 01:06 PM, Lahiru Gunathilake wrote:
Hi Devs,
I did a quick review of gfac architecture, while doing that I had a feeling
that gfac-core notification implementation is having unnecessary complexity.
I noticed following things.
It has a base interface called Subject which is expecting Ojbect to most of
the methods and it never used.
Then ExecutionContext has a Notifier as a member and it has set of
Notifiable object and each notifiable has again Notifier (workflow-tracking
Notifier ojbect) objects.
I think class naming is very confuse when someone look in to the code
because there are two type of Notifier objects, I think we need to change
the class names...
Regards
Lahiru
Hi Lahiru,
I think the reason is "Notifier" is a common name.
And yes, you can change it to GfacNotifiable or GfacNotifier or anything
else.
For GFAC architecture, let's assume that it doesn't have
Workflow-tracking notifier implementation.
Notification implementation in GFAC is designed base on "Observer" pattern.
- "Subject" is a topic that can be used in the system.
- "Notifiable" is one who is notified.
- "Notifier" is one who send out notification to whoever listens
(Notifiable).
Like publisher/subscriber, so there can be multiple Notifiables for one
Notifier (Multiple subscribers listens to one publisher) or One
Notifiable can listen to multiple Notifier (a subscriber subscribes to
multiple publishers).
For example,
- Subject can be about startOfExecution, fileTransferDone, etc.
- SystemOutNotifiable is a Notifiable that will write everything that it
hears (from Notifier) to System.out.
- SystemOutNotifier can write down everything that it is going to send
out to System.out and also it might want to change messages before
sending out to listeners by adding its name in front of the messages.
If SystemOutNotifiable registers itself with SystemOutNotifier, then for
a notification there will be 2 stand output one from Notifier (without
modification) and one from Notifiable (with the Notifier's name in front
of the message).
Right now there is only one implementation of Notifier
(DefaultNotifier). Its job is simple, send out whatever it gets from
invoker (GFAC) to Notifiables who register with it.
So, back to Workflow-tracking Notifiable. From the GFAC point of view,
it doesn't know (and care) what Notifiables will do when they are
notified. Actually, it doesn't either know what Notifier will do. It
just gets Notifier object and send notification out according to Subject
when it needs. In case of WorkflowTrackingNotifiable, its job is to
listen to a notification (Subject) sent out from GFAC and send this
notification out in the WorkflowTracking context by using Notifier (in
WorkflowTracking package).
It is possible to implement WorkflowTracking context as a GFAC's
Notifier. For example, it converts all Gfac notification context to
WorkflowTracking context and send this context out to whoever listens
(Notifiables).
About, "Object" in the Subject is used to identify GFAC components who
send out the notification e.g. Provider, Scheduler, etc. I think we can
remove it if it is not used. (Notifiable don't want to know which
components send out the message). It is overly designed.
I don't know if this is too complex or not. I think we can simplify it
if we want or change to other design pattern. For example, if we just
want a simpler interface for Subject, we can remove unnecessary method
and add more specific Subject class for each GFAC Components or Abstract
class with intercept and interpret a message before sent out.
Regards,
Patanachai Tangchaisin
