Why parsing unnecessary Object to all the methods in Subject interface - GFac core

[Lahiru Gunathilake <gl...@gmail.com>]

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



-- 
System Analyst Programmer
PTI Lab
Indiana University

Re: Why parsing unnecessary Object to all the methods in Subject interface - GFac core

[Lahiru Gunathilake <gl...@gmail.com>]

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 <
ptangcha@umail.iu.edu> 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

Re: Why parsing unnecessary Object to all the methods in Subject interface - GFac core

[Patanachai Tangchaisin <pt...@umail.iu.edu>]

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