avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Nader Aeinehchi" <na...@aeinehchi.com>
Subject Re: What do you think about Merlin with Jini?
Date Sat, 03 Apr 2004 15:03:10 GMT
Hi Niclas

Central in the Jini metaphor is that service are not always available and
the
> 'client' always has to support this, whereas in Merlin the total opposite
is
> true. So I have recognized that there has to be some form of Availability
> noitification system introduced, and I haven't gotten to defining one.
Once
> that is in place, we not only get the Jini/Distributed services
possibility,
> but also reloadable components, which is desirable independently of
> Jini/distrbuted.

You are touching some very interesting thing "Availability noitification
system ".

a. The question is whose responsibility is to ensure
the availibilty and the availibility notification, the component itself or
the container of the component?

If the container is responsible, then the container should check for the
availibity of the components it is responsible for.  The container could do
it periodically by a timer or more intelligently by having an management
agent.

On the other hand, if the component takes the responsibility, then it
prompotes a  proactive component architecture.

I think both approaches are interesting, and probably completing each other.


b. The second issue is how the client should know about the availibility?
Should the client be informed by the
I-the component
II-the container of the component
III- should the client proactively ask for the availibility?

I- results in observer/oberservable pattern that we know from Java's know
listener mechanism.  As far as I can see, this approach has been taken in
Merlin's Kernel.java
II- here a simple hub-spoke architecture might be good enough, where the
container (or an underlying component) acts like the hub.  Both publishers
(the component) and subscribers (the client) of availibility event act as
spokes.  Note that this approach could also be used for a.
III- well, this is the difficult one to implement.  Here the client could
periodically either ask the component or the container of the compoent about
the availibility.

Having said the above, it seems to me that Merlin is not geared toward
distributed systems?



Best Regards

--
Nader Aeinehchi
Aasenhagen 66 E
2020 Skedsmokorset
NORWAY
Direct and Mobile +47 41 44 29 57
Tel (private): +47 64 83 09 08
Fax +47 64 83 08 07
www.aeinehchi.com

----- Original Message -----
From: "Niclas Hedhman" <niclas@hedhman.org>
To: "Avalon Developers List" <dev@avalon.apache.org>
Sent: Saturday, April 03, 2004 12:07 PM
Subject: Re: What do you think about Merlin with Jini?


> On Saturday 03 April 2004 17:43, Nader Aeinehchi wrote:
> > 1. Is there any
> > automatization in discovery of the deployed elements?
>
> The Composition package reads the block.xml file(s) and builds a model of
the
> involved components, matches any dependencies and tries to figure out what
> ties into what (that has a good chance of being deployed).
>
> >2. What do you think to either integrate with
> > Jini or develop a similar mechanism in Merlin?
>
> There has been some debate of "Jini in Avalon", and since I am probably
one of
> the more experience Jini users, I guess it falls onto my responsibility to
> figure out how this can be achieved,
>
> Central in the Jini metaphor is that service are not always available and
the
> 'client' always has to support this, whereas in Merlin the total opposite
is
> true. So I have recognized that there has to be some form of Availability
> noitification system introduced, and I haven't gotten to defining one.
Once
> that is in place, we not only get the Jini/Distributed services
possibility,
> but also reloadable components, which is desirable independently of
> Jini/distrbuted.
>
> Once that is in place, it is a matter of moving forward.
>
>
> Niclas
> --
> +---------//-------------------+
> |   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


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org


Mime
View raw message