Hi Patnachai, Thanks for the nice explanation, I do not have any issues with this design(It looks good) but I have seen some unnecessary things in the code !
I will change the bad naming of classes in GFac, I prefer using the objects parse in notifier methods so that we know who sent these notificaition ( we always parse "this" as the input for oject). i will try to change the notification message. Regards Lahiru On Fri, Sep 16, 2011 at 2:27 PM, Patanachai Tangchaisin < [email protected]> wrote: > 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 > -- System Analyst Programmer PTI Lab Indiana University
