You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Alex Karasulu <ao...@bellsouth.net> on 2004/02/18 05:44:16 UTC
[RT] Notification pattern has interesting effects on IoC
Hi all,
While looking at the frontend of the Eve server I began to realize a trend
emerging after I introduced a central publish and subscribe facility. The
pattern decouples components by enabling communication using events and the
notifier pattern. This also lead to the disappearence of methods on service
interfaces.
So the dependency graph turns into a star with all components depending on
the event router, hub, bus or whatever you call it in the center. Event
types and interfaces essentially become the dependency as opposed to the
service interfaces. This way you can introduce new subscribers and
publishers. Also the dynamic rerouting of events is possible at runtime.
What this means is that the dependencies between components can change on
the fly! Wow not a bad thang.
What does this mean for service interfaces? Well they start looking bleak
because the Subscriber interface replaces them. Basically methods are called
internally by the Subscriber handling code on the component itself rather
than exposing them on the service interface for direct calls by what are now
publishers. This is crazy my service interfaces are all empty now!
Alex
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] Notification pattern has interesting effects on IoC
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Friday 27 February 2004 00:02, Berin Loritsch wrote:
> Niclas Hedhman wrote:
> :) Honestly, I don't like the "only event" approach, and events do address
Me neither.
> certain issues nicely. It's when we get into synchronous responses that
> the event approach really breaks down as far as simplicity goes.
>
> THey lend themselves much nicer to non-response oriented artchitectures.
Agree!
Niclas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] Notification pattern has interesting effects on IoC
Posted by Berin Loritsch <bl...@d-haven.org>.
Niclas Hedhman wrote:
>
> As for synchronization in firing of events, it boils down to; "Can a Listener
> recieve an event after it has de-registered?"
> If the answer is "Yes, that is ok." then synchronization can be minimized.
> If the answer is "No", one should review that requirement ;o)
>
>
> I am not negative to Events at all. In fact, been depending on them more than
> most.
:) Honestly, I don't like the "only event" approach, and events do address
certain issues nicely. It's when we get into synchronous responses that
the event approach really breaks down as far as simplicity goes.
THey lend themselves much nicer to non-response oriented artchitectures.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] Notification pattern has interesting effects on IoC
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Thursday 26 February 2004 23:40, Berin Loritsch wrote:
> Leo Sutic wrote:
> >>Not sure. In very 'busy' systems, it becomes a challange to
> >>write the 'hub', so that you don't need to synchronize the
> >>'addListener' and 'fireEvent' parts, because otherwise it
> >>becomes a bottleneck.
> >
> > Listeners are added and removed comparatively rarely compared
> > to the number of fireEvent calls, so a copy-on-write list
> > can eliminate much synchronization.
>
> The GUIApp EventBus is very simple, and it separates out the
> need for synchronous and asynchronous events. If you need
> synchronous events we use the SwingUtils class to ensure all
> those events are fired in one thread. The asynchronous events
> can happen in any order.
>
> It's not hard.
It is harder than you may consider in the first instance...
Assuming that your component maintains State and is ThreadSafe, experience
tells me that it is NOT possible to fire events within synchronized blocks,
which leads to some form of queueing/asynch mechanism.
In the case of the EventBus, I agree that one can "throw in more effort" to
get these picky details right, once and for all.
As for synchronization in firing of events, it boils down to; "Can a Listener
recieve an event after it has de-registered?"
If the answer is "Yes, that is ok." then synchronization can be minimized.
If the answer is "No", one should review that requirement ;o)
I am not negative to Events at all. In fact, been depending on them more than
most.
Niclas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] Notification pattern has interesting effects on IoC
Posted by Berin Loritsch <bl...@d-haven.org>.
Leo Sutic wrote:
>
>>Not sure. In very 'busy' systems, it becomes a challange to
>>write the 'hub', so that you don't need to synchronize the
>>'addListener' and 'fireEvent' parts, because otherwise it
>>becomes a bottleneck.
>
>
> Listeners are added and removed comparatively rarely compared
> to the number of fireEvent calls, so a copy-on-write list
> can eliminate much synchronization.
The GUIApp EventBus is very simple, and it separates out the
need for synchronous and asynchronous events. If you need
synchronous events we use the SwingUtils class to ensure all
those events are fired in one thread. The asynchronous events
can happen in any order.
It's not hard.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] Notification pattern has interesting effects on IoC
Posted by Berin Loritsch <bl...@d-haven.org>.
Niclas Hedhman wrote:
> On Friday 27 February 2004 01:15, Berin Loritsch wrote:
>
>>Niclas Hedhman wrote:
>>THe biggest issue I had to overcome (and it did not
>>take me long to develop some guidelines to avoid it completely) is the
>>icky circular event logic.
>
>
> What is your solution? Sticking the "original source" into the event?
> In my systems, it is less of an issue, as it is very rare that consumer and
> producer are linked in "both directions", but it happens, and I use two
> solutions;
Funny you should ask....
http://d-haven.org/modules/news/article.php?storyid=12
I already have that answered.
> Niclas
>
> B.t.w Nice seeing you active in Avalon :o) !
:) Thanks.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] Notification pattern has interesting effects on IoC
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Friday 27 February 2004 01:15, Berin Loritsch wrote:
> Niclas Hedhman wrote:
> THe biggest issue I had to overcome (and it did not
> take me long to develop some guidelines to avoid it completely) is the
> icky circular event logic.
Can be somewhat difficult. I know it is more common in GUI apps, since you
often are both the consumer and producer of the same EventType (property
modified for instance).
What is your solution? Sticking the "original source" into the event?
In my systems, it is less of an issue, as it is very rare that consumer and
producer are linked in "both directions", but it happens, and I use two
solutions;
1. The event that arrives back at the source doesn't trigger a new event,
since the incoming event has "no effect", for instance, the event results in
an value update, but a new event is only fired when the value has actually
changed (and in some cases, I also use an "minimum change" for float values).
2. A ThreadLocal variable that are set prior to the fireEvent() and checked on
event entries. A very efficient way to 'disable' incoming events.
> :/ It all comes back to the problem at hand. Until you can prove it is
> : really
> a problem, it is merely a case of misunderstanding the system. Too rigid a
> spec makes the software bloated and slow, while too loose a spec makes
> things prone to breaking unexpectedly.
Agree.
> I am still out on my verdict which one is preferable to err towards. One
> might argue that you are "safer" with the over designed system, but I
> wonder if that is really the case.
I have been too much in Jini-land, where things are very liquid. But once one
get the hang of writing services that are more autonomous it becomes really
neat.
> I may have missed it. I am just saying that in many cases, you won't need
> the availability requirement.
Exactly, I am not saying that it is always required, just as initialize() is
not always required.
But, if an AvailabilityAware notion existed in AF, it would be possible to
implement more interesting systems.
But with such a contract in AF, it would be possible to implement all kinds of
cool features in the container; hot (re)deploy, Jini, moving agents,
self-healing systems, load balancing clusters...
Without it, it is not really possible without very specific components :o(
This is somewhat independent of EventDriven programming, but Availability can
support the EventDriven pattern.
Niclas
B.t.w Nice seeing you active in Avalon :o) !
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
[OT] Religious affiliation (was Re: [RT] Notification pattern has
interesting effects on IoC)
Posted by Berin Loritsch <bl...@d-haven.org>.
Niclas Hedhman wrote:
> On Friday 27 February 2004 03:01, Berin Loritsch wrote:
>
>
>>http://d-haven.org/modules/news/article.php?storyid=15
>
>
> So you are a orthodox protestant?? Or perhaps a reformed catholic??
>
> What do I know, being moslem?
Just a Christian. No denomination. I most identify with pentecostal
type churches though if that helps to give a frame of reference.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] Notification pattern has interesting effects on IoC
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Friday 27 February 2004 03:01, Berin Loritsch wrote:
> http://d-haven.org/modules/news/article.php?storyid=15
So you are a orthodox protestant?? Or perhaps a reformed catholic??
What do I know, being moslem?
Niclas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
[OT] D-Haven.org site (was Re: [RT] Notification pattern has interesting
effects on IoC)
Posted by Berin Loritsch <bl...@d-haven.org>.
Alex Karasulu wrote:
> Berin what did you used to build this site. Did you hand code this or is
> this something you've customized. Just asking cuz I like it.
I am using the XOOPS 2 PHP site framework (it is effortless to use). I grabbed
a theme I liked and only customized the graphics. It is really put together
by a bunch of PHP scripts. Most of the styling is done through CSS from what
I understand.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: [RT] Notification pattern has interesting effects on IoC
Posted by Alex Karasulu <ao...@bellsouth.net>.
Berin what did you used to build this site. Did you hand code this or is
this something you've customized. Just asking cuz I like it.
ALex
> -----Original Message-----
> From: news [mailto:news@sea.gmane.org] On Behalf Of Berin Loritsch
> Sent: Thursday, February 26, 2004 2:02 PM
> To: dev@avalon.apache.org
> Subject: Re: [RT] Notification pattern has interesting effects on IoC
>
> Berin Loritsch wrote:
>
> > Niclas Hedhman wrote:
> >
> >>
> >> My point; Stephen is very much of the opinion that the container
> >> should validate that the deployment requirements are fulfilled, so
> >> called rigid.
> >> The EventDriven architecture is very much the opposite, and allow you
> >> to plug in stuff later, even to fulfill dependencies of other
> >> components that have been "starved".
> >
> > I am still out on my verdict which one is preferable to err towards.
> > One might
> > argue that you are "safer" with the over designed system, but I wonder
> > if that
> > is really the case. I might throw together another of my essays on that
> > subject
> > soon. No promises though.
>
> Ok, I made up my mind (I had to pull on my Christian roots to do it
> though).
> For any interested parties the URL is here:
>
> http://d-haven.org/modules/news/article.php?storyid=15
>
> Essentially, I don't like being forced into one way of doing things.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
> For additional commands, e-mail: dev-help@avalon.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] Notification pattern has interesting effects on IoC
Posted by Berin Loritsch <bl...@d-haven.org>.
Berin Loritsch wrote:
> Niclas Hedhman wrote:
>
>>
>> My point; Stephen is very much of the opinion that the container
>> should validate that the deployment requirements are fulfilled, so
>> called rigid.
>> The EventDriven architecture is very much the opposite, and allow you
>> to plug in stuff later, even to fulfill dependencies of other
>> components that have been "starved".
>
> I am still out on my verdict which one is preferable to err towards.
> One might
> argue that you are "safer" with the over designed system, but I wonder
> if that
> is really the case. I might throw together another of my essays on that
> subject
> soon. No promises though.
Ok, I made up my mind (I had to pull on my Christian roots to do it though).
For any interested parties the URL is here:
http://d-haven.org/modules/news/article.php?storyid=15
Essentially, I don't like being forced into one way of doing things.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: [RT] Notification pattern has interesting effects on IoC
Posted by Alex Karasulu <ao...@bellsouth.net>.
> > URL?
>
> http://cvs.sourceforge.net/viewcvs.py/d-haven/guiapp/guiapp-
> core/src/java/org/d_haven/guiapp/eventbus/
We just rewrote the same thing calling it the event router in the LDAP
server. We wanted to take the code directly but questions were asked about
software grants so we just rewrote it here:
http://cvs.apache.org/viewcvs.cgi/incubator/directory/eve/trunk/eve/frontend
/event/?root=Apache-SVN
It's really simple and did not take long at all. I think we should change
the name to EventBus though because it sounds beter.
Alex
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] Notification pattern has interesting effects on IoC
Posted by Berin Loritsch <bl...@d-haven.org>.
Niclas Hedhman wrote:
> On Thursday 26 February 2004 23:18, Berin Loritsch wrote:
>
>>Niclas Hedhman wrote:
>>
>>>This is the driving pattern for the OSGi framework.
>>>
>>>In principal I like this a lot, however, there is a "downside" (and a big
>>>one that I know someone like Stephen faint over);
>>>
>>>You don't know if the component can fulfill its 'purpose', since it may
>>>not be fed required information from "dependent" components, and
>>>especially not prior to the components are instantiated.
>>
>>In some respects, you can code the event classes to enforce or require the
>>proper information. It *does* make the stack trace messier, so debugging
>>these babies is more difficult. It is always best to keep the types of
>>events and contracts with the events as simple as possible. I've been
>>doing this for about six months now.
>
>
> Debugging; :o) Once the Event infrastructure in place, the intimidating stack
> traces is less so, just look at the first couple of entries, and ignore the
> rest. (I have been in this boat since 96/97).
:) I know, but when you are convincing people to adopt the event based
architecture the eyes glaze over when they see a 40+ line stack trace.
Anyhoo, its academic. THe biggest issue I had to overcome (and it did not
take me long to develop some guidelines to avoid it completely) is the
icky circular event logic. You know, when one event triggers another event,
which triggers the first one again. Clicking on a menu item in that situation
will cause the application to feel like it locked up until the stack limits
have been reached.
>
> My point; Stephen is very much of the opinion that the container should
> validate that the deployment requirements are fulfilled, so called rigid.
> The EventDriven architecture is very much the opposite, and allow you to plug
> in stuff later, even to fulfill dependencies of other components that have
> been "starved".
:/ It all comes back to the problem at hand. Until you can prove it is really
a problem, it is merely a case of misunderstanding the system. Too rigid a
spec makes the software bloated and slow, while too loose a spec makes things
prone to breaking unexpectedly.
I am still out on my verdict which one is preferable to err towards. One might
argue that you are "safer" with the over designed system, but I wonder if that
is really the case. I might throw together another of my essays on that subject
soon. No promises though.
>>I highly recommend you take a look at GUIApps' EventBus. It is very
>>simple, and not a lot to it. You can subscribe for a particular type of
>>event, as well as add filters to more fully refine what events you want to
>>be notified of.
>
> URL?
http://cvs.sourceforge.net/viewcvs.py/d-haven/guiapp/guiapp-core/src/java/org/d_haven/guiapp/eventbus/
>>Not to mention you can run into issues of double
>>notification if you add a listener twice (once in two different locations).
>> KISS.
>
>
> Double notification is unresolved at a semantic level. IMVHO, if I do double
> registration I should get double notification, as well as have to do double
> de-registration.
> But this is not the place for this discussion.
Yep. I was speaking more for accidental double registration due to more
complex set ups.
>>>In both case, I think that the primary concern for us would be the
>>>"Availability Contract", which somehow communicate with the component
>>>when other components are available or not. Because once that is defined
>>>in framework, both the above patterns, and re-loadable traditional AF4
>>>components, can be implemented in the container.
>>
>>You'd be surprised with this "requirement". Unless you put your entire
>>interface on the hub, you only need to notify other components when certain
>>events happen. For example, when I save changes to a type of information,
>>I would send an Update[INFO]Event on the bus, and any component already
>>loaded that needs to know if that type of info is updated will recheck the
>>values. It's pretty handy in that respect. If you send an event that
>>requires something else created and ready for you, then you will run into
>>some problems if things are not started in order. Its easier to use a
>>direct method in that case.
>
> I think you missed my argument.
> If we allow services to come and go asynchronously, we should provide a
> mechanism for the component to know that a service is/becomes or is not/"no
> longer" available.
> This is somewhat orthogonal with the EventBus discussion.
> Components that are "AvailabilityAware" can have multiple strategies in place
> to fulfill the service, depending on available services. Having spontaneous
> events every now and then doesn't help for this.
I may have missed it. I am just saying that in many cases, you won't need
the availability requirement. In fact, I haven't run accross something I
needed that guarantee for yet. I know we work on very different types of
projects, so you may have. Esp. if you are dealing with hardware integration.
Usually in these cases, I have seen an XXXAvailable event and corresponding
XXXUnavailable event. The thing is, if you miss either one of these, you
may be operating on the wrong assumption. That brings up the synchronous
requirement and a QueryXXXAvailable event.
There are ways around everything, but in the end it boils down to what makes
sense for your proejct. I tend to use concrete components and introduce
events sparingly. That approach works for me, and it really works well
(IMNSHO). Granted, I haven't done the same amount of pure event based
programming that you have either.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] Notification pattern has interesting effects on IoC
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Thursday 26 February 2004 23:18, Berin Loritsch wrote:
> Niclas Hedhman wrote:
> > This is the driving pattern for the OSGi framework.
> >
> > In principal I like this a lot, however, there is a "downside" (and a big
> > one that I know someone like Stephen faint over);
> >
> > You don't know if the component can fulfill its 'purpose', since it may
> > not be fed required information from "dependent" components, and
> > especially not prior to the components are instantiated.
>
> In some respects, you can code the event classes to enforce or require the
> proper information. It *does* make the stack trace messier, so debugging
> these babies is more difficult. It is always best to keep the types of
> events and contracts with the events as simple as possible. I've been
> doing this for about six months now.
Debugging; :o) Once the Event infrastructure in place, the intimidating stack
traces is less so, just look at the first couple of entries, and ignore the
rest. (I have been in this boat since 96/97).
My point; Stephen is very much of the opinion that the container should
validate that the deployment requirements are fulfilled, so called rigid.
The EventDriven architecture is very much the opposite, and allow you to plug
in stuff later, even to fulfill dependencies of other components that have
been "starved".
> I highly recommend you take a look at GUIApps' EventBus. It is very
> simple, and not a lot to it. You can subscribe for a particular type of
> event, as well as add filters to more fully refine what events you want to
> be notified of.
URL?
> Not to mention you can run into issues of double
> notification if you add a listener twice (once in two different locations).
> KISS.
Double notification is unresolved at a semantic level. IMVHO, if I do double
registration I should get double notification, as well as have to do double
de-registration.
But this is not the place for this discussion.
> > In both case, I think that the primary concern for us would be the
> > "Availability Contract", which somehow communicate with the component
> > when other components are available or not. Because once that is defined
> > in framework, both the above patterns, and re-loadable traditional AF4
> > components, can be implemented in the container.
>
> You'd be surprised with this "requirement". Unless you put your entire
> interface on the hub, you only need to notify other components when certain
> events happen. For example, when I save changes to a type of information,
> I would send an Update[INFO]Event on the bus, and any component already
> loaded that needs to know if that type of info is updated will recheck the
> values. It's pretty handy in that respect. If you send an event that
> requires something else created and ready for you, then you will run into
> some problems if things are not started in order. Its easier to use a
> direct method in that case.
I think you missed my argument.
If we allow services to come and go asynchronously, we should provide a
mechanism for the component to know that a service is/becomes or is not/"no
longer" available.
This is somewhat orthogonal with the EventBus discussion.
Components that are "AvailabilityAware" can have multiple strategies in place
to fulfill the service, depending on available services. Having spontaneous
events every now and then doesn't help for this.
Cheers
Niclas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] Notification pattern has interesting effects on IoC
Posted by Jonathan Hawkes <jh...@adsnm.com>.
http://jakarta.apache.org/commons/collections/apidocs-COLLECTIONS_3_0/org/apache/commons/collections/FastHashMap.html
http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html
The memory model is pretty screwy up to (and including) java 1.4. I believe
that the have fixed some of the issues in 1.5. The problem is that your
operations don't "have to" be done in order. They just have to "appear" to
be done in the correct order according to the executing thread. Thus
"m_Listeners" could be assigned a reference to "clone" before the clone was
fully initialized. Another thread could then get a hold of an invalid
"m_Listeners".
----- Original Message -----
From: "Niclas Hedhman" <ni...@hedhman.org>
To: "Avalon Developers List" <de...@avalon.apache.org>
Sent: Thursday, February 26, 2004 9:11 AM
Subject: Re: [RT] Notification pattern has interesting effects on IoC
> On Thursday 26 February 2004 23:36, Jonathan Hawkes wrote:
> > Isn't copy-on-write broken along with double-checked locking (under the
> > 1.4- memory model)?
>
> I would be happy to see any references on this.
>
> My typical code looks;
>
> public void addMyListener( MyListener listener )
> {
> synchronized( m_Listeners )
> {
> ArrayList clone = (ArrayList) m_Listeners.clone();
> clone.add( listener );
> m_Listeners = clone;
> }
> }
>
> public void removeMyListener( MyListener listener )
> {
> synchronized( m_Listeners )
> {
> ArrayList clone = (ArrayList) m_Listeners.clone();
> clone.remove( listener );
> m_Listeners = clone;
> }
> }
>
> And I can't figure out how this could be faulty, even on exotic hardware.
>
>
> Niclas
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
> For additional commands, e-mail: dev-help@avalon.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] Notification pattern has interesting effects on IoC
Posted by Jonathan Hawkes <jh...@adsnm.com>.
> Otherwise you can get:
>
> public void addMyListener( MyListener listener )
> {
> synchronized( m_Listeners )
> {
> ArrayList clone = (ArrayList) m_Listeners.clone();
> m_Listeners = clone;
> clone.add( listener );
> }
> }
>
> Due to out-of-order-execution.
>
> util.concurrent has a CopyOnWriteArrayList, BTW, so
> there's no need to implement this yourself...
>
> /LS
java.util.concurrent is in 1.5
a LOT of concurrency improvements are in 1.5
Unfortunately, I am stuck using 1.3 for the time being.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] Notification pattern has interesting effects on IoC
Posted by Jonathan Hawkes <jh...@adsnm.com>.
> On Friday 27 February 2004 00:20, Leo Sutic wrote:
> > But don't you have to synchronize on a lock for m_Listeners when
> > you traverse the list for sending notifications?
>
> > Otherwise you can get:
> >
> > public void addMyListener( MyListener listener )
> > {
> > synchronized( m_Listeners )
> > {
> > ArrayList clone = (ArrayList) m_Listeners.clone();
> > m_Listeners = clone;
> > clone.add( listener );
> > }
> > }
>
> Hmmm...
>
> public void addMyListener( MyListener listener )
> {
> ArrayList clone;
> synchronized( m_Listeners )
> {
> clone = (ArrayList) m_Listeners.clone();
> clone.add( listener );
> }
> m_Listeners = clone;
> }
>
> ??
That won't work either. You just can't beat the flawed memory model. The
following is a terrific resource.
http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html
Doug Lea proposes many work-arounds and then shoots most of them down :)
I think that the memory model was actually modified for java 1.5.
Jonathan Hawkes
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] Notification pattern has interesting effects on IoC
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Friday 27 February 2004 00:20, Leo Sutic wrote:
> But don't you have to synchronize on a lock for m_Listeners when
> you traverse the list for sending notifications?
> Otherwise you can get:
>
> public void addMyListener( MyListener listener )
> {
> synchronized( m_Listeners )
> {
> ArrayList clone = (ArrayList) m_Listeners.clone();
> m_Listeners = clone;
> clone.add( listener );
> }
> }
Hmmm...
public void addMyListener( MyListener listener )
{
ArrayList clone;
synchronized( m_Listeners )
{
clone = (ArrayList) m_Listeners.clone();
clone.add( listener );
}
m_Listeners = clone;
}
??
--
+---------//-------------------+
| http://www.bali.ac |
| http://niclas.hedhman.org |
+------//----------------------+
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: [RT] Notification pattern has interesting effects on IoC
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> -----Original Message-----
> From: Niclas Hedhman [mailto:niclas@hedhman.org]
> Sent: den 26 februari 2004 17:11
> To: Avalon Developers List
> Subject: Re: [RT] Notification pattern has interesting effects on IoC
>
>
> On Thursday 26 February 2004 23:36, Jonathan Hawkes wrote:
> > Isn't copy-on-write broken along with double-checked locking (under
> > the
> > 1.4- memory model)?
>
> I would be happy to see any references on this.
>
> My typical code looks;
>
> public void addMyListener( MyListener listener )
> {
> synchronized( m_Listeners )
> {
> ArrayList clone = (ArrayList) m_Listeners.clone();
> clone.add( listener );
> m_Listeners = clone;
> }
> }
>
> public void removeMyListener( MyListener listener )
> {
> synchronized( m_Listeners )
> {
> ArrayList clone = (ArrayList) m_Listeners.clone();
> clone.remove( listener );
> m_Listeners = clone;
> }
> }
>
> And I can't figure out how this could be faulty, even on
> exotic hardware.
But don't you have to synchronize on a lock for m_Listeners when
you traverse the list for sending notifications?
Otherwise you can get:
public void addMyListener( MyListener listener )
{
synchronized( m_Listeners )
{
ArrayList clone = (ArrayList) m_Listeners.clone();
m_Listeners = clone;
clone.add( listener );
}
}
Due to out-of-order-execution.
util.concurrent has a CopyOnWriteArrayList, BTW, so
there's no need to implement this yourself...
/LS
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] Notification pattern has interesting effects on IoC
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Thursday 26 February 2004 23:36, Jonathan Hawkes wrote:
> Isn't copy-on-write broken along with double-checked locking (under the
> 1.4- memory model)?
I would be happy to see any references on this.
My typical code looks;
public void addMyListener( MyListener listener )
{
synchronized( m_Listeners )
{
ArrayList clone = (ArrayList) m_Listeners.clone();
clone.add( listener );
m_Listeners = clone;
}
}
public void removeMyListener( MyListener listener )
{
synchronized( m_Listeners )
{
ArrayList clone = (ArrayList) m_Listeners.clone();
clone.remove( listener );
m_Listeners = clone;
}
}
And I can't figure out how this could be faulty, even on exotic hardware.
Niclas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] Notification pattern has interesting effects on IoC
Posted by Jonathan Hawkes <jh...@adsnm.com>.
This would work. :)
----- Original Message -----
From: "Leo Sutic" <le...@inspireinfrastructure.com>
To: "'Avalon Developers List'" <de...@avalon.apache.org>
Sent: Thursday, February 26, 2004 10:28 AM
Subject: RE: [RT] Notification pattern has interesting effects on IoC
> It is, but that's a broken implementation of copy-on-write (CoW).
>
> You still need synchronization to comply with the Java memory model.
> There's no way to get around that.
>
> The problem we have is this:
>
> + We have a list of listeners.
>
> + In order to send out an event to the listeners, we must
> traverse the list and call handleEvent(e) on all of them.
>
> + But we also want to add and remove listeners.
>
> + We can't add/remove *and* traverse the list simultaneuosly
> (ConcurrentModificationException).
>
> + So we could do this:
>
> synchronized void addListener (Listener l) { ... }
> synchronized void removeListener (Listener l) { ... }
> synchronized void fireEvent (Event e) { ... }
>
> + But then we can't have two fireEvent calls running
> concurrently. That's bad.
>
> + So we do this: In fireEvent, synchronize on m_updateLock
> long enough to obtain an iterator.
>
> Then, when we are about to mutate the list (add/remove)
> lock the m_mutateLock (to prevent concurrent updates,
> which is still a no-no). Then lock m_updateLock, and get
> an iterator. release m_updateLock.
>
> Copy the list by using the iterator. (The list is
> now unlocked and can be used in fireEvent. It is
> guaranteed not to change, since we hold m_mutateLock.)
>
> Modify the copy.
>
> synchronize on m_updateLock
>
> Assign the copy to the list member field.
>
> release m_updateLock
>
> Release the m_mutateLock.
>
> Then all writes are guaranteed to be flushed, and
> we minimize the time m_updateLock is locked.
>
>
>
> /LS
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: [RT] Notification pattern has interesting effects on IoC
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
It is, but that's a broken implementation of copy-on-write (CoW).
You still need synchronization to comply with the Java memory model.
There's no way to get around that.
The problem we have is this:
+ We have a list of listeners.
+ In order to send out an event to the listeners, we must
traverse the list and call handleEvent(e) on all of them.
+ But we also want to add and remove listeners.
+ We can't add/remove *and* traverse the list simultaneuosly
(ConcurrentModificationException).
+ So we could do this:
synchronized void addListener (Listener l) { ... }
synchronized void removeListener (Listener l) { ... }
synchronized void fireEvent (Event e) { ... }
+ But then we can't have two fireEvent calls running
concurrently. That's bad.
+ So we do this: In fireEvent, synchronize on m_updateLock
long enough to obtain an iterator.
Then, when we are about to mutate the list (add/remove)
lock the m_mutateLock (to prevent concurrent updates,
which is still a no-no). Then lock m_updateLock, and get
an iterator. release m_updateLock.
Copy the list by using the iterator. (The list is
now unlocked and can be used in fireEvent. It is
guaranteed not to change, since we hold m_mutateLock.)
Modify the copy.
synchronize on m_updateLock
Assign the copy to the list member field.
release m_updateLock
Release the m_mutateLock.
Then all writes are guaranteed to be flushed, and
we minimize the time m_updateLock is locked.
/LS
> From: Jonathan Hawkes [mailto:jhawkes@adsnm.com]
>
> http://jakarta.apache.org/commons/collections/apidocs-COLLECTI
> ONS_3_0/org/apache/commons/collections/FastHashMap.html
>
> Isn't this what you mean by copy-on-write? It's broken
> according to the docs.
>
>
> ----- Original Message -----
> From: "Leo Sutic" <le...@inspireinfrastructure.com>
> To: "'Avalon Developers List'" <de...@avalon.apache.org>
> Sent: Thursday, February 26, 2004 8:45 AM
> Subject: RE: [RT] Notification pattern has interesting effects on IoC
>
>
> > No.
> >
> > Double-checked locking is broken, but copy-on-write isn't.
> >
> > Another way of doing it is to wrap the set of listeners in a
> > read/write lock.
> >
> > /LS
> >
> > > From: Jonathan Hawkes [mailto:jhawkes@adsnm.com]
> >
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
> > For additional commands, e-mail: dev-help@avalon.apache.org
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
> For additional commands, e-mail: dev-help@avalon.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] Notification pattern has interesting effects on IoC
Posted by Jonathan Hawkes <jh...@adsnm.com>.
http://jakarta.apache.org/commons/collections/apidocs-COLLECTIONS_3_0/org/apache/commons/collections/FastHashMap.html
Isn't this what you mean by copy-on-write? It's broken according to the
docs.
----- Original Message -----
From: "Leo Sutic" <le...@inspireinfrastructure.com>
To: "'Avalon Developers List'" <de...@avalon.apache.org>
Sent: Thursday, February 26, 2004 8:45 AM
Subject: RE: [RT] Notification pattern has interesting effects on IoC
> No.
>
> Double-checked locking is broken, but copy-on-write isn't.
>
> Another way of doing it is to wrap the set of listeners in a
> read/write lock.
>
> /LS
>
> > From: Jonathan Hawkes [mailto:jhawkes@adsnm.com]
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
> For additional commands, e-mail: dev-help@avalon.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: [RT] Notification pattern has interesting effects on IoC
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
No.
Double-checked locking is broken, but copy-on-write isn't.
Another way of doing it is to wrap the set of listeners in a
read/write lock.
/LS
> From: Jonathan Hawkes [mailto:jhawkes@adsnm.com]
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] Notification pattern has interesting effects on IoC
Posted by Jonathan Hawkes <jh...@adsnm.com>.
Isn't copy-on-write broken along with double-checked locking (under the 1.4-
memory model)?
----- Original Message -----
From: "Leo Sutic" <le...@inspireinfrastructure.com>
To: "'Avalon Developers List'" <de...@avalon.apache.org>
Sent: Thursday, February 26, 2004 8:27 AM
Subject: RE: [RT] Notification pattern has interesting effects on IoC
>
>
> > Not sure. In very 'busy' systems, it becomes a challange to
> > write the 'hub', so that you don't need to synchronize the
> > 'addListener' and 'fireEvent' parts, because otherwise it
> > becomes a bottleneck.
>
> Listeners are added and removed comparatively rarely compared
> to the number of fireEvent calls, so a copy-on-write list
> can eliminate much synchronization.
>
> /LS
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
> For additional commands, e-mail: dev-help@avalon.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: [RT] Notification pattern has interesting effects on IoC
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> Not sure. In very 'busy' systems, it becomes a challange to
> write the 'hub', so that you don't need to synchronize the
> 'addListener' and 'fireEvent' parts, because otherwise it
> becomes a bottleneck.
Listeners are added and removed comparatively rarely compared
to the number of fireEvent calls, so a copy-on-write list
can eliminate much synchronization.
/LS
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] Notification pattern has interesting effects on IoC
Posted by Berin Loritsch <bl...@d-haven.org>.
Niclas Hedhman wrote:
> This is the driving pattern for the OSGi framework.
>
> In principal I like this a lot, however, there is a "downside" (and a big one
> that I know someone like Stephen faint over);
>
> You don't know if the component can fulfill its 'purpose', since it may not be
> fed required information from "dependent" components, and especially not
> prior to the components are instantiated.
In some respects, you can code the event classes to enforce or require the
proper information. It *does* make the stack trace messier, so debugging
these babies is more difficult. It is always best to keep the types of events
and contracts with the events as simple as possible. I've been doing this
for about six months now.
> There is a kind-of solution. If the 'router'/'hub' has a registration
> requirement for the 'publisher' of the events, then the 'subscriber' can
> query the 'hub' if there is any 'publisher' of the event types of interest.
>
> Do I think that a centralized 'hub' is better than 'direct events'??
>
> Not sure. In very 'busy' systems, it becomes a challange to write the 'hub',
> so that you don't need to synchronize the 'addListener' and 'fireEvent'
> parts, because otherwise it becomes a bottleneck.
I highly recommend you take a look at GUIApps' EventBus. It is very simple, and
not a lot to it. You can subscribe for a particular type of event, as well as
add filters to more fully refine what events you want to be notified of.
You don't need to do addListener() and fireEvent() methods, and it is easier
to wire than directly calling those methods like in a Swing based app. Any
component that wants to publish events only needs the EventBus. If they want
to listen for events we have the (un)subscribe methods on the EventBus, and
those events are routed to a Subscriber. It works very smoothly.
> And then compare it with "direct events", meaning you register yourself at the
> source.
> The difference is basically;
>
> The 'hub' pattern uses an EventListener interface and an EventObject class,
> all in true JavaBean tradition.
>
> The decoupled 'direct event' pattern also needs a EventProducer interface, and
> a 'query' service capable of searching for interfaces.
The hub pattern scales much more easily and is simpler to code and understand.
A decoupled "direct event" pattern is much less easy to implement or use. Not
to mention you can run into issues of double notification if you add a listener
twice (once in two different locations). KISS.
> In both case, I think that the primary concern for us would be the
> "Availability Contract", which somehow communicate with the component when
> other components are available or not. Because once that is defined in
> framework, both the above patterns, and re-loadable traditional AF4
> components, can be implemented in the container.
You'd be surprised with this "requirement". Unless you put your entire
interface on the hub, you only need to notify other components when certain
events happen. For example, when I save changes to a type of information,
I would send an Update[INFO]Event on the bus, and any component already
loaded that needs to know if that type of info is updated will recheck the
values. It's pretty handy in that respect. If you send an event that
requires something else created and ready for you, then you will run into
some problems if things are not started in order. Its easier to use a
direct method in that case.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] Notification pattern has interesting effects on IoC
Posted by Niclas Hedhman <ni...@hedhman.org>.
This is the driving pattern for the OSGi framework.
In principal I like this a lot, however, there is a "downside" (and a big one
that I know someone like Stephen faint over);
You don't know if the component can fulfill its 'purpose', since it may not be
fed required information from "dependent" components, and especially not
prior to the components are instantiated.
There is a kind-of solution. If the 'router'/'hub' has a registration
requirement for the 'publisher' of the events, then the 'subscriber' can
query the 'hub' if there is any 'publisher' of the event types of interest.
Do I think that a centralized 'hub' is better than 'direct events'??
Not sure. In very 'busy' systems, it becomes a challange to write the 'hub',
so that you don't need to synchronize the 'addListener' and 'fireEvent'
parts, because otherwise it becomes a bottleneck.
And then compare it with "direct events", meaning you register yourself at the
source.
The difference is basically;
The 'hub' pattern uses an EventListener interface and an EventObject class,
all in true JavaBean tradition.
The decoupled 'direct event' pattern also needs a EventProducer interface, and
a 'query' service capable of searching for interfaces.
In both case, I think that the primary concern for us would be the
"Availability Contract", which somehow communicate with the component when
other components are available or not. Because once that is defined in
framework, both the above patterns, and re-loadable traditional AF4
components, can be implemented in the container.
Cheers
Niclas
On Wednesday 18 February 2004 12:44, Alex Karasulu wrote:
> Hi all,
>
> While looking at the frontend of the Eve server I began to realize a trend
> emerging after I introduced a central publish and subscribe facility. The
> pattern decouples components by enabling communication using events and the
> notifier pattern. This also lead to the disappearence of methods on service
> interfaces.
>
> So the dependency graph turns into a star with all components depending on
> the event router, hub, bus or whatever you call it in the center. Event
> types and interfaces essentially become the dependency as opposed to the
> service interfaces. This way you can introduce new subscribers and
> publishers. Also the dynamic rerouting of events is possible at runtime.
> What this means is that the dependencies between components can change on
> the fly! Wow not a bad thang.
>
> What does this mean for service interfaces? Well they start looking bleak
> because the Subscriber interface replaces them. Basically methods are
> called internally by the Subscriber handling code on the component itself
> rather than exposing them on the service interface for direct calls by what
> are now publishers. This is crazy my service interfaces are all empty now!
>
> Alex
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
> For additional commands, e-mail: dev-help@avalon.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] Notification pattern has interesting effects on IoC
Posted by Jonathan Hawkes <jh...@adsnm.com>.
I've been looking into this also. In fact, I was introduced to Avalon
through looking into SEDA architectures. As Alex mentioned, event
interfaces seem to replace service interfaces. In my opinion, service
interfaces are more intuitive, however. The following examples are pretty
much equivalent.
Example:
Queue pizzaMakerQueue = ....;
Queue pizzaConsumerQueue = ...;
PizzaOrderEvent evt = new SimplePizzaOrderEvent("large", "supreme",
pizzaConsumerQueue);
pizzaMakerQueue.publish(evt);
Example:
PizzaMaker pizzaMaker = ...;
PizzaConsumer pizzaConsumer = ...;
pizzaMaker.placeOrder("large","supreme", pizzaConsumer);
Jonathan Hawkes
----- Original Message -----
From: "Timothy Bennett" <ex...@comcast.net>
To: <de...@avalon.apache.org>
Sent: Tuesday, February 17, 2004 10:53 PM
Subject: Re: [RT] Notification pattern has interesting effects on IoC
> Alex Karasulu wrote:
> > Hi all,
> >
> > While looking at the frontend of the Eve server I began to realize a
trend
> > emerging after I introduced a central publish and subscribe facility.
The
> > pattern decouples components by enabling communication using events and
the
> > notifier pattern. This also lead to the disappearence of methods on
service
> > interfaces.
> >
> > So the dependency graph turns into a star with all components depending
on
> > the event router, hub, bus or whatever you call it in the center. Event
> > types and interfaces essentially become the dependency as opposed to the
> > service interfaces. This way you can introduce new subscribers and
> > publishers. Also the dynamic rerouting of events is possible at runtime.
> > What this means is that the dependencies between components can change
on
> > the fly! Wow not a bad thang.
> >
> > What does this mean for service interfaces? Well they start looking
bleak
> > because the Subscriber interface replaces them. Basically methods are
called
> > internally by the Subscriber handling code on the component itself
rather
> > than exposing them on the service interface for direct calls by what are
now
> > publishers. This is crazy my service interfaces are all empty now!
> >
> > Alex
>
> Alex,
>
> I've noticed the same thing with a similar avalon application that I've
> built using pub-sub event router between components. In my mind, I've
> been trying to pro/con the services vs. notifications for about six
> months now. Am interested on others' take on this subject.
>
> Timothy
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
> For additional commands, e-mail: dev-help@avalon.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: [RT] Notification pattern has interesting effects on IoC
Posted by Alex Karasulu <ao...@bellsouth.net>.
> I've noticed the same thing with a similar avalon application that I've
> built using pub-sub event router between components. In my mind, I've
> been trying to pro/con the services vs. notifications for about six
> months now. Am interested on others' take on this subject.
It just hit me today and it made me step back and go wow. Steve said
basically pub/sub trades in methods on service interfaces for dependencies
on event classes. Seems that way definitely. It's just odd how the
pattern ate the methods on my service interfaces.
Alex
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] Notification pattern has interesting effects on IoC
Posted by Timothy Bennett <ex...@comcast.net>.
Alex Karasulu wrote:
> Hi all,
>
> While looking at the frontend of the Eve server I began to realize a trend
> emerging after I introduced a central publish and subscribe facility. The
> pattern decouples components by enabling communication using events and the
> notifier pattern. This also lead to the disappearence of methods on service
> interfaces.
>
> So the dependency graph turns into a star with all components depending on
> the event router, hub, bus or whatever you call it in the center. Event
> types and interfaces essentially become the dependency as opposed to the
> service interfaces. This way you can introduce new subscribers and
> publishers. Also the dynamic rerouting of events is possible at runtime.
> What this means is that the dependencies between components can change on
> the fly! Wow not a bad thang.
>
> What does this mean for service interfaces? Well they start looking bleak
> because the Subscriber interface replaces them. Basically methods are called
> internally by the Subscriber handling code on the component itself rather
> than exposing them on the service interface for direct calls by what are now
> publishers. This is crazy my service interfaces are all empty now!
>
> Alex
Alex,
I've noticed the same thing with a similar avalon application that I've
built using pub-sub event router between components. In my mind, I've
been trying to pro/con the services vs. notifications for about six
months now. Am interested on others' take on this subject.
Timothy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] Notification pattern has interesting effects on IoC
Posted by Vincent Tence <vt...@videotron.ca>.
On Wed, 2004-02-18 at 04:44, Alex Karasulu wrote:
> Hi all,
>
> While looking at the frontend of the Eve server I began to realize a trend
> emerging after I introduced a central publish and subscribe facility. The
> pattern decouples components by enabling communication using events and the
> notifier pattern. This also lead to the disappearence of methods on service
> interfaces.
>
> So the dependency graph turns into a star with all components depending on
> the event router, hub, bus or whatever you call it in the center. Event
> types and interfaces essentially become the dependency as opposed to the
> service interfaces. This way you can introduce new subscribers and
> publishers. Also the dynamic rerouting of events is possible at runtime.
> What this means is that the dependencies between components can change on
> the fly! Wow not a bad thang.
>
> What does this mean for service interfaces? Well they start looking bleak
> because the Subscriber interface replaces them. Basically methods are called
> internally by the Subscriber handling code on the component itself rather
> than exposing them on the service interface for direct calls by what are now
> publishers. This is crazy my service interfaces are all empty now!
Which is cool, cuz it means yours components can be POJOs. Can you wire
the entire system at startup and get rid of the need to support
different component frameworks? Only the bootstrap mechanism would be
dependant of the kernel used.
>
> Alex
>
>
RE: [RT] Notification pattern has interesting effects on IoC
Posted by Alex Karasulu <ao...@bellsouth.net>.
Very good one! Using Monitors rather than Loggers is awesome.
> -----Original Message-----
> From: Leo Sutic [mailto:leo.sutic@inspireinfrastructure.com]
> Sent: Wednesday, February 18, 2004 12:47 PM
> To: 'Avalon Developers List'
> Subject: RE: [RT] Notification pattern has interesting effects on IoC
>
>
>
> > From: Niclas Hedhman [mailto:niclas@hedhman.org]
> >
> > On Wednesday 18 February 2004 20:54, Leo Simons wrote:
> >
> > > that was Leo Sutic's essay :D
> >
> > Oops... All kudos transferred from LSD to LS !!!!
>
> I think it was Paul Hammant's idea originally.
>
> /LS
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
> For additional commands, e-mail: dev-help@avalon.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: [RT] Notification pattern has interesting effects on IoC
Posted by Leo Sutic <le...@inspireinfrastructure.com>.
> From: Niclas Hedhman [mailto:niclas@hedhman.org]
>
> On Wednesday 18 February 2004 20:54, Leo Simons wrote:
>
> > that was Leo Sutic's essay :D
>
> Oops... All kudos transferred from LSD to LS !!!!
I think it was Paul Hammant's idea originally.
/LS
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] Notification pattern has interesting effects on IoC
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Wednesday 18 February 2004 20:54, Leo Simons wrote:
> that was Leo Sutic's essay :D
Oops... All kudos transferred from LSD to LS !!!!
Cheers
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] Notification pattern has interesting effects on IoC
Posted by Leo Simons <le...@apache.org>.
Niclas Hedhman wrote:
> On Wednesday 18 February 2004 19:39, Leo Simons wrote:
>
> Thanks for the long RT on what constitutes a Request/Response architecture,
hehehe. Well the point is looking at request/response from the IoC view
of the world, innit?
> but IMHV, isn't this just an generalization (i.e. using something else than
> the heap and stack, as transport) of normal call/returns of most programming
> languages?
it's all turing-equivalent :D
what's important is the way we think about these things. When I look at
most implementations in this field, I often think "well, that's just all
the same". But that doesn't really help us get anywhere ;)
> When I think of "Event-Driven" programming patterns, it boils down to exactly
> what you have described in your essay about why Loggers are no good (I loved
> that one, and a real eye-opener of something one have taken for granted!).
that was Leo Sutic's essay :D
> And I think Alex has noticed that, and seen that the next level is the
> 'router'/'hub', gives even more decoupling benefits.
yep. And the next point is decoupling 90% of the code from being aware
of the router ;)
> Join my Advanced Course ;o)
I study physics dude. With software I'm only interested in long-winded
and preferably unfounded discussion and thought exchange that have no
basis in knowledge. I thought you had that figured out by now ;)
--
cheers,
- Leo Simons
-----------------------------------------------------------------------
Weblog -- http://leosimons.com/
IoC Component Glue -- http://jicarilla.org/
Articles & Opinions -- http://articles.leosimons.com/
-----------------------------------------------------------------------
"We started off trying to set up a small anarchist community, but
people wouldn't obey the rules."
-- Alan Bennett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
RE: [RT] Notification pattern has interesting effects on IoC
Posted by andreas oberhack <de...@softwarefabrik.biz>.
Hi Niklas,
> "Call/Return"s are made in the opposite direction in the object
hierarchy,
> causing some really serious trouble in multi-threaded environments.
People
> interested; Join my Advanced Course ;o)
Give me the registration application. I'll come over! :-)
Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] Notification pattern has interesting effects on IoC
Posted by Niclas Hedhman <ni...@hedhman.org>.
On Wednesday 18 February 2004 19:39, Leo Simons wrote:
> This is a request/response architecture, and its not general enough. It
> seems we need an "event bus" or listener approach, where there can be
> multiple publishers of the same message, and multiple recipients. we can
> ath this point drift into the realm of JINI, JavaSpaces, and the like.
> Since I don't fully understand most of that I won't go there.
You should... That's where the fun starts ;o)
Thanks for the long RT on what constitutes a Request/Response architecture,
but IMHV, isn't this just an generalization (i.e. using something else than
the heap and stack, as transport) of normal call/returns of most programming
languages?
When I think of "Event-Driven" programming patterns, it boils down to exactly
what you have described in your essay about why Loggers are no good (I loved
that one, and a real eye-opener of something one have taken for granted!).
"Event-Driven" (call it publish/subscribe, notification or whatever) patterns
are introducing a very nice extension to the familiar call/return concept.
Unfortunately, the benefits are rather subtle, and not easily appreciated
until you scale up the complexity of a system.
And I think Alex has noticed that, and seen that the next level is the
'router'/'hub', gives even more decoupling benefits.
NOTE; There are some traps in "Event-Driven" patterns, where the Events has
the 'trend' of moving from the low-level towards the higher levels, and the
"Call/Return"s are made in the opposite direction in the object hierarchy,
causing some really serious trouble in multi-threaded environments. People
interested; Join my Advanced Course ;o)
Cheers
Niclas
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] Notification pattern has interesting effects on IoC
Posted by Vinay Chandran <vi...@yahoo.com>.
Hi,
> > I began to realize a trend
> > emerging after I introduced a central publish and
> subscribe facility. The
> > pattern decouples components by enabling
> communication using events and the
> > notifier pattern. This also lead to the
> disappearence of methods on service
> > interfaces.
>
Interesting ,
Some problems with Implicit
Invocation(event,pub/suc,notifier...) is :-
. loss of control (which components responded,when did
the other component finish its task, order of flow of
events). In some case these might not be important at
all(pure loosely coupled) and in some we might build
it using protocols (req-reply,ack) but it muddies the
implementation. So it doesnt seem like a cure for all
types of component interactions.
. lots of events esp when maintaining frequently-used
shared data/interaction across such components.I
think maybe its less intuitive too at times esp when
its a chain of events/actions.
But its a well researched area(google(implicit
inovation)) & a pretty interesting one too.
Regards,
Vinay
__________________________________
Do you Yahoo!?
Yahoo! Mail SpamGuard - Read only the mail you want.
http://antispam.yahoo.com/tools
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org
Re: [RT] Notification pattern has interesting effects on IoC
Posted by Leo Simons <le...@apache.org>.
Alex Karasulu wrote:
> While looking at the frontend of the Eve server
I still need to check that one out...the buzz is increasing :D
> I began to realize a trend
> emerging after I introduced a central publish and subscribe facility. The
> pattern decouples components by enabling communication using events and the
> notifier pattern. This also lead to the disappearence of methods on service
> interfaces.
I've thought about this a great deal, and so have many others. But I
have yet to find a thought actually worth writing down (not even talking
about it making sense, too). Since this is such a fun topic, I'll try
anyway :D. This will have a high RT level. It'll get better at the bottom.
At a very high abstraction level, you might say that the
interface/service world is call-based ("composer calls method on
component" is what the avalon terms used to be). OTOH, publish/subscribe
and event systems are message-based ("sender sends message to
receiver"). Let's take a look at these seperately and see if the
emerging technologies can work together.
Realizations in service-based design
------------------------------------
A service will use other services to accomplish its task. This is a
dependency. The simplest case is where a service is responsible for
every aspect of the "other service" that it depends on.
The next step is to delegate some responsibility to another entity. This
can be a registry, a container, or some hybrid form. We tend to prefer
the container paradigm as opposed to the registry paradigm because the
container view of the world centralizes some responsibilities, which
makes it easier for a human to figure out exactly what is going on (We
call that IoC). It is more logical, and more secure.
We can go further, and delegate different kinds of responsibility in
different directions. We can identify distinct (human and/or machine)
roles in our systems and decompose the system further to allow for that
(ie, we'll use terms like assembler, composer, publisher, subscribe,
poller, manager, kernel, hub, configurator, administrator) as our system
grows more complex. At some point it becomes natural to think in terms
of responsibilities (we call that seperation of concerns).
In summary, we apply SoC and IoC on a call-based system.
In avalon, the decomposition choices have slowly evolved (exactly what
concerns we seperate into distinct "blocks" or "components" or
"facilities" or ...) from nearly non-specified (we stop at the concept
of ComponentManager) to nearly set-in-stone (we use a very rigid and
uniformly structured model as the basis of the merlin system). As long
as I've been at avalon, the trend has been towards more rigidity,
predicatibility, stability, etc. There have been a few attempts to
change that direction, but none of them ever gained the neccessary momentum.
Up to a few months ago, most people looking towards IoC were looking for
rigidity.
Realizations in message-based systems
-------------------------------------
An entity will send message to other entities to accomplish "something".
One of the simplest cases is probably where a browser sends a GET to a
server. This is request/response messaging.
The next step is to decouple entities by introducing an addressing
scheme (ie some form of URIs), possibly namespaces, and, again, the term
registry will pop up again. I tend to prefer the kernel paradigm (ie,
mach). Another popular trend is the use of a discovery mechanism in
place of something centralized like a kernel or a registry. And of
course the whole "spaces" area is subject to active academic research.
IMV, the communication/protocol/message format/style choices in
message-based systems are as vital as the decomposition in the
service-based systems, and just as hard.
In summary, message-based systems are difficult.
In avalon, we've tried marriage of the service paradigm with the message
paradigm a few times, at one point by introducing Commands and
Commandables into avalon-framework, at another point by defining
responsibilities of a message-based system (sender, receiver, queue,
...) in excalibur-event. However, our resource identifiers (roles) have
always been particular, and never uniform. We did talk for a few weeks
about changing that, but never got round to it.
The most popular form of merging message-based systems with
service-based systems is probably found in some applications of the
servlet api, where HTTP messages are mapped to and from services. The
cleanest version of that is probably found in SOAP, and something like
Axis does a good job of mapping some core abstractions.
Message<->Service adapters
--------------------------
You can use tomcat+axis+a good bit of configuration and assembly to map
HTTP messages to services. You'll need to use a few registries and
discovery mechanisms before you can though (TCP/IP, DNS, WSDL, and more).
You can intersect a message layer between tomcat and your service engine
to translate between human-readable (HTML) and machine readable (the
method call, or often "action", which is a high-abstraction method
call). You'll need to use several registries as well here.
Many similar solutions are in active use in many problem domains.
Observation: combine everything together, and these adapters,
registries, containers, etc, are rather *big*.
If Joe User has a message/action/use case/whatever like
update the first paragraph of the article "News From The Foo Bar
Corporation" to read "..."
there are rather a lot of adapters and intermediary steps, prerequisites
and postrequisites).
I *think* we are looking for a way to use less of these adapters, and
simpler, more predicatible ones. In Eve, you're not wanting to build
something the size and scale of the web, but you do need to translate
some kind of message to a method call and back again.
The magic word
--------------
"Universal" in "Universal Resource Identifier (URI)" is rather powerful.
"Uniform" in "Uniform Resource Name (URN)" is of similar power. We're
looking for things that have these qualifications. "universal",
"uniform", "general".
Some of the work is already done, and is ready to be applied. We have
URI, URN, JNDI, HTTP, XML, SOAP, etc, on the message/registry side. We
have no such thing yet on the service side, but for the moment lets just
live with the type1/2/3/4/5 versions of "IoC" and assume you're doing a
merlin-based system.
Now, we want, maybe, a "uniform" and "general" message<->service adapter.
This is, I think, just about what jicarilla-framework is about (though
I've only just realized that!). Let me try and explain.
The uniform message<->service adapter
-------------------------------------
At some point, you have some kind of message that you want some kind of
service to handle. Lets introduce an intermediary form. An Invocation.
Define services that can receive and handle invocations. Define
transformers that can convert between message formats and invocations.
Define how to create URNs for these transformers. Define mappings from
URIs to URNs. That's it.
I'm currently working on as generic and universal a message<->service
adapter as possible, which is at the same time also quite small. I'm
focussing on the web domain atm. It should (will) look like this...
A client fires of a HTTP message. The web server handles the
low-level protocol. It sends the object representation of the message
to a broker/mapper. The broker handles the URI/URN translation, and
sends the message to a transformer found by URN. The transformer is
half of the bridge between the message-based system and the
service-based system. It creates an invocation and feeds it to the
service. The other half of the message<->service adapter lives in the
service itself or in some intermediary and transforms the conceptual
Invocation into an actual invocation.
Intermezzo
----------
phew! That's a whole lot of typing, and I haven't really even talked
about notifications and dependencies. Lets try and get back down to
earth a little more.
Notification and callbacks
--------------------------
Not described above are callbacks/responses. Invocations create
responses, which need to be translated back to messages, and sent
somewhere. We might travel the whole "message bus" in reverse, or we
might go forward through a different bus. It's not that difficult to
figure out the former can be mapped to the latter, so in the quest for
"uniform" we'll pick the latter. Continuing my example
The intermediary between the transformer and the service applies the
invocation to the service. The service returns a result from the
method call. The intermediary feeds this back to the transformer,
which translates the response to an object representation of an
HTTP message. This message is fed back to the web server, which
handles the low level protocol. The response arrives back at the
client.
This is a request/response architecture, and its not general enough. It
seems we need an "event bus" or listener approach, where there can be
multiple publishers of the same message, and multiple recipients. we can
ath this point drift into the realm of JINI, JavaSpaces, and the like.
Since I don't fully understand most of that I won't go there.
However, I think stuff like multicasters and aggregators can be used to
adapt a simple pipeline to a more complex one. So lets keep the basics
of the pipeline simple until we are sure we need complexity.
The point to take away
----------------------
I think this is the big thing. The response to this:
> So the dependency graph turns into a star with all components depending on
> the event router, hub, bus or whatever you call it in the center. Event
> types and interfaces essentially become the dependency as opposed to the
> service interfaces. This way you can introduce new subscribers and
> publishers. Also the dynamic rerouting of events is possible at runtime.
> What this means is that the dependencies between components can change on
> the fly! Wow not a bad thang.
well, its less rigid. Have you gone through the introduction of lots of
rigidity by introducing a strict model for lots of things (declaring
loads of metadata and creating facilities to read/write/store it), only
to build a layer on top of it that takes all the rigidity away again?
> What does this mean for service interfaces? Well they start looking bleak
> because the Subscriber interface replaces them. Basically methods are called
> internally by the Subscriber handling code on the component itself rather
> than exposing them on the service interface for direct calls by what are now
> publishers. This is crazy my service interfaces are all empty now!
I think you want to introduce a layer between your event-based system
that maps events to-and-from method calls. Your services don't change
(good thing), but you still get all the benefit of the event-based approach.
Otherwise, what's the benefit of using avalon at all?
--
cheers,
- Leo Simons
-----------------------------------------------------------------------
Weblog -- http://leosimons.com/
IoC Component Glue -- http://jicarilla.org/
Articles & Opinions -- http://articles.leosimons.com/
-----------------------------------------------------------------------
"We started off trying to set up a small anarchist community, but
people wouldn't obey the rules."
-- Alan Bennett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org